第13章线程局部存储（Thread Local Storage）

课程目录第13章线程局部存储（Thread Local Storage）

13、线程局部存储（Thread Local Storage）：thread_local关键字、TLS的应用场景、性能考量

线程局部存储，简称TLS。说白了，就是给每个线程一份独立的变量副本。

你想想看，多线程编程里最头疼的是什么？是数据竞争。大家抢同一个变量，加锁、解锁、死锁，烦不烦？TLS的思路很简单——既然你们要抢，那我干脆每人发一份，各玩各的，不抢了。

我个人习惯把TLS比作「线程的私人储物柜」。每个线程打开自己的柜子，拿自己的东西，互不干扰。

13.1 thread_local 关键字

C++11开始，标准库正式支持了thread_local关键字。用法其实很简单：

// 线程局部变量声明
thread_local int g_counter = 0;

void worker() {
    g_counter++;  // 每个线程都有自己的g_counter
    std::cout << "counter = " << g_counter << "\n";
}

int main() {
    std::thread t1(worker);
    std::thread t2(worker);
    t1.join();
    t2.join();
    return 0;
}

运行结果，两个线程都会输出1。为什么？因为每个线程的g_counter是独立的，互不影响。

嗯，这里要注意：thread_local可以修饰全局变量、静态成员变量，也可以修饰函数内的局部静态变量。但不能修饰普通的局部变量——那玩意儿本来就在栈上，每个线程调用时自然就是独立的。

核心要点：

thread_local 变量在每个线程首次使用时创建
线程退出时，TLS变量自动销毁
不同线程的TLS变量地址不同，不存在数据竞争

13.2 TLS的应用场景

我在项目中遇到过不少适合用TLS的场景。挑几个典型的说说：

13.2.1 线程专属的日志缓冲区

高并发日志系统，如果所有线程都往同一个日志文件写，那锁竞争会非常严重。我见过一个项目，日志写入占了30%的CPU时间，全耗在锁上了。

解决方案？每个线程维护一个TLS缓冲区，先写到自己缓冲区里，满了再批量刷到文件。这样锁的粒度大大降低。

thread_local std::string tls_log_buffer;

void log_write(const std::string& msg) {
    tls_log_buffer += msg + "\n";
    if (tls_log_buffer.size() > 4096) {
        flush_to_file(tls_log_buffer);  // 批量写入
        tls_log_buffer.clear();
    }
}

13.2.2 线程安全的随机数生成器

随机数生成器不是线程安全的。你想想看，如果多个线程同时调用rand()，内部状态就乱套了。

我以前的做法是加锁，后来改成TLS版本，性能提升很明显：

thread_local std::mt19937 tls_rng(std::random_device{}());

int get_random() {
    std::uniform_int_distribution<int> dist(0, 99);
    return dist(tls_rng);
}

每个线程有自己的随机数引擎，完全不需要同步。

13.2.3 错误码与errno

说到这个，我记得早期Unix的errno是个全局变量。多线程程序里，一个线程刚检查完errno，另一个线程可能就把它改了。后来POSIX标准把errno改成了TLS实现——每个线程一份，这才解决了问题。

你现在用的C++标准库，errno就是TLS的。不信你试试：

#include <cerrno>
#include <thread>
#include <iostream>

void check_errno() {
    errno = 0;
    // 模拟某个系统调用失败
    errno = EINVAL;
    std::cout << "errno = " << errno << "\n";
}

int main() {
    std::thread t1(check_errno);
    std::thread t2(check_errno);
    t1.join();
    t2.join();
    return 0;
}

两个线程的errno互不干扰，这就是TLS的功劳。

13.2.4 线程池中的上下文信息

我曾经写过一个网络框架，每个工作线程需要知道自己的线程ID、当前处理的连接ID、以及一些统计信息。这些数据用TLS存储再合适不过：

struct ThreadContext {
    int thread_id;
    uint64_t processed_requests;
    std::string current_connection_id;
};

thread_local ThreadContext tls_ctx;

void worker_thread_init(int id) {
    tls_ctx.thread_id = id;
    tls_ctx.processed_requests = 0;
}

void handle_request(const std::string& conn_id) {
    tls_ctx.current_connection_id = conn_id;
    // 处理请求...
    tls_ctx.processed_requests++;
}

13.3 性能考量

TLS不是银弹。用得好是神器，用不好是坑。我踩过几个坑，跟你分享一下：

性能陷阱一：TLS访问比普通变量慢

每次访问TLS变量，编译器都要通过线程控制块（TCB）去寻址。这比直接访问栈变量或全局变量多了一层间接跳转。在热点路径上，这个开销不可忽视。

我曾经在一个高吞吐的中间件里，把频繁访问的计数器从TLS改成了普通全局变量+原子操作，性能反而提升了5%。为什么？因为那个变量每秒被访问几百万次，TLS的寻址开销累积起来很可观。

性能陷阱二：TLS变量过多导致内存膨胀

每个TLS变量，每个线程都有一份。如果你有100个线程，每个线程有10个TLS变量，每个变量占1KB，那就是100×10×1KB ≈ 1MB。看起来不多？但如果每个变量是1MB呢？那就是100MB。

我见过一个项目，开发人员把一个大对象（几MB）声明为TLS，结果开了200个线程后，内存直接爆了。嗯，这就是典型的「没算账」。

建议：

TLS变量尽量小而精，别放大的数据结构
热点路径上，考虑用普通变量+原子操作替代TLS
线程数可控的场景（如固定线程池）用TLS比较安全
动态创建大量线程的场景，注意TLS的内存累积

13.4 TLS的内部实现原理

为了让你更直观地理解TLS，我画了一张图：

从这张图可以看得很清楚：每个线程有自己的TLS存储区，里面放着各自的变量副本。而全局变量区是所有线程共享的，需要同步机制保护。

TLS的实现通常依赖于操作系统和编译器的支持。在Linux上，通过__thread关键字（GCC扩展）或C++11的thread_local，编译器会生成代码通过线程控制块（TCB）中的指针来访问TLS数据。

13.5 避坑指南

最后，我总结几个实战中容易踩的坑：

避坑一：DLL/动态库中的TLS

我曾经在Windows上写一个插件系统，主程序加载了多个DLL。结果发现，在DLL中声明的thread_local变量，在不同DLL之间居然不是同一个实例！这是因为每个DLL有自己的TLS索引。解决方案？要么统一用主程序提供的接口，要么用TLS回调函数来管理。

避坑二：TLS变量的析构顺序

线程退出时，TLS变量的析构顺序是未定义的。如果你的TLS变量A依赖TLS变量B，那就要小心了——B可能先被析构。我建议TLS变量之间不要有依赖关系，或者用智能指针来管理生命周期。

避坑三：fork()后的TLS

在Linux上，fork()之后，子进程只会保留调用fork()的那个线程。其他线程的TLS数据会丢失。如果你在子进程中访问了其他线程的TLS变量，那就是未定义行为。嗯，这个坑我踩过一次，调试了两天才找到原因。

好了，关于线程局部存储，就聊这么多。记住一句话：TLS是解决数据竞争的利器，但不是万能的。用对场景，事半功倍；用错场景，事倍功半。

公众号:蓝海资料掘金营，微信deep3321