C++11前double-checked locking不安全，因缺乏内存模型约束，编译器和CPU重排序可能导致指针提前赋值而对象未构造完，引发未定义行为；volatile无法修复。
为什么 double-checked locking 在 C++11 前不安全
因为编译器重排序和 CPU 指令重排，可能导致 instance 指针被提前赋值，而对象构造尚未完成。其他线程看到非空指针后直接使用，触发未定义行为——常见现象是程序偶发崩溃、成员变量为垃圾值、或构造函数只执行了一半。
关键点在于：C++11 之前没有内存模型约束，volatile 无法阻止编译器优化，也不能保证跨线程可见性。
- 不要用
volatile修饰单例指针来“修复”这个问题 - 不要在 C++11 之前项目里手写 double-checked locking
- 如果必须支持旧标准，改用静态局部变量（见下一条）或进程启动时初始化
用 static local variable 实现最简线程安全单例
C++11 起，函数内 static 局部变量的初始化天然线程安全——标准明确要求首次进入时加锁，且仅初始化一次。这是目前最推荐的做法，无须手动管理锁、无内存序烦恼、也无资源泄漏风险。
示例：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
class Singleton {
public:
static Singleton& getInstance() {
static Singleton instance; // ✅ 线程安全，懒加载，自动析构
return instance;
}
private:
Singleton() = default;
~Singleton() = default;
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
};- 注意：必须是
static Singleton instance;，不是static Singleton* instance = new Singleton; - 析构时机由静态存储期决定，在 main 返回后、全局对象析构阶段执行
- 若需控制析构顺序（比如依赖其他静态对象），该方案可能出问题
std::call_once + std::once_flag 手动控制初始化时机
当单例构造逻辑复杂、需传参、或要延迟到某个特定函数调用点才真正创建时，std::call_once 更灵活。它比 static local 变量多一层可控性，但代码稍长，且容易漏掉 std::once_flag 的 static 修饰。
常见错误：把 std::once_flag 声明成非 static 成员或局部变量，导致每次调用都新建 flag，失去“仅一次”语义。
-
std::once_flag必须是 static 存储期（全局、类 static 成员、或函数内 static 局部变量） - 构造函数不能抛异常，否则
std::call_once行为未定义；如需异常处理，应在 lambda 内捕获 - 性能上，首次调用有原子操作开销，之后是普通分支判断，基本无损
为什么不用 std::shared_ptr + std::atomic 实现懒汉式
有人试图用 std::atomic<std::shared_ptr<Singleton>> 替代原始指针做 double-checked locking，以为能绕过内存序问题。但错在：std::shared_ptr 的原子操作只保证指针本身的读写原子性，不保证所指向对象的构造完成同步。
也就是说，你仍可能拿到一个 shared_ptr，其内部 ptr 非空，但对象尚未构造完毕。
- 不要自己封装基于
std::atomic<T*>的单例，除非你完整理解memory_order的六种语义及对应平台实现 -
std::atomic<T*>默认是memory_order_seq_cst，性能未必比std::call_once好 - 即使写对了，可读性和维护成本远高于 static local variable 方案
最容易被忽略的是：单例生命周期与静态对象析构顺序的交互。哪怕用了最标准的 static local 方式，一旦它在某个静态对象的析构函数中被访问，就可能已析构——这不是线程问题，而是定义顺序问题。这时候，别硬扛，考虑改用工厂函数或显式生命周期管理。
