C++11 起 static 局部变量初始化线程安全，编译器自动生成双重检查锁，确保首次调用时仅一个线程执行构造，其余等待；但仅限初始化过程，内部状态读写仍需手动同步。
为什么 static 局部变量能保证线程安全？
从 C++11 开始，static 局部变量的初始化是线程安全的——标准明确要求编译器生成带双重检查锁（double-checked locking）语义的代码。这意味着第一次调用时，多个线程同时进入函数，也只会有一个线程执行构造，其余阻塞等待，且无需手动加锁。
这是 Meyers’ Singleton 的核心依据，也是它比手写 std::call_once 或互斥量更简洁的根本原因。
- 必须使用 C++11 或更高标准（
-std=c++11及以上） - 构造函数不能是
explicit（否则无法隐式构造） - 不要在构造函数中抛异常：若初始化失败，后续调用会再次尝试，但行为未定义（可能 crash 或重复抛出）
getInstance() 的标准写法与常见误写
正确实现仅需一个函数、一个静态局部变量，返回引用：
class Singleton {public: static Singleton& getInstance() {static Singleton instance; // C++11 线程安全初始化 return instance;} private: Singleton() = default; // 防止外部构造 ~Singleton() = default; // 非虚析构（无继承时 OK）Singleton(const Singleton&) = delete; Singleton& operator=(const Singleton&) = delete; };常见错误包括：
立即学习“C++ 免费学习笔记（深入）”；
- 返回
Singleton*并在堆上new：失去自动生命周期管理，易内存泄漏，且破坏线程安全前提（new本身不安全） - 把
static Singleton instance;提到类外全局 作用域：C++98 风格，不保证线程安全（尤其 DLL/so 加载顺序复杂时） - 在
getInstance()中加std::mutex：冗余，且可能引入死锁（比如构造函数内又调用getInstance()）
析构时机与静态对象生命周期风险
静态局部变量的析构发生在 main() 返回后、程序退出前，按构造逆序执行。这意味着：
- 单例对象在
main()结束后才被销毁，其他静态对象若在析构期访问它，会触发未定义行为（已析构访问） - 若单例持有资源（如线程、文件句柄、网络连接），应在析构函数中显式清理，不能依赖 RAII 自动释放（因为析构顺序不可控）
- 跨 DLL 边界使用时，不同模块可能看到不同实例（Windows 下每个 DLL 有独立静态变量空间），此时需导出符号或改用指针 + 显式初始化
什么时候不该用 Meyers’ Singleton？
它简单可靠，但不是万能解。以下情况需谨慎或换方案：
- 需要控制析构顺序（例如日志单例必须最后销毁）→ 改用
std::unique_ptr+std::call_once手动管理生命周期 - 构造开销极大，且 90% 场景下根本不会用到 → 考虑延迟初始化 + 原子指针（
std::atomic），避免首次调用卡顿 - 测试时需替换实现（mock）→ Meyers 版本无法重置或注入，应改用依赖注入或工厂接口
- 目标平台不支持 C++11（如某些嵌入式环境）→ 必须退回到 Pthreads / Win32 API + 双重检查锁
最常被忽略的一点：Meyers 单例的“线程安全”仅限于初始化过程。如果单例内部状态可变，所有读写操作仍需自行同步（比如加 std::mutex 或用原子变量）。
