C/C++ 11 thread_local 注意事项

liulilittle

已于 2022-07-26 15:36:51 修改

阅读量954

点赞数 1

CC 4.0 BY-SA版权

分类专栏： C/C++ 文章标签： c++ 开发语言

于 2022-07-26 15:27:24 首次发布

本文链接：https://blog.csdn.net/liulilittle/article/details/125995213

C/C++ 专栏收录该内容

368 篇文章

订阅专栏

本文解析了C++11中thread_local的原理，强调了其依赖操作系统TLS存储，介绍了Windows API中的相关API。讨论了内存泄露问题及C++11编译器如何在线程结束时自动清理thread_local变量，以及在不同线程环境下的适用性和注意事项。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

thread_local 等价于 “static thread_local”，即局部线程存储（TLS）技术，注意：此（TLS）并非某 SSL/TLS 安全传输层协议，那个东西哈，乱入要有一个限度。

先贴一段代码：

class Foo {
public:
    ~Foo() {
        printf("close\r\n");
    }
    void say() {
        printf("say\r\n");
    }
};    

    std::thread([] {
        thread_local Foo foo;
        foo.say();
    }).detach();

此处以 Windows VC++ 为例：（GCC实际上也差不多）

我们先看看：foo.say() 是如何被执行的。

01094A7C 8B 0D 70 B3 59 01    mov         ecx,dword ptr [_tls_index (0159B370h)]  
01094A82 64 8B 15 2C 00 00 00 mov         edx,dword ptr fs:[2Ch]  
01094A89 8B 0C 8A             mov         ecx,dword ptr [edx+ecx*4]  
01094A8C 89 81 14 01 00 00    mov         dword ptr [ecx+114h],eax  
01094A92 68 18 E1 F5 00       push        offset `<lambda_8db51befb6b9322d4d50df9ac98a9cf6>::operator()'::`2'::`dynamic atexit destructor for 'foo'' (0F5E118h)  
01094A97 E8 61 9D EC FF       call        ___tlregdtor (0F5E7FDh)  
01094A9C 83 C4 04             add         esp,4  
   284:         foo.say();

可以看到它依赖于操作系统提供 Thread Local Store （TLS）线程存储机制，Windows API提供以下几个API：

TlsAlloc、TlsGetValue、TlsSetValue、TlsFree，分别对应几种不同的行为，每个线程在分配时操作系统内核都会为线程单独分配一个“TLS索引数组缓冲区”，注意这是有限大小，所以不可能允许开发人员无限制的分配大量的TLS变量。

而在 C++11 上面，thread_local 语法糖是存在内存泄露问题的，但按照标准化套路实现不会存在这个问题，举例：

我们通过 CreateThread 函数创建一个新的工作线程，并在该线程内部使用 thread_local 声明一个变量，那么就会产生泄露，因为没有地方调用 C/C++ 11 编译器内部实现的 “thread_local” 变量资源回收函数，而该函数是非公开的（编译器，编译期实现）。

而C/C++11提供的线程变量资源回收的契机是在 “thread_start（std::thread）”线程执行完毕以后，清理这些由 thread_local 语法糖声明持有的TLS线程存储变量资源。

一个全新的问题？如果C/C++11编译的 main 入口点执行函数（即STA线程模式下的主线程）执行完毕会不会执行 “TLS线程存储变量资源”呢？答案是可以的。

现代的C/C++11编译器，main 程序入口点函数已经不再是真正意义上的系统执行PE文件的可执行程序入口点函数了，在进入用户 main 函数以前现代 C/C++ 编译器会执行大量的由编译器生成的 “代码”，一般为初始化 “static global、common global” 定义的C++结构或类的分配（自然会调用构造函数），同理在 main 函数结束以后会执行相应的析构行为，而由C++11提供的 thread_local 实现的线程存储变量，自然也在析构的范畴。

所以：thread_local 语法糖实现的线程存储变量，不允许在 std::thread 标准库线程模板以外的方式创建的线程上面使用，这类情况则需要人工手动管理TLS线程存储（如果非要用）。

补充：但是CreateThread创建的线程上面仍旧可以使用 thread_local 进行释放，这种需要捕获系统释放TLS变量的堆栈，自己在C++中声明由编译器实现的线程回收函数，只要调用协议没什么问题，那么就可以让C/C++程序连接器连接上该函数，在线程结束的时候手动去调这个函数就可以回收了，只是不是很建议这样操作了，类似的操作也有替换C++编译器默认实现的 new，这种呢，依赖于对运算符的重载来实现，但缺点是只能是当前编译工程代码内可以被连接上，如其它编译为DLL的没什么用。