1 问题描述
CString
类线程不安全问题和解决过程,测试运行一段时间后,后台软件崩了,软件重启后,恢复正常,隔三四小时又出现异常,Debug模式下调用堆栈,发现问题出现在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
为一物联网设备的名称,多次测试都是同一设备出问题,刚开始怀疑与这一设备有关,于是屏蔽该设备继续测试。
if(pSystemInfo-> szMac == 这个设备的实际mac地址)
{
Break;
}
运行三五小时过去了,没有出现异常,以为这样就解决了, 三四天过去了软件又报异常,这次发现异常还在同一地方 pSystemInfo-> szName
换其他设备了,意识到异常与设备无关,但为什么以前测试总是同一设备出问题呢。
经抓包软件抓取数据包发现,其他设备发送数据和心跳数据包都比较稳定,经常出问题的这台设备发送数据的频率异常,一秒发好几条数据,这就解释了为什么出问题的时候总是这个设备名称,其实和设备没有关系,只是因为这台设备频率快出错的概率更大一些,于是,写了测试代码对后台软件狂发测试数据,果然不到 20 分钟报异常了,异常还在这里。
经过分析以及查资料得知,导致这个问题的根本原因是因为 CString
类不是线程安全的,在线程中进行 CString
字符串的拷贝会导致内存泄露。
CString
的 “=” 拷贝操作的源码如下:
inline const CString& CString::operator=(const CString& stringSrc)
{
if (m_pchData != stringSrc.m_pchData) //防止自拷贝
{
//如果目标对象的数据空间已经分配,而且没有别的CString实例指向它,则把stringSrc的数据拷贝过来;
//或者,如果stringSrc的数据的引用次数小于零,则把它的数据拷贝过来
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
{
//其他情况,就先自己的数据空间释放掉,然后再指向stringSrc的数据空间
// can just copy references around
Release();
ATLASSERT(stringSrc.GetData() != afxDataNil);
m_pchData = stringSrc.m_pchData;
InterlockedIncrement(&GetData()->nRefs); //引用次数增1,这里为了防止多线程情况下出错,使用了原子性自增
}
}
return *this;
}
CString
的拷贝构造函数没有使用内存分配,而是使用的引用,它内部保存了一个引用的计数器(这是错误的根源)。
比如:
CString str1="aaa";
CString str2=str1; //注意,这时候str2并没有调用 new ,而是使用str1的引用同时,str1中保存的引用记数++。
str2="abcd1234"; //好了,现在str2才分配内存,str1引用记数--。这同时也是为什么str2.Empty()就没有内存泄露的原因。因为str1的引用记数也--了。
另外,它分配内存的方法是 4 字节对齐的 64 字节的倍数 + sizeof (内部结构)(超过 64 的时候)。
在多数情况下,比较简单的使用过程中,MFC 的这个 BUG 不会发作,也就是不会有内存泄露。
那什么时候 CString
会暴露出 BUG 呢?如果多次调用带有CString
引用的参数的函数,在一定的时候,CString
的内部引用记数器发生记数混乱,造成内存泄露。
所以尽量避免使用 CString
,例如可以改用 char 数组。
修改后的结构体定义:
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
在线程处理中,稍有处理不当,极易引起内存泄漏。
再看另外一个例子:
//在线程函数中定义CString局部变量并进行操作
CString strstate;
strstate.Format("正在解密,请稍后... (共 %d 张地图)",p->m_countmap);
可以看到非常简单,在 debug 下,很容易看到如下的内存泄漏。
遇到这种问题可以使用 ATL 提供的 CAtlStringMgr
类对字符串数据进行自定义内存分配。
CWin32HeapstringHeap(HEAP_NO_SERIALIZE, 0, 0 );
CAtlStringMgr stringMgr(&stringHeap );
CString strstate(&stringMgr );
strstate.Format("正在解密,请稍后... (共 %d 张地图)",p->m_countmap);
如上代码才具有线程安全性。
3 总结
我们开发时经常会用到 CString
类,无可否认,CString
类是很好用,但很少人注意到 CString
类不是线程安全的。一般地,界面编程都是在主线程,很少用到多线程,所以不会遇到什么问题。但是,当我们多个线程同时操作同一个 CString
类型变量时,就可能会出现内存地址错误,最终导致进程异常退出。内存错误导致的问题也很难调查,通常导致内存错误的地方没有马上报异常,而且在程序的其他地方才捕获异常。
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
类都会重用分配的定长内存,所以一般异常的地方大多数也是在 CString
操作的地方。
- 当在多线程中使用共享
CString
变量时,遇到异常问题最简单的解决办法就是不用CString
改为char *
或char[]
。 - 当在线程中使用局部变量时候,可以使用 ATL 提供的
CAtlStringMgr
类对字符串数据进行自定义内存分配,保证线程的中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(……);
}