CString 類的線程不安全問題
1 問題描述
CString
類線程不安全問題和解決過程,測(cè)試運(yùn)行一段時(shí)間后,后臺(tái)軟件崩了,軟件重啟后,恢復(fù)正常,隔三四小時(shí)又出現(xiàn)異常,Debug模式下調(diào)用堆棧,發(fā)現(xiàn)問題出現(xiàn)在strname = pSystemInfo-> szName
這一行。
程序中定義結(jié)構(gòu)體(相關(guān)的成員變量):
typedef struct _SYSTEMINFO_CONTEXT
{
CString szMac; //mac地址
CString szName; //工程名稱
//構(gòu)造
_SYSTEMINFO_CONTEXT()
{
tAutoTime=COleDateTime::
GetCurrentTime();//初始化當(dāng)前時(shí)間
}
//析構(gòu)
~_SYSTEMINFO_CONTEXT()
{
}
}SYSTEMINFO_CONTEXT,*PSYSTEMINFO_CONTEXT;
strname = pSystemInfo-> szName; //異常報(bào)錯(cuò)地方
異常報(bào)錯(cuò)地方 strname = pSystemInfo-> szName
,調(diào)試指向:
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 問題分析
報(bào)異常處strName = pSystemInfo-> szName
,strName
內(nèi)存無法讀取,pSystemInfo-> szName
為一物聯(lián)網(wǎng)設(shè)備的名稱,多次測(cè)試都是同一設(shè)備出問題,剛開始懷疑與這一設(shè)備有關(guān),于是屏蔽該設(shè)備繼續(xù)測(cè)試。
if(pSystemInfo-> szMac == 這個(gè)設(shè)備的實(shí)際mac地址)
{
Break;
}
運(yùn)行三五小時(shí)過去了,沒有出現(xiàn)異常,以為這樣就解決了, 三四天過去了軟件又報(bào)異常,這次發(fā)現(xiàn)異常還在同一地方 pSystemInfo-> szName
換其他設(shè)備了,意識(shí)到異常與設(shè)備無關(guān),但為什么以前測(cè)試總是同一設(shè)備出問題呢。
經(jīng)抓包軟件抓取數(shù)據(jù)包發(fā)現(xiàn),其他設(shè)備發(fā)送數(shù)據(jù)和心跳數(shù)據(jù)包都比較穩(wěn)定,經(jīng)常出問題的這臺(tái)設(shè)備發(fā)送數(shù)據(jù)的頻率異常,一秒發(fā)好幾條數(shù)據(jù),這就解釋了為什么出問題的時(shí)候總是這個(gè)設(shè)備名稱,其實(shí)和設(shè)備沒有關(guān)系,只是因?yàn)檫@臺(tái)設(shè)備頻率快出錯(cuò)的概率更大一些,于是,寫了測(cè)試代碼對(duì)后臺(tái)軟件狂發(fā)測(cè)試數(shù)據(jù),果然不到 20 分鐘報(bào)異常了,異常還在這里。
經(jīng)過分析以及查資料得知,導(dǎo)致這個(gè)問題的根本原因是因?yàn)?CString
類不是線程安全的,在線程中進(jìn)行 CString
字符串的拷貝會(huì)導(dǎo)致內(nèi)存泄露。
CString
的 “=” 拷貝操作的源碼如下:
inline const CString& CString::operator=(const CString& stringSrc)
{
if (m_pchData != stringSrc.m_pchData) //防止自拷貝
{
//如果目標(biāo)對(duì)象的數(shù)據(jù)空間已經(jīng)分配,而且沒有別的CString實(shí)例指向它,則把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,這里為了防止多線程情況下出錯(cuò),使用了原子性自增
}
}
return *this;
}
CString
的拷貝構(gòu)造函數(shù)沒有使用內(nèi)存分配,而是使用的引用,它內(nèi)部保存了一個(gè)引用的計(jì)數(shù)器(這是錯(cuò)誤的根源)。
比如:
CString str1="aaa";
CString str2=str1; //注意,這時(shí)候str2并沒有調(diào)用 new ,而是使用str1的引用同時(shí),str1中保存的引用記數(shù)++。
str2="abcd1234"; //好了,現(xiàn)在str2才分配內(nèi)存,str1引用記數(shù)--。這同時(shí)也是為什么str2.Empty()就沒有內(nèi)存泄露的原因。因?yàn)閟tr1的引用記數(shù)也--了。
另外,它分配內(nèi)存的方法是 4 字節(jié)對(duì)齊的 64 字節(jié)的倍數(shù) + sizeof (內(nèi)部結(jié)構(gòu))(超過 64 的時(shí)候)。
在多數(shù)情況下,比較簡(jiǎn)單的使用過程中,MFC 的這個(gè) BUG 不會(huì)發(fā)作,也就是不會(huì)有內(nèi)存泄露。
那什么時(shí)候 CString
會(huì)暴露出 BUG 呢?如果多次調(diào)用帶有CString
引用的參數(shù)的函數(shù),在一定的時(shí)候,CString
的內(nèi)部引用記數(shù)器發(fā)生記數(shù)混亂,造成內(nèi)存泄露。
所以盡量避免使用 CString
,例如可以改用 char 數(shù)組。
修改后的結(jié)構(gòu)體定義:
typedef struct _SYSTEMINFO_CONTEXT
{
Char szMac[20]; //mac地址,對(duì)應(yīng)macAddr
Char szName[50]; //工程名稱
//構(gòu)造
_SYSTEMINFO_CONTEXT()
{
tAutoTime = COleDateTime::GetCurrentTime();//初始化當(dāng)前時(shí)間
}
//析構(gòu)
~_SYSTEMINFO_CONTEXT()
{
}
}SYSTEMINFO_CONTEXT,*PSYSTEMINFO_CONTEXT;
strncpy(pSystemInfo->szName,(LPCTSTR)strName,sizeof(pSystemInfo->szName)); //這樣就不會(huì)出錯(cuò)了
VC++7(.NET) 中,MFC 徹底修改了 CString
,把它寫成了 CString T
形式的模板類。
CString
在線程處理中,稍有處理不當(dāng),極易引起內(nèi)存泄漏。
再看另外一個(gè)例子:
//在線程函數(shù)中定義CString局部變量并進(jìn)行操作
CString strstate;
strstate.Format("正在解密,請(qǐng)稍后... (共 %d 張地圖)",p->m_countmap);
可以看到非常簡(jiǎn)單,在 debug 下,很容易看到如下的內(nèi)存泄漏。
遇到這種問題可以使用 ATL 提供的 CAtlStringMgr
類對(duì)字符串?dāng)?shù)據(jù)進(jìn)行自定義內(nèi)存分配。
CWin32HeapstringHeap(HEAP_NO_SERIALIZE, 0, 0 );
CAtlStringMgr stringMgr(&stringHeap );
CString strstate(&stringMgr );
strstate.Format("正在解密,請(qǐng)稍后... (共 %d 張地圖)",p->m_countmap);
如上代碼才具有線程安全性。
3 總結(jié)
我們開發(fā)時(shí)經(jīng)常會(huì)用到 CString
類,無可否認(rèn),CString
類是很好用,但很少人注意到 CString
類不是線程安全的。一般地,界面編程都是在主線程,很少用到多線程,所以不會(huì)遇到什么問題。但是,當(dāng)我們多個(gè)線程同時(shí)操作同一個(gè) CString
類型變量時(shí),就可能會(huì)出現(xiàn)內(nèi)存地址錯(cuò)誤,最終導(dǎo)致進(jìn)程異常退出。內(nèi)存錯(cuò)誤導(dǎo)致的問題也很難調(diào)查,通常導(dǎo)致內(nèi)存錯(cuò)誤的地方?jīng)]有馬上報(bào)異常,而且在程序的其他地方才捕獲異常。
CString
類的 Debug 版本和 Release 版本不完全一樣,Debug 版本則直接分配( MFC 在 Debug 版本有內(nèi)存管理,主要是為了排錯(cuò),內(nèi)存泄漏等),CString
類在 Release 版本會(huì)使用定長(zhǎng)內(nèi)存管理( CFixedAlloc 類),主要管理是4個(gè)長(zhǎng)度的內(nèi)存,
CString類的Debug版本和Release版本不完全一樣,Debug版本則直接分配(MFC在Debug版本有內(nèi)存管理,主要是為了排錯(cuò),內(nèi)存泄漏等),CString類在Release版本會(huì)使用定長(zhǎng)內(nèi)存管理(CFixedAlloc類),主要管理是 4個(gè) 長(zhǎng)度的內(nèi)存,如下:
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)));
這樣做是防止內(nèi)存碎片和提高效率,由于 CString
類都會(huì)重用分配的定長(zhǎng)內(nèi)存,所以一般異常的地方大多數(shù)也是在 CString
操作的地方。
-
當(dāng)在多線程中使用共享 CString
變量時(shí),遇到異常問題最簡(jiǎn)單的解決辦法就是不用CString
改為char *
或char[]
。 -
當(dāng)在線程中使用局部變量時(shí)候,可以使用 ATL 提供的 CAtlStringMgr
類對(duì)字符串?dāng)?shù)據(jù)進(jìn)行自定義內(nèi)存分配,保證線程的中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(……);
}
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問題,請(qǐng)聯(lián)系我們,謝謝!