std::call_once + std::once_flag 是首选，因它是c++11唯一明确保证线程安全的单例初始化机制，避免dclp手动同步和静态局部变量在旧编译器中的问题。
为什么 std::call_once + std::once_flag 是首选
因为它是 C++11 标准里唯一被明确保证线程安全的单例初始化机制，不依赖双重检查锁（DCLP）的手动同步，也避开静态局部变量在旧编译器中的潜在问题。
常见错误现象：std::call_once 被多次调用却没报错，但单例构造函数被执行了两次——通常是因为 std::once_flag 成员被误声明为局部变量（每次调用都新建），而非 static 或类静态成员。
-
std::once_flag必须是 static（全局/函数内静态/类静态成员），否则失效 - 传给
std::call_once的 callable 不能捕获局部对象地址，否则可能引发析构后使用 - 构造函数抛异常时，
std::call_once会重试下一次调用——这是标准行为，不是 bug
class Singleton {
public:
static Singleton& instance() {
std::call_once(flag_, []{ instance_.reset(new Singleton); });
return *instance_;
}
private:
Singleton() = default;
static std::unique_ptr<Singleton> instance_;
static std::once_flag flag_;
};
静态局部变量写法到底安不安全
从 C++11 开始，静态局部变量的初始化是线程安全的，且只执行一次——这是标准强制要求，不是编译器扩展。
但容易踩的坑：有人以为“只要用了 static local 就绝对安全”，却忽略了析构时机和生命周期管理。
立即学习“C++免费学习笔记（深入）”；
- 静态局部变量在首次控制流经过其定义时初始化，且初始化过程自带互斥，无需额外锁
- 析构发生在程序退出时、按构造逆序进行，若单例持有资源（如线程、文件句柄），且其他静态对象析构时又依赖它，就可能 crash
- 某些嵌入式或裸机环境（无完整 C++ 运行时）不支持该特性，需确认工具链是否符合 C++11
Singleton& Singleton::instance() {
static Singleton inst; // ✅ 线程安全初始化
return inst;
}
双重检查锁（DCLP）为什么现在不推荐手写
因为手动实现极易出错：内存序（memory order）漏设、volatile 误用、编译器重排未抑制，都会导致读到未构造完成的对象。
典型错误现象：多线程下偶尔返回非空指针，但访问成员时 segfault 或读到垃圾值。
-
volatile对线程同步完全无效，C++ 标准不承认它能防止重排或提供原子性 - 必须用
std::atomic<t></t>替代原始指针，并显式指定memory_order_acquire/memory_order_release - 即使写对了，性能也不比
std::call_once或静态局部变量更好，反而更难维护
单例析构顺序失控的真实风险
这不是理论问题。当单例内部持有一个 std::thread，而另一个静态对象（比如日志器）在析构时尝试向该单例发消息，就可能在线程已 join 或已销毁后访问它。
根本原因：C++ 不规定跨编译单元的静态对象析构顺序。
- 避免在单例析构函数中调用其他静态对象的接口
- 若必须交互，改用 “construct on first use” + 显式
destroy()控制时机 - 更稳妥的做法：让单例生命周期绑定到 main() 结束前，不依赖静态析构——比如用
std::shared_ptr管理，外部持有强引用
