c++11中首选static局部变量实现单例，因其初始化线程安全且仅一次；std::call_once仅用于需传参、异常重试等static local无法满足的场景；dclp易因内存序错误导致未定义行为。
为什么 std::call_once + static local 变量是首选
因为 C++11 标准明确保证：函数内 static 局部变量的初始化是线程安全的，且仅执行一次。这比手写双重检查锁定（DCLP）更简洁、更可靠，也绕过了经典 DCLP 中 memory_order 配置错误导致的重排序问题。
常见错误现象：std::call_once 被误用在非静态上下文中，或配合非 static 变量，导致每次调用都新建实例；或者仍用老式 DCLP 写法，但漏掉 std::atomic 和正确的内存序，结果在优化级别升高后崩溃或返回未构造完成的对象。
- 必须把实例声明为函数内
static局部变量，不是类静态成员 -
std::call_once仅用于需要延迟初始化但又不能用 static local 的极少数场景（比如要传参构造） - 不要手动 new +
std::atomic<t></t>+memory_order_acquire/release—— 复杂且极易出错
class Singleton {
public:
static Singleton& instance() {
static Singleton inst; // ✅ 线程安全，C++11 起保证
return inst;
}
private:
Singleton() = default;
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
};什么时候必须用 std::call_once
当你无法用 static local 变量时：比如构造函数需要运行时参数，或需捕获异常并重试，或需与外部资源（如配置文件、网络）联动初始化。
使用场景：服务启动时加载配置单例、数据库连接池首次初始化、日志器带自定义格式器构造。
立即学习“C++免费学习笔记（深入）”；
- 必须搭配
std::once_flag成员或全局变量，不能在每次调用中新建 - 初始化逻辑必须是无状态的纯函数，否则多线程下可能因竞态触发多次执行
- 若初始化抛异常，
std::call_once会将该 flag 置为“已调用”，后续调用直接返回，不会重试
class ConfigSingleton {
static ConfigSingleton* instance_;
static std::once_flag init_flag;
explicit ConfigSingleton(const std::string& path);
public:
static ConfigSingleton& instance(const std::string& path) {
std::call_once(init_flag, [&]() {
instance_ = new ConfigSingleton(path); // 注意：需自行管理生命周期
});
return *instance_;
}
};DCLP 为什么容易踩坑（即使你坚持要写）
双重检查锁定不是“加个锁再判断一次”就完事——它依赖精确的内存屏障语义。C++11 前几乎没人写对；C++11 后仍有人用 volatile 代替 std::atomic，或漏掉 memory_order_acquire，导致编译器/处理器重排构造顺序，让其他线程看到未初始化完成的对象指针。
典型错误现象：segfault 或读到垃圾值，尤其在 GCC -O2 / Clang -O3 下高频复现；Valgrind 报 uninitialized memory read；ASan 不报错但行为不稳定。
-
volatile对线程同步无效，必须用std::atomic<t></t> - 第一次检查用
load(std::memory_order_acquire)，new 后赋值用store(std::memory_order_release) - 第二次检查（锁内）必须再次 load，且不能省略
- 析构和销毁时机完全由你负责，static local 方案自动处理
单例生命周期与析构风险
static local 变量的析构发生在 main() 返回后、程序退出前，按构造逆序执行。如果其他静态对象（比如全局 logger）在析构期访问该单例，就会触发未定义行为——此时单例可能已被析构。
这个问题在跨动态库、插件系统、或使用 atexit 注册清理函数时特别明显。
- 避免在其他静态对象的析构函数中调用
Singleton::instance() - 若必须支持“可销毁”，改用
std::shared_ptr+std::weak_ptr管理，但会失去“全局唯一强引用”的语义 - 最稳妥的做法：接受“进程生命周期内不析构”，即不提供显式 destroy 接口
真正难的不是怎么写线程安全的构造，而是怎么让整个程序的静态生命周期不打架。这点常被忽略，直到上线后偶发 crash 才去翻 atexit 表。
