全局变量在多线程中直接读写会导致数据竞争和未定义行为，因++等操作非原子，可能引发计数错误、崩溃或断言失败；应使用互斥锁（如std::mutex配合std::lock_guard）严格保护所有读写访问。
全局变量在多线程中直接读写会出什么问题
直接用普通全局变量（比如 int g_counter = 0;）在多个线程里做 ++g_counter，结果几乎必然错误。这不是“偶尔错”，而是因为 ++ 不是原子操作：它包含读取、加1、写回三步，两个线程可能同时读到旧值，各自加1后写回，最终只+1而不是+2。
常见现象包括：计数远小于预期、程序崩溃（如多个线程同时 delete 同一指针）、数据结构（如 std::vector）内部状态不一致触发断言失败。
除非你明确做了同步，否则「全局变量 + 多线程」默认等于未定义行为。
怎么安全地共享全局状态：互斥锁是最常用解法
对共享全局变量加锁，是最直观、也最可控的方式。C++ 标准库提供 std::mutex 和 RAII 封装 std::lock_guard，避免忘记解锁。
立即学习“C++免费学习笔记（深入）”；
- 声明全局变量和配套互斥量要成对出现，且互斥量本身不能是局部静态或延迟初始化的（否则首次访问可能竞态）
- 所有读写该变量的地方，必须用同一把锁保护；漏掉任意一处（比如只锁写不锁读），仍可能读到中间状态
- 避免在锁内做耗时操作（如 I/O、sleep、调用未知第三方函数），否则拖慢整个线程池
示例：
int g_shared_data = 0;
std::mutex g_shared_mutex;
void thread_func() {
for (int i = 0; i < 1000; ++i) {
std::lock_guard<std::mutex> lk(g_shared_mutex);
++g_shared_data; // 安全
}
}
什么时候该用 thread_local 而不是全局变量
thread_local 不是“线程安全的全局变量”，而是“每个线程一份独立副本”的变量。它解决的是**避免共享、消除同步开销**的问题，典型场景包括：
- 缓存线程本地计算结果（如正则表达式编译对象、随机数引擎
std::mt19937） - 避免频繁分配/释放资源（如线程专用的
std::string或小内存池） - 封装非线程安全的 C 库上下文（如
errno的替代、OpenSSL 的ERR_get_error()相关状态）
注意：thread_local 变量的构造和析构发生在对应线程的生命周期内，主线程的 main() 开始前和结束时各一次；新线程中首次访问时才构造。如果构造函数抛异常，该线程后续访问会再次尝试构造——这点容易被忽略。
std::atomic 能否替代 mutex 处理全局变量
可以，但仅限于简单类型（int、bool、指针）的单一原子操作。例如 std::atomic_int g_counter{0}; 支持 g_counter.fetch_add(1) 这类无锁原子更新。
优势是无锁、低开销；劣势也很明确：
- 不支持复合操作（比如“如果值为 X 则设为 Y，否则不变”需用
compare_exchange_weak手动实现 CAS 循环） - 无法保护多个变量的关联更新（如同时改
g_x和g_y并保证二者一致性） - 对用户自定义类型，只有 trivially copyable 且满足特定对齐要求才能用
std::atomic<T>，且多数编译器实际只支持 lock-free 实现的子集
所以，别为了“看起来高级”硬套 std::atomic。该用锁的时候，锁更直白、更易维护。
真正容易被忽略的点是：thread_local 和 atomic 都解决不了「跨线程传递复杂状态」的问题。一旦你需要让线程 A 的某个中间结果被线程 B 精确观察到，就得回到同步原语（mutex / condition_variable / future）或者无锁数据结构的设计层面——那已经是另一个复杂度层级了。
