直接加 mutex 保护 new 操作不够，因未防止指令重排导致线程看到未构造完成的对象；必须用 std::atomic 指针配合内存序，或更优地采用 std::call_once + std::once_flag。
为什么直接加 mutex 保护 new 操作还不够
懒汉式单例在首次调用 getInstance() 时才创建实例，看似简单，但多线程下极易出现双重检查失效问题。典型错误是只在外层判空后加锁、内部再判空，却没用 std::atomic 或内存序控制——这会导致某个线程看到非空指针但对象尚未构造完成（指令重排）。
常见现象：std::bad_alloc 没抛出，但后续访问实例成员时 crash；或程序偶发读到未初始化的字段值。
- 必须对指针本身做原子操作，不能只靠互斥锁同步构造逻辑
-
std::call_once+std::once_flag是更安全的选择，它天然处理内存序和重复调用 - 若坚持手写双重检查，需用
std::atomic<t></t>存储指针，并配合memory_order_acquire/memory_order_release
std::call_once 是最简且线程安全的实现方式
不用自己管理锁、不用纠结内存序，std::call_once 保证初始化函数只执行一次，且对所有线程可见。C++11 起完全可用，无兼容性顾虑。
示例结构：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
class Singleton {
public:
static Singleton& getInstance() {
std::call_once(initFlag, []{ instance = new Singleton; });
return *instance;
}
private:
Singleton() = default;
static Singleton* instance;
static std::once_flag initFlag;
};
<p>Singleton* Singleton::instance = nullptr;
std::once_flag Singleton::initFlag;-
initFlag必须是静态变量，生命周期贯穿整个程序 - lambda 内部用
new是允许的，但记得配对delete（或改用std::unique_ptr） - 如果构造函数可能抛异常，
std::call_once会重试——这点要小心，避免无限循环
用 std::unique_ptr 避免手动内存管理
原始指针 + new 容易漏掉析构，尤其单例生命周期与程序一致时，不显式释放虽不会泄漏，但资源（如文件句柄、线程）可能无法及时清理。
换成智能指针后，可利用其自动析构特性，且 std::call_once 仍适用：
class Singleton {
public:
static Singleton& getInstance() {
std::call_once(initFlag, []{
instance = std::make_unique<Singleton>();
});
return *instance;
}
private:
Singleton() = default;
static std::unique_ptr<Singleton> instance;
static std::once_flag initFlag;
};
<p>std::unique_ptr<Singleton> Singleton::instance;
std::once_flag Singleton::initFlag;-
std::unique_ptr的析构在程序退出时自动触发，适合管理需要显式关闭的资源 - 注意：不能返回
std::unique_ptr&，必须解引用返回引用（*instance） - 如果类有虚析构函数，确保它是 public 或 protected，否则
unique_ptr删除时行为未定义
为什么不要用局部静态变量替代
C++11 规定函数内局部静态变量的初始化是线程安全的，所以有人写 static Singleton instance; 然后返回引用。这看起来最简，但有隐藏代价：
- 每次调用
getInstance()都需检查是否已初始化（编译器插入的测试+跳转），高频调用时有轻微开销 - 销毁时机由实现定义，某些平台可能在 main 返回后、全局对象析构前就销毁，导致依赖它的其他静态对象访问野指针
- 无法控制构造失败后的重试逻辑（比如网络初始化失败时想重试几次）
它适合“绝对轻量、无资源依赖、不关心销毁顺序”的场景。一旦单例内部持有线程、socket 或需要显式 shutdown，就得退回到 std::call_once + 智能指针方案。
