std::call_once比手写DCL更可靠，因其由标准库保证“仅执行一次”，自动处理内存序、编译器/CPU重排、异常安全及析构管理，而手写DCL易因原子操作遗漏、内存序错误或构造函数提前暴露this导致未定义行为。
为什么直接用 std::call_once 比手写 DCL 更可靠
手写双重检查锁（DCL）在 C++11 之前是常见做法，但 C++11 内存模型引入了严格的顺序约束，手动实现极易出错。最典型的问题是：未用 std::atomic 声明指针、漏掉 memory_order_acquire/memory_order_release、或构造函数内提前暴露 this 指针（如注册回调、发消息），导致其他线程看到未初始化完成的对象。
而 std::call_once 封装了正确的栅栏语义和异常安全逻辑，且编译器对其有专门优化。它在首次调用时加锁执行一次初始化，后续调用无锁返回，性能不输正确实现的 DCL，且代码更短、可读性更高。
-
std::call_once自动处理异常：若初始化函数抛异常，后续调用仍会重试（符合单例语义） - 无需手动管理
static指针生命周期或原子操作细节 - 避免因忘记
memory_order或误用relaxed导致的跨平台崩溃（尤其在 ARM/PowerPC 上）
std::call_once 单例实现的关键写法
核心是把实例指针声明为 static 局部变量，并用 std::once_flag 控制初始化时机。注意：必须用局部静态变量，不能用全局静态指针 + std::call_once 手动 new —— 后者无法保证析构时机，且易引发内存泄漏或重复释放。
class Singleton {
public:
static Singleton& instance() {
static std::once_flag flag;
static Singleton* inst = nullptr;
std::call_once(flag, []{
inst = new Singleton();
});
return *inst;
}
<p>private:
Singleton() = default;
~Singleton() = default; // 不建议 public 析构，但需确保能被 delete
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
};- 必须将
inst声明为static局部变量，否则每次调用都新建once_flag，失去“只执行一次”的意义 - 不要在 lambda 内捕获外部变量（尤其是
this），lambda 必须是无状态的 - 如果构造函数可能抛异常，
std::call_once会重试，但需确保构造逻辑幂等，或改用带异常处理的封装
DCL 手写版本中三个必改的错误点
若因历史代码或教学需要必须手写 DCL，以下三点不修正，几乎必然出问题：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 单例指针必须是
static std::atomic<Singleton*>，不能是static Singleton*或volatile Singleton*—— 后两者在 C++11 后已无法阻止编译器/处理器重排序 - 第一次检查后必须用
load(std::memory_order_acquire)，new 后必须用store(inst, std::memory_order_release)；漏掉任意一个 order，ARM64 下大概率 crash - 构造函数内严禁调用虚函数、注册到全局 map、或通过其他线程可见方式暴露
this地址 —— 此时对象内存已分配但成员尚未初始化
示例错误写法：if (instance_ == nullptr) { instance_ = new Singleton(); } —— 这不是 DCL，是竞态条件高发区。
什么时候该放弃单例，哪怕性能再好
单例本质是全局状态，它让单元测试变脆弱、依赖难以 mock、模块边界模糊。即使 std::call_once 实现零开销，只要单例持有资源（如数据库连接、配置句柄、日志器），就应优先考虑依赖注入。
- 若单例仅用于缓存计算结果（无状态、无副作用），且访问极频繁（如每微秒调用数次），才值得保留
- 若单例需在程序退出前明确释放（如 flush 日志、关闭 socket），则必须确保析构顺序可控 —— 静态对象析构顺序不可靠，此时应改用 RAII 管理的局部作用域对象
- 多 DLL 场景下，各模块可能各自初始化自己的单例副本，
static局部变量无法跨模块共享
真正难的从来不是怎么写对 DCL，而是判断“这里真的需要全局唯一实例吗”。
