应优先使用 std::call_once 或静态局部变量而非手写 DCLP，因后者易受内存重排影响且 volatile 无效；前者由标准保证线程安全、异常安全与高效实现，后者由编译器自动插入同步逻辑。
为什么用 std::call_once 而不是双重检查锁定（DCLP）？
因为手写 DCLP 在 C++11 之前极易出错：内存重排可能导致返回未构造完成的对象指针。C++11 起，std::call_once 提供了标准、简洁、且编译器保证的线程安全初始化机制，无需手动管理 std::atomic 或内存序。
- 所有主流编译器（GCC/Clang/MSVC）对
std::call_once都有高效实现，底层通常用 futex 或 Windows SRWLock，性能不输手工优化 - 不要试图用
volatile修复 DCLP——它在 C++ 中对线程同步无效，纯属误导 - 如果单例构造函数可能抛异常，
std::call_once会确保后续调用仍安全重试（标准规定：仅首次抛异常的那次调用失败，其余等待线程继续阻塞直到成功或再次抛异常）
static local variable 的线程安全性是否足够？
是的，C++11 标准明确要求静态局部变量的初始化是线程安全的——这本质上就是编译器自动为你插入了类似 std::call_once 的逻辑。它比手写单例更简短、更难出错。
- 写法：
static MyClass instance;放在getInstance()内部即可，无需额外锁或标志位 - 注意：必须是 *函数作用域内* 的 static 变量；类内
static成员变量不享受此保证，仍需手动同步 - 某些嵌入式平台或老版本编译器（如 GCC __cplusplus >= 201103L 且启用
-std=c++11或更高
析构时机与静态对象生命周期冲突怎么办？
静态局部变量会在程序退出时按构造逆序销毁，但如果其他静态对象（比如全局 std::ofstream）的析构函数中调用了单例，就可能访问已销毁的实例——这是典型的静态析构顺序问题。
- 最稳妥做法：放弃自动析构，改用“只构造、不析构”策略。把
static变量声明为static MyClass* instance = nullptr;，配合std::call_once+new分配，不 delete - 如果必须析构，可用
atexit()注册清理函数，但要确保注册顺序可控，且避免跨 DLL 边界调用 - 别依赖
std::shared_ptr管理单例生命周期——它的控制块本身也是静态对象，无法解决根本问题
如何验证你的单例真的线程安全？
光看代码不能证明，得用工具暴露竞态。实际测试比理论推演更重要。
立即学习“C++免费学习笔记（深入）”；
- 用
std::thread启动 100+ 线程并发调用getInstance()，检查返回地址是否全部相同（&*ptr == &*ptr），并观察 ASan/TSan 是否报 data race - Clang/GCC 下加
-fsanitize=thread编译，运行时能直接捕获初始化阶段的竞态（比如两个线程同时进入构造函数体） - 禁用编译器优化（
-O0）测试——某些看似安全的写法在优化后会暴露出重排问题
真正麻烦的从来不是“怎么写”，而是“怎么确认它没在某个边界条件下崩”。线程安全单例的坑，往往藏在百万次调用后的某一次析构里。
