CString 类的线程不安全问题

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（……）;
}

本文由哈喽比特于4年以前收录，如有侵权请联系我们。
文章来源：https://mp.weixin.qq.com/s/qPIDUG4c3iDF_rU8jTbNyQ