C++如何编写线程安全的单例模式

# C++如何编写线程安全的单例模式 C++11前，双重检查锁定（DCLP）是很多人实现线程安全单例的首选方案，但说实话，这条路坑很多。问题出在哪儿？编译器重排序和CPU指令重排，可能导致`instance`指针被提前赋值——对象还没构造完，其他线程看到非空指针就直接拿来用，结果就是未定义行为。典型表现：`Segmentation fault`，或者读到一些半初始化的字段（比如指针成员明明是`nullptr`，理论上不该这样）。 ## 为什么双重检查锁定（DCLP）在C++11之前不安全 编译器重排序和CPU指令重排是罪魁祸首。`instance`指针的赋值操作，可能被提前到对象构造完成之前。其他线程发现指针不空，直接冲进去用，触发未定义行为。 实际代码中常见什么现象？`Segmentation fault`，或者读到的对象字段残缺不全——比如某个指针成员应该是`nullptr`但被赋予了未知值。 - C++11之前，必须用平台相关的内存屏障（比如`_ReadWriteBarrier`或`__sync_synchronize`）来强行约束，可维护性很差 - 就算给指针加上`volatile`，也拦不住编译器对非`volatile`成员的重排 - 而静态局部变量的初始化，从C++11开始，标准才正式保证其线程安全性——这才是更优解 ## 用静态局部变量实现最简线程安全单例 C++11标准明确规定了：函数内静态局部变量的首次初始化，是原子操作、线程安全的，并且只会执行一次。不需要手动加锁，也不需要双重检查。 ```cpp class Singleton { public: static Singleton& getInstance() { static Singleton instance; // ✅ 线程安全，延迟初始化 return instance; } Singleton(const Singleton&) = delete; Singleton& operator=(const Singleton&) = delete; private: Singleton() = default; // 可含复杂初始化逻辑 }; ``` 有几个注意点： - `instance`的构造函数不能抛异常。如果可能抛异常，首次调用会直接终止程序（C++11行为） - 销毁时机由实现定义，通常在`main()`返回后按构造逆序销毁；多线程环境下，析构顺序不保证 - 适用于绝大多数场景，比手写`std::call_once`更简洁、高效 ## 需要控制析构时机时用`std::call_once` + `static`指针 有些场景下，静态局部变量那套行不通：比如单例需要在特定时间点显式销毁（卸载插件、重置测试环境），或者构造函数可能抛异常。这时改用动态分配 + 显式管理。 ```cpp class Singleton { public: static Singleton& getInstance() { std::call_once(init_flag, []{ instance = new Singleton(); }); return *instance; } static void destroy() { delete instance; instance = nullptr; } private: static Singleton* instance; static std::once_flag init_flag; Singleton() = default; }; Singleton* Singleton::instance = nullptr; std::once_flag Singleton::init_flag; ``` - `std::call_once`保证初始化代码块仅执行一次，且对所有线程同步 - 必须手动配对`destroy()`，否则泄漏；多线程调用`destroy()`还需额外同步 - 相比静态局部变量，多了堆分配开销和指针间接访问，但控制力更强 ## 别忽略静态初始化顺序问题 来看一个更隐蔽的坑：如果单例A的构造函数里调用了单例B的`getInstance()`，而B尚未初始化，就会触发所谓的"静态初始化顺序fiasco"——行为未定义。 - 无法靠加锁解决，因为此时连静态对象都未构造完成 - 避免跨单例依赖：把B的逻辑抽成无状态工具函数，或让A延迟到首次使用时再获取B实例（即惰性求值） - 如果必须依赖，可统一在`main()`开始前，用类似`std::ios_base::Init`的方式预初始化所有单例 真正棘手的不是"怎么写线程安全"，而是"谁在什么时候访问它"。初始化顺序和生命周期边界，往往比锁本身更难调试。