1 問題描述

CString 類線程不安全問題和解決過程，測試運行一段時間后，后臺軟件崩了，軟件重啟后，恢復正常，隔三四小時又出現(xiàn)異常，Debug模式下調用堆棧，發(fā)現(xiàn)問題出現(xiàn)在strname = pSystemInfo-> szName 這一行。

程序中定義結構體(相關的成員變量):

typedef struct _SYSTEMINFO_CONTEXT
{
     CString szMac;  //mac地址
     CString szName;       //工程名稱

     //構造
     _SYSTEMINFO_CONTEXT()
    {
       tAutoTime=COleDateTime::
      GetCurrentTime();//初始化當前時間
    }

    //析構
    ~_SYSTEMINFO_CONTEXT()
    {
    
    }
}SYSTEMINFO_CONTEXT,*PSYSTEMINFO_CONTEXT;

strname = pSystemInfo-> szName;      //異常報錯地方

異常報錯地方 strname = pSystemInfo-> szName ，調試指向：

const CString& CString::operator=(const CString& stringSrc)
{
  if (m_pchData != stringSrc.m_pchData)
  {
    if ((GetData()->nRefs < 0 && GetData() != _afxDataNil) ||
      stringSrc.GetData()->nRefs < 0)
    {
      // actual copy necessary since one of the strings is locked
      AssignCopy(stringSrc.GetData()->nDataLength, stringSrc.m_pchData);
    }
    else
    {
      // can just copy references around
      Release();
      ASSERT(stringSrc.GetData() != _afxDataNil);
      m_pchData = stringSrc.m_pchData;
      InterlockedIncrement(&GetData()->nRefs);
    }
  }
  return *this;
}

2 問題分析

報異常處strName = pSystemInfo-> szName，strName 內存無法讀取，pSystemInfo-> szName 為一物聯(lián)網設備的名稱，多次測試都是同一設備出問題，剛開始懷疑與這一設備有關，于是屏蔽該設備繼續(xù)測試。

if(pSystemInfo-> szMac == 這個設備的實際mac地址)
{
    Break；
}

運行三五小時過去了，沒有出現(xiàn)異常，以為這樣就解決了， 三四天過去了軟件又報異常，這次發(fā)現(xiàn)異常還在同一地方 pSystemInfo-> szName 換其他設備了，意識到異常與設備無關，但為什么以前測試總是同一設備出問題呢。

經抓包軟件抓取數(shù)據(jù)包發(fā)現(xiàn)，其他設備發(fā)送數(shù)據(jù)和心跳數(shù)據(jù)包都比較穩(wěn)定，經常出問題的這臺設備發(fā)送數(shù)據(jù)的頻率異常，一秒發(fā)好幾條數(shù)據(jù)，這就解釋了為什么出問題的時候總是這個設備名稱，其實和設備沒有關系，只是因為這臺設備頻率快出錯的概率更大一些，于是，寫了測試代碼對后臺軟件狂發(fā)測試數(shù)據(jù)，果然不到 20 分鐘報異常了，異常還在這里。

經過分析以及查資料得知，導致這個問題的根本原因是因為 CString 類不是線程安全的，在線程中進行 CString 字符串的拷貝會導致內存泄露。

CString 的 “=” 拷貝操作的源碼如下：

inline const CString& CString::operator=(const CString& stringSrc)
{
    if (m_pchData != stringSrc.m_pchData) //防止自拷貝
    {
        //如果目標對象的數(shù)據(jù)空間已經分配，而且沒有別的CString實例指向它，則把stringSrc的數(shù)據(jù)拷貝過來；
        //或者，如果stringSrc的數(shù)據(jù)的引用次數(shù)小于零，則把它的數(shù)據(jù)拷貝過來
        if ((GetData()->nRefs < 0 && GetData() != afxDataNil) ||
            stringSrc.GetData()->nRefs < 0)
        {
            // actual copy necessary since one of the strings is locked
            AssignCopy(stringSrc.GetData()->nDataLength, stringSrc.m_pchData);
        }
        else
        {
            //其他情況，就先自己的數(shù)據(jù)空間釋放掉，然后再指向stringSrc的數(shù)據(jù)空間
            // can just copy references around
            Release();
            ATLASSERT(stringSrc.GetData() != afxDataNil);
            m_pchData = stringSrc.m_pchData;
            InterlockedIncrement(&GetData()->nRefs);  //引用次數(shù)增1，這里為了防止多線程情況下出錯，使用了原子性自增
        }
    }
    return *this;
}

CString 的拷貝構造函數(shù)沒有使用內存分配，而是使用的引用，它內部保存了一個引用的計數(shù)器（這是錯誤的根源）。

比如：

CString str1="aaa";

CString str2=str1;   //注意，這時候str2并沒有調用 new ，而是使用str1的引用同時，str1中保存的引用記數(shù)++。

