CString 类的线程不安全问题
1 问题描述
CString
类线程不安全问题和解决过程,测试运行一段时间后,后台软件崩了,软件重启后,恢复正常,隔三四小时又出现异常,Debug模式下调用堆栈,发现问题出现在strname = pSystemInfo-> szName
这一行。
程序中定义结构体(相关的成员变量):
异常报错地方 strname = pSystemInfo-> szName
,调试指向:
2 问题分析
报异常处strName = pSystemInfo-> szName
,strName
内存无法读取,pSystemInfo-> szName
为一物联网设备的名称,多次测试都是同一设备出问题,刚开始怀疑与这一设备有关,于是屏蔽该设备继续测试。
运行三五小时过去了,没有出现异常,以为这样就解决了, 三四天过去了软件又报异常,这次发现异常还在同一地方 pSystemInfo-> szName
换其他设备了,意识到异常与设备无关,但为什么以前测试总是同一设备出问题呢。
经抓包软件抓取数据包发现,其他设备发送数据和心跳数据包都比较稳定,经常出问题的这台设备发送数据的频率异常,一秒发好几条数据,这就解释了为什么出问题的时候总是这个设备名称,其实和设备没有关系,只是因为这台设备频率快出错的概率更大一些,于是,写了测试代码对后台软件狂发测试数据,果然不到 20 分钟报异常了,异常还在这里。
经过分析以及查资料得知,导致这个问题的根本原因是因为 CString
类不是线程安全的,在线程中进行 CString
字符串的拷贝会导致内存泄露。
CString
的 “=” 拷贝操作的源码如下:
CString
的拷贝构造函数没有使用内存分配,而是使用的引用,它内部保存了一个引用的计数器(这是错误的根源)。
比如:
另外,它分配内存的方法是 4 字节对齐的 64 字节的倍数 + sizeof (内部结构)(超过 64 的时候)。
在多数情况下,比较简单的使用过程中,MFC 的这个 BUG 不会发作,也就是不会有内存泄露。
那什么时候 CString
会暴露出 BUG 呢?如果多次调用带有CString
引用的参数的函数,在一定的时候,CString
的内部引用记数器发生记数混乱,造成内存泄露。
所以尽量避免使用 CString
,例如可以改用 char 数组。
修改后的结构体定义:
VC++7(.NET) 中,MFC 彻底修改了 CString
,把它写成了 CString T
形式的模板类。
CString
在线程处理中,稍有处理不当,极易引起内存泄漏。
再看另外一个例子:
可以看到非常简单,在 debug 下,很容易看到如下的内存泄漏。
遇到这种问题可以使用 ATL 提供的 CAtlStringMgr
类对字符串数据进行自定义内存分配。
如上代码才具有线程安全性。
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个 长度的内存,如下:
这样做是防止内存碎片和提高效率,由于 CString
类都会重用分配的定长内存,所以一般异常的地方大多数也是在 CString
操作的地方。
当在多线程中使用共享
CString
变量时,遇到异常问题最简单的解决办法就是不用CString
改为char *
或char[]
。当在线程中使用局部变量时候,可以使用 ATL 提供的
CAtlStringMgr
类对字符串数据进行自定义内存分配,保证线程的中CString
变量的安全性。
例如:
版权声明: 本文为 InfoQ 作者【C语言与CPP编程】的原创文章。
原文链接:【http://xie.infoq.cn/article/f6a8cd2e92718707ff735ed6a】。文章转载请联系作者。
评论