首选 static 局部变量配合 std::call_once，因其线程安全、懒加载、无内存泄漏且 C++11 原生支持；手写 DCLP 易因内存序问题导致未初始化对象访问。
为什么 std::call_once + static 局部变量是首选
因为线程安全、懒加载、无内存泄漏，且 C++11 起原生支持，不用手写双重检查锁（DCLP）这种易出错的方案。手写 DCLP 在缺少 volatile 和正确内存序时，可能在多核 CPU 上看到未初始化对象——不是概率低，是必然发生，只是时机难复现。
实操建议：
-
static局部变量的初始化在首次调用时发生，且标准保证其线程安全（背后调用std::call_once） - 构造函数必须是
private，禁止外部new或栈实例化 - 返回引用比返回指针更安全：避免误判
nullptr，也规避裸指针生命周期管理问题
class Logger {
public:
static Logger& instance() {
static Logger inst; // 线程安全的延迟初始化
return inst;
}
Logger(const Logger&) = delete;
Logger& operator=(const Logger&) = delete;
private:
Logger() = default; // 可含实际初始化逻辑
};
什么时候必须用 std::shared_ptr + std::atomic 手动管理
当单例需要支持显式销毁（比如测试中重置状态）、或需跨 DLL/so 边界共享（Windows 下静态局部变量的析构顺序在 DLL 卸载时不可靠）时，static 局部变量就不够用了。
常见错误现象：Access violation 或 pure virtual method called —— 某个模块析构后，另一模块仍试图访问已销毁的单例。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 用
std::shared_ptr管理堆内存，配合std::atomic存储原始指针，避免std::shared_ptr自身读写竞争 - 销毁入口必须全局唯一，且确保所有持有者都释放完毕后再调用
reset() - 不要在单例析构函数里调用其他单例——极易形成循环依赖和析构顺序崩溃
getInstance() 返回指针还是引用？关键看所有权语义
返回引用隐含“永不为空”契约；返回指针则开放了 nullptr 判断空间，但也引入空指针解引用风险。多数场景下，引用更符合单例本意：它就该存在，且只存在一次。
使用场景差异：
- 配置类、日志器、全局事件总线 → 用引用，启动失败应直接
abort()或抛异常，不给“容错”假象 - 可选硬件设备抽象（如摄像头驱动）→ 可考虑返回
std::optional<:reference_wrapper>></:reference_wrapper>或std::shared_ptr<t></t>，但这就已偏离经典单例语义
性能影响：引用无拷贝开销；指针多一次解引用，但现代 CPU 分支预测下几乎无感。真正代价是心理负担——开发者会下意识加空检查，反而掩盖设计缺陷。
Linux 下 fork() 后单例失效的坑怎么填
子进程复制了父进程的内存页，包括已初始化的 static 局部变量地址，但后续对单例状态的修改不会同步回父进程。更糟的是，若单例内部持有了文件描述符、socket 或 pthread mutex，fork() 后父子进程共用同一 fd，却各自有独立 mutex 实例——导致死锁或数据错乱。
这不是“要不要用单例”的问题，而是“是否允许 fork 后继续用”的架构决策。
实操建议：
- 服务进程明确禁用
fork()（如在 main 开头设prctl(PR_SET_NO_NEW_PRIVS, 1)并检查getpid() == getppid()） - 若必须支持 fork（如传统守护进程），单例内部所有资源必须可重初始化：例如用
pthread_atfork()注册prepare/parent/child回调，重置 mutex、重连 socket - 避免在单例构造函数里打开文件或绑定端口——这些操作无法安全 fork 继承
最常被忽略的一点：即使你没写 fork()，第三方库（如 glibc 的 getaddrinfo()、某些日志库的异步刷盘线程）也可能悄悄调用它。真要健壮，得从资源模型上放弃“全局唯一状态”的执念，改用显式传参或 context 对象。
