为什么直接用静态局部变量最安全
在 C++11 及以后，static 局部变量的初始化天然线程安全——编译器自动生成带 pthread_once 或类似机制的保护逻辑，无需手动加锁。这是目前最简洁、最可靠的方式，且无内存泄漏和指令重排风险。
常见错误是还在手写 getInstance() + std::mutex，既冗余又容易漏锁或死锁。更糟的是，有人用老式 double-checked locking（DCL）但没加 std::atomic 和内存序，导致在优化级别升高后崩溃。
- 必须确保编译器支持 C++11 或更高标准（
-std=c++11） - 不要在构造函数里调用其他单例的
getInstance()，否则可能引发静态初始化顺序问题 - 若需延迟初始化且构造开销极大，静态局部变量仍适用；它只在第一次调用时构造，之后直接返回引用
class Singleton {
public:
static Singleton& getInstance() {
static Singleton instance; // 线程安全，C++11 起保证
return instance;
}
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
<p>private:
Singleton() = default; // 可含复杂初始化逻辑
};双重检查锁定（DCL）为何必须用 std::atomic 和 memory_order_acquire/release
原始 DCL（如 Java 风格）在 C++ 中不安全：编译器重排和 CPU 乱序可能导致 instance 指针被提前写入，而对象实际未构造完成。仅靠 std::mutex 锁两次是低效且错误的——第一次检查必须原子读，第二次写必须原子写+禁止重排。
关键点不是“加锁”，而是“控制可见性与执行顺序”。裸指针 + volatile 完全无效，volatile 不提供线程同步语义。
立即学习“C++免费学习笔记（深入）”；
-
instance必须声明为std::atomic<singleton></singleton>，不能是Singleton* - 首次读用
load(std::memory_order_acquire)，避免后续读被重排到其前 - 写入用
store(ptr, std::memory_order_release)，确保构造完成后再更新指针 - 中间的
new Singleton必须在锁内完成，且不能被编译器移到锁外
class Singleton {
public:
static Singleton* getInstance() {
Singleton* ptr = instance.load(std::memory_order_acquire);
if (ptr == nullptr) {
std::lock_guard<std::mutex> lock(mutex_);
ptr = instance.load(std::memory_order_acquire);
if (ptr == nullptr) {
ptr = new Singleton();
instance.store(ptr, std::memory_order_release);
}
}
return ptr;
}
<p>private:
static std::atomic<Singleton*> instance;
static std::mutex mutex_;
};什么时候不该用单例，哪怕它线程安全
单例本质是全局状态，会隐式增加模块耦合、阻碍单元测试（无法 mock）、掩盖生命周期依赖。很多所谓“需要全局唯一”的场景，其实更适合依赖注入或作用域明确的工厂函数。
典型误用包括：日志器、配置管理器、数据库连接池。它们往往需要可配置、可替换、可重置——而单例把这些能力锁死了。
- 如果类有非 trivial 析构函数（比如要释放资源），静态局部变量方式在程序退出时析构顺序不可控，可能 crash
- 动态库中使用单例需格外小心：多个 DLL 可能各自初始化一份，尤其 Windows 下不同模块的静态变量不共享
- 单元测试中若单例持有状态，必须显式重置（如提供
resetForTest()），否则测试间污染
真正要注意的不是“怎么写”，而是“谁来销毁”
静态局部变量由运行时在 main() 返回后自动析构，看似省心，但若析构函数中调用了另一个单例（或任何依赖全局状态的代码），就进入未定义行为——此时其他单例可能已被析构。
更隐蔽的问题是：某些嵌入式环境或特殊运行时（如 iOS 的 App Extension）不保证静态析构器执行，导致资源泄漏不报错，只在长期运行后暴露。
所以比“如何线程安全创建”更重要的是：确认这个单例是否真该存在，以及它的生命周期是否真的能由语言运行时托管。
