C++11起推荐用static局部变量实现线程安全单例，编译器保障首次初始化原子性；禁用DCL、裸指针和volatile，饿汉式虽线程安全但有资源浪费与初始化顺序风险。
直接用 static 局部变量，别手写锁、别裸指针、别 volatile —— 这是 C++11 及以后最简、最可靠、编译器级保障的线程安全单例写法。
用 static 局部变量实现（C++11 起标准保证）
C++11 标准明确规定：函数内 static 局部变量的首次初始化是原子的、线程安全的。编译器自动生成等效于 std::call_once 的同步逻辑，你完全不用管锁、内存序或原子操作。
- 构造函数只执行一次，其余并发线程会阻塞等待，不是忙等
- 懒加载：实例在第一次调用
getInstance()时才构造 - 析构由静态存储期自动管理，在程序退出时线程安全地调用
- 必须显式删除拷贝和赋值，否则可能意外复制出新对象
示例：
class Singleton {
public:
static Singleton& getInstance() {
static Singleton instance; // ✅ 线程安全，C++11 起 guaranteed
return instance;
}
private:
Singleton() = default;
~Singleton() = default;
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
};
为什么不能用裸指针 + new + 双重检查（DCL）
手写 if (ptr == nullptr) { lock; if (ptr == nullptr) ptr = new T; } 在 C++ 中极易崩溃，不是“加没加锁”的问题，而是内存可见性与指令重排导致未定义行为。
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
ptr必须是std::atomic<Singleton*>，裸指针或volatile Singleton*完全无效 - 首次读必须用
load(std::memory_order_acquire)，否则后续读可能被重排到构造前 -
new Singleton()必须在std::lock_guard内完成，且不能被编译器优化出临界区 -
store(ptr, std::memory_order_release)必须在锁内，否则其他线程看到非空指针时，对象状态不可见 - 若构造函数抛异常，
ptr仍为nullptr，但内存可能已部分分配，后续重试易泄漏或重复构造
需要运行时重置时怎么办
标准 static 局部变量无法在程序运行中销毁重建。若测试、插件热重载等场景需「重置」，就得换方案：
- 用
std::unique_ptr<Singleton>托管实例，配合std::once_flag和std::call_once - 初始化逻辑写在 lambda 里，确保只执行一次
- 需手动调用
reset()销毁，或注册atexit()清理，否则程序退出时不自动释放 - 比
static局部变量多一次指针解引用，但开销可忽略
关键片段：
class Singleton {
public:
static Singleton& getInstance() {
static std::once_flag flag;
static std::unique_ptr<Singleton> instance;
std::call_once(flag, []{
instance = std::make_unique<Singleton>();
});
return *instance;
}
private:
Singleton() = default;
};
饿汉式也线程安全，但有隐含代价
静态成员变量在程序启动时初始化，天然无竞争，确实线程安全：
class Singleton {
private:
static Singleton instance;
Singleton() = default;
public:
static Singleton& getInstance() { return instance; }
};
Singleton Singleton::instance; // 全局初始化，在 main() 前完成
但它的问题很实在：
- 不管是否用到，都会在启动时构造，浪费资源（比如打开文件、连数据库）
- 依赖全局初始化顺序：若多个饿汉单例相互调用，可能因初始化顺序未定义而崩溃
- 析构时机不可控，可能在某些库已卸载后才调用，引发 crash
真正容易被忽略的是：**局部 static 变量方案看似简单，但很多人仍下意识写 DCL，只因旧书/老代码惯性太强。它不是“一种可选方案”，而是 C++11 起唯一推荐的默认解法——不写错、不维护、不踩坑，就是它的全部意义。**
