静态变量多线程访问需同步，全局/成员静态变量非线程安全，局部静态仅初始化线程安全，析构期访问易崩溃，应明确访问主体与生命周期。
多线程访问静态变量不是“能不能用”的问题，而是“怎么用才不出错”的问题。直接读写 static 全局变量或静态成员变量，几乎必然引发数据竞争；而局部静态变量虽有初始化保护，但后续读写仍需同步——这点常被忽略。
静态全局变量和静态成员变量默认不线程安全
它们在内存中只有一份，所有线程共享同一地址。没有额外保护时，++、--、赋值等操作都不是原子的。
- 常见错误现象：
ResourceCounter::count在 5 个线程各递增 10000 次后，输出结果远小于 50000（如 42317），说明发生了丢失更新 - 根本原因：CPU 指令序列（读-改-写）被多个线程交叉执行，例如两个线程同时读到
count == 10，各自加 1 后都写回11 - 不能靠“只读”侥幸：即使当前逻辑只读，未来维护可能加入写操作；且编译器可能因未声明
const而做激进优化 - 性能影响：加锁（如
std::mutex）会串行化访问，高并发下成为瓶颈；改用std::atomic<int></int>可避免锁，但要注意内存序（默认memory_order_seq_cst安全但稍慢）
局部静态变量初始化是线程安全的，但仅限初始化那一刻
C++11 标准保证函数内首次执行到 static T x{...} 时，多个线程会排队等待初始化完成。但这不等于整个变量生命周期都受保护。
- 典型误用：在单例
getInstance()中用static Singleton s;安全构造，但后续调用s.doSomething()若内部修改了其成员，仍需自行加锁 - 编译器差异：GCC 4.3+、Clang 3.2+、MSVC 2015+ 均实现该保证；老版本（如 MSVC 2013）或嵌入式工具链可能不支持，需查文档确认
- 陷阱：若初始化过程抛异常（如构造函数 throw），标准规定该次初始化失败，下次进入仍会重试——可能反复抛异常，阻塞其他线程
析构顺序与多线程退出是隐蔽崩溃源
静态变量析构发生在 main() 返回后，由系统按“构造反序”执行。若此时仍有子线程运行并访问这些变量，就会触发 EXC_BAD_ACCESS 或 SIGSEGV。
- 真实崩溃案例：iOS 上 MNN 推理引擎子线程调用含静态变量的函数，主线程已调用
_exit开始析构，导致访问已释放内存 - 关键点：线程结束 ≠ 对象销毁。子线程可能仍在运行，而静态变量已被析构（尤其当线程未显式
join()或detach()不当） - 规避方式：避免在静态变量析构期依赖它；更稳妥的是用
thread_local替代部分场景（如每个线程独享缓存），或确保所有工作线程在main()结束前完成并join()
真正麻烦的不是初始化是否线程安全，而是你得时刻分清：这个静态变量，此刻是被谁访问？谁负责它的生命周期？有没有线程在它“死后”还试图读写？这些问题不厘清，加再多锁也拦不住崩溃。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
