最简最安全的单例实现是用static局部变量，C++11保证其首次初始化线程安全、懒加载、自动析构且无需手动同步；必须显式删除拷贝和赋值以防止绕过控制。
用 static 局部变量实现 Meyers 单例（最简、最安全）
C++11 标准明确保证：函数内 static 局部变量的首次初始化是线程安全的。编译器自动生成等效于 std::call_once 的同步逻辑，无需你写锁、也不依赖 std::mutex。
- 构造函数只执行一次，其余并发线程会阻塞等待初始化完成，不是忙等
- 析构在程序退出时由静态存储期自动触发，且线程安全上下文中调用
- 懒加载 —— 实例在首次调用
getInstance()时才构造，不浪费启动资源 - 禁止拷贝和赋值必须显式声明为
= delete，否则可能意外复制出新对象
示例：
class Singleton {
public:
static Singleton& getInstance() {
static Singleton instance; // ✅ C++11 线程安全
return instance;
}
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
private:
Singleton() = default; // 可含耗时初始化（如打开文件、连数据库）
~Singleton() = default;
};
为什么不要手写双重检查锁定（DCLP）
手动实现 if (ptr == nullptr) { lock; if (ptr == nullptr) ptr = new T; } 在 C++ 中极易出错，尤其在构造函数可能抛异常或含复杂逻辑时。
-
new若抛异常，ptr仍为nullptr，但内存已部分分配，后续重试可能泄漏或重复构造 - 旧标准下存在指令重排风险：对象内存分配后、构造函数执行前，指针就可能被其他线程读到
- 即使 C++11 引入
std::atomic和内存序，正确实现 DCLP 仍需精确控制memory_order，远超多数场景需求 - 编译器对 DCLP 的优化行为不稳定，不同平台/版本表现可能不一致
需要异常安全重置时，用 std::call_once + std::unique_ptr
标准 static 局部变量无法在运行时销毁并重建实例。若你的单例需支持「重置」（比如测试中反复初始化），就得换方案。
立即学习“C++免费学习笔记（深入）”；
- 把实例托管给
std::unique_ptr，配合std::once_flag和std::call_once - 构造逻辑放在 lambda 里，确保只执行一次；析构由
unique_ptr自动管理 - 需手动注册
atexit或在合适时机调用reset()，否则程序退出时不自动释放 - 比
static局部变量多一层间接访问（解引用），但开销可忽略
关键片段：
class Singleton {
public:
static Singleton& getInstance() {
std::call_once(onceFlag, []() {
instance = std::make_unique<Singleton>();
});
return *instance;
}
private:
Singleton() = default;
static std::unique_ptr<Singleton> instance;
static std::once_flag onceFlag;
};
std::unique_ptr<Singleton> Singleton::instance;
std::once_flag Singleton::onceFlag;
饿汉式（static 成员变量）的隐含代价
把实例声明为类内 static 成员、在类外定义（如 Singleton Singleton::instance;），确实线程安全 —— 因为全局对象初始化发生在 main() 之前，由链接器和启动代码保证顺序。
- 但它不是懒加载：程序一启动就构造，哪怕从不调用
getInstance() - 全局对象析构顺序不可控，若单例依赖其他静态对象（比如日志器），可能在依赖对象析构后还被访问
- 多个翻译单元间静态对象初始化顺序未定义，跨模块使用时风险更高
- 仅适合无副作用、无外部依赖、构造极快的简单类型
真正需要「启动即建」时，优先考虑用 static 局部变量 + 显式初始化函数，而非裸饿汉式。
最易被忽略的一点：无论用哪种方式，都必须禁用拷贝和移动语义 —— = delete 不只是形式，漏掉就等于开放了绕过单例控制的路径。另外，构造函数里若调用其他单例，要注意初始化顺序死锁风险，这不是语法能解决的，得靠设计约束。
