std::call_once比双重检查锁更可靠，因其由标准库保证“仅执行一次”，并自动处理内存序、编译器/CPU重排等问题；而DCLP易因遗漏内存栅栏或非原子访问导致未完全构造对象被读取。
std::call_once 为什么比双重检查锁更可靠
因为 std::call_once 由标准库保证“仅执行一次”，且内部处理了内存序、编译器重排、CPU 指令重排等所有并发边界问题，不需要手动插入 std::memory_order 或 volatile。而手写双重检查锁（DCLP）极易出错：比如漏掉 std::atomic_thread_fence，或把 instance 声明为非原子指针却用 load(relaxed) 读取，导致看到未完全构造的对象。
实操建议：
- 必须搭配
std::once_flag静态变量使用，不能局部声明后传入 —— 否则每次调用都新建 flag，失去“once”语义 -
std::call_once抛异常时，flag 仍被标记为“已调用”，后续调用直接返回，不会重试；若需重试，得自己封装逻辑 - 初始化函数里不要做耗时操作（如文件 IO、网络请求），否则所有首次调用线程都会阻塞等待
std::atomic<:shared_ptr>> 方案的陷阱在哪
用原子智能指针实现单例看似简洁，但默认的 std::shared_ptr 赋值不是原子的 —— 它内部包含控制块指针和对象指针两部分，直接赋值会引发数据竞争。必须用 std::atomic_store / std::atomic_load 显式操作，且 T* 类型需满足 trivially copyable 才能安全原子化。
常见错误现象：std::atomic_load 返回空指针，但紧接着解引用就 crash —— 实际是 load 到了中间态（控制块已建好，对象尚未构造完）。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 声明必须是
static std::atomic<:shared_ptr>> instance_{};</:shared_ptr>，不能是std::shared_ptr<logger></logger>再套一层 atomic 变量 - 首次写入必须用
std::atomic_store(&instance_, std::make_shared<logger>());</logger>，不能用instance_.store(...)（C++20 前不支持该成员函数） - 读取必须用
std::atomic_load(&instance_)，不能直接*instance_—— 这会触发隐式转换，绕过原子访问
为什么推荐 std::call_once + 静态局部变量组合
C++11 起，函数内静态局部变量的初始化已是线程安全的（由编译器生成 __cxa_guard 或类似机制保障），它底层就依赖 std::call_once 语义。相比裸用 std::call_once，它更简洁、无额外状态变量、且天然支持延迟构造。
性能影响很小：首次调用有轻微开销（一次原子读+可能一次锁），之后就是普通指针读取，无任何同步成本。
示例写法：
class Config {
public:
static Config& getInstance() {
static Config instance; // 线程安全初始化，无需额外 once_flag
return instance;
}
private:
Config() = default;
};
注意：该方案要求构造函数不能抛异常。一旦抛出，下次调用会再次尝试构造 —— 这和 std::call_once 行为不同，属于容易被忽略的关键差异。
析构时机与生命周期管理的盲区
所有上述方案都只解决“创建”的线程安全，不解决“销毁”的顺序问题。静态对象析构在 main 返回后发生，多线程环境下无法保证单例析构时其他线程已退出 —— 若有线程仍在调用 getInstance()，就可能访问已析构对象。
根本原因：C++ 标准不保证静态对象析构的线程安全性，也无机制通知其他线程“我即将销毁”。
实操建议：
- 服务类单例（如日志、配置）尽量设计为“永不析构”，即用原始指针 +
new分配，不 delete - 若必须析构，应在程序明确进入 shutdown 阶段后，由主线程统一调用
reset()或显式销毁，并确保所有工作线程已 join - 避免在全局对象的构造/析构函数中调用单例 —— 极易引发静态初始化顺序 fiasco