str2="abcd1234";     //好了，現(xiàn)在str2才分配內存，str1引用記數(shù)--。這同時也是為什么str2.Empty()就沒有內存泄露的原因。因為str1的引用記數(shù)也--了。

另外，它分配內存的方法是 4 字節(jié)對齊的 64 字節(jié)的倍數(shù) + sizeof (內部結構)（超過 64 的時候）。

在多數(shù)情況下，比較簡單的使用過程中，MFC 的這個 BUG 不會發(fā)作，也就是不會有內存泄露。

那什么時候 CString 會暴露出 BUG 呢？如果多次調用帶有CString 引用的參數(shù)的函數(shù)，在一定的時候，CString 的內部引用記數(shù)器發(fā)生記數(shù)混亂，造成內存泄露。

所以盡量避免使用 CString ,例如可以改用 char 數(shù)組。

修改后的結構體定義：

typedef struct _SYSTEMINFO_CONTEXT
{
  Char szMac[20];       //mac地址，對應macAddr
  Char szName[50];     //工程名稱

  //構造
  _SYSTEMINFO_CONTEXT()
  {
    tAutoTime = COleDateTime::GetCurrentTime();//初始化當前時間
  }
  //析構
  ~_SYSTEMINFO_CONTEXT()
  {
  
  }
}SYSTEMINFO_CONTEXT,*PSYSTEMINFO_CONTEXT;

strncpy(pSystemInfo->szName,(LPCTSTR)strName,sizeof(pSystemInfo->szName)); //這樣就不會出錯了

VC++7(.NET) 中，MFC 徹底修改了 CString ，把它寫成了 CString T 形式的模板類。

CString 在線程處理中，稍有處理不當，極易引起內存泄漏。

再看另外一個例子：

//在線程函數(shù)中定義CString局部變量并進行操作

CString strstate;  
strstate.Format("正在解密，請稍后．．． (共 %d 張地圖)",p->m_countmap);

可以看到非常簡單，在 debug 下，很容易看到如下的內存泄漏。

遇到這種問題可以使用 ATL 提供的 CAtlStringMgr 類對字符串數(shù)據(jù)進行自定義內存分配。

CWin32HeapstringHeap(HEAP_NO_SERIALIZE, 0, 0 );
CAtlStringMgr stringMgr(&stringHeap );
CString strstate(&stringMgr );
strstate.Format("正在解密，請稍后．．． (共 %d 張地圖)",p->m_countmap);

如上代碼才具有線程安全性。

3 總結

我們開發(fā)時經常會用到 CString 類，無可否認，CString 類是很好用，但很少人注意到 CString 類不是線程安全的。一般地，界面編程都是在主線程，很少用到多線程，所以不會遇到什么問題。但是，當我們多個線程同時操作同一個 CString類型變量時，就可能會出現(xiàn)內存地址錯誤，最終導致進程異常退出。內存錯誤導致的問題也很難調查，通常導致內存錯誤的地方沒有馬上報異常，而且在程序的其他地方才捕獲異常。

CString 類的 Debug 版本和 Release 版本不完全一樣，Debug 版本則直接分配（ MFC 在 Debug 版本有內存管理，主要是為了排錯，內存泄漏等），CString 類在 Release 版本會使用定長內存管理（ CFixedAlloc 類），主要管理是4個長度的內存，

CString類的Debug版本和Release版本不完全一樣，Debug版本則直接分配（MFC在Debug版本有內存管理，主要是為了排錯，內存泄漏等），CString類在Release版本會使用定長內存管理（CFixedAlloc類），主要管理是 4個 長度的內存，如下：

1AFX_STATICCFixedAlloc _afxAlloc64(ROUND4(65*sizeof(TCHAR)+sizeof(CStringData)));

2AFX_STATICCFixedAlloc _afxAlloc128(ROUND4(129*sizeof(TCHAR)+sizeof(CStringData)));

3AFX_STATICCFixedAlloc _afxAlloc256(ROUND4(257*sizeof(TCHAR)+sizeof(CStringData)));

4AFX_STATICCFixedAlloc _afxAlloc512(ROUND4(513*sizeof(TCHAR)+sizeof(CStringData)));

這樣做是防止內存碎片和提高效率，由于 CString 類都會重用分配的定長內存，所以一般異常的地方大多數(shù)也是在 CString 操作的地方。

• 當在多線程中使用共享 CString 變量時，遇到異常問題最簡單的解決辦法就是不用 CString改為 char * 或 char[] 。
• 當在線程中使用局部變量時候，可以使用 ATL 提供的 CAtlStringMgr 類對字符串數(shù)據(jù)進行自定義內存分配，保證線程的中 CString 變量的安全性。

// Declare a non-thread-safe heap just for this thread
CWin32HeapstringHeap( HEAP_NO_SERIALIZE, 0, 0 );
// Declare a string manager that uses the thread's heap
CAtlStringMgrstringMgr( &stringHeap );
//do anything you want

例如：

{
    CString strstate(&stringMgr );
    strstate.format（……）;
}