C++11起单例线程安全初始化应使用静态局部变量，因其天然线程安全且只执行一次；避免手写双重检查锁定，注意构造函数不可抛异常，析构时机需与创建方式匹配。
单例的线程安全初始化为什么总出错
多线程环境下，getInstance() 第一次调用时若没加锁或没用正确机制，极大概率触发竞态——两个线程同时判断 instance == nullptr 为真，各自 new 一份对象，导致内存泄漏+行为不可控。
别手写双重检查锁定（DCLP）：C++11 之前确实得靠 pthread_mutex 或 volatile + 汇编屏障，但 C++11 起，静态局部变量的初始化天然线程安全，且只执行一次。
- ✅ 正确做法：直接在
getInstance()里定义静态局部变量static T instance - ❌ 避免手写
if (instance == nullptr) { lock(); if (instance == nullptr) instance = new T(); }—— C++ 中 volatile 不能阻止重排，new可能只构造完指针就赋值，对象实际未构造完成 - ⚠️ 注意：该机制要求构造函数不能抛异常；一旦抛出，下次调用会再次尝试初始化（标准允许，但行为可能不符合预期）
class Logger {
public:
static Logger& getInstance() {
static Logger instance; // C++11 起，这里自动线程安全
return instance;
}
private:
Logger() = default; // 防止外部构造
Logger(const Logger&) = delete;
Logger& operator=(const Logger&) = delete;
};
懒汉式 vs 饿汉式：什么时候该用哪一种
饿汉式（全局静态对象）在程序启动时就构造单例，懒汉式（首次调用才创建）延迟到运行时。二者不是性能高低问题，而是语义和生命周期控制问题。
- ✅ 用饿汉式：单例依赖全局资源（如配置文件、日志句柄），且这些资源在
main()前已就绪；或者你明确需要确保单例在任何静态对象析构前仍有效（避免静态析构顺序问题） - ✅ 用懒汉式：构造开销大（如加载大模型、连接数据库）、或依赖运行时参数（如命令行 flag）、或可能根本不会被用到
- ⚠️ 饿汉式隐患：若单例构造函数中调用了另一个尚未初始化的静态对象（比如某个全局
std::string），会触发未定义行为（静态初始化顺序问题） - ⚠️ 懒汉式隐患：若单例析构函数中又调用了其他静态对象（尤其在 main 返回后），同样可能访问已析构对象
如何让单例支持继承和测试
硬编码 static Logger instance 的写法彻底封死了多态能力——你没法在测试时注入 mock 实现，也没法让 FileLogger 继承自 Logger 并复用单例逻辑。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
核心思路是把“实例存储”和“类型绑定”解耦：用模板+指针管理实例，允许派生类覆盖 getInstance()，同时保持基类接口一致。
- ✅ 推荐方式：基类声明纯虚
getInstance()，派生类各自实现静态实例；或使用 CRTP 模板基类封装通用逻辑 - ✅ 测试友好做法：提供
setInstanceForTest()接口（仅 debug 构建启用），临时替换内部指针 - ❌ 不要让所有单例共用一个全局
void*存储区再强转——类型安全丢失，调试崩溃时毫无线索 - ⚠️ 注意：若用智能指针（如
std::unique_ptr）管理实例，需确保析构时机可控；std::shared_ptr容易因循环引用或意外拷贝延长生命周期
delete 运算符和析构函数怎么配对才不崩
单例对象若由 new 创建，就必须用 delete 销毁；若用静态存储期（如饿汉式或静态局部变量），则**绝不能手动 delete**——它会在程序退出时由运行时自动清理。
- ✅ 静态局部变量（推荐）：无需 delete，析构函数在 main 返回后、全局对象析构阶段自动调用
- ✅ new 出来的懒汉式：必须在程序退出前显式调用
delete instance;，且只能调用一次；常见做法是在atexit()注册清理函数 - ❌ 混用：在静态局部变量版本里写
delete &getInstance()→ 未定义行为，大概率 crash - ⚠️ 析构函数里禁止调用其他单例（尤其是可能已析构的），否则极易触发段错误；如需交互，改用弱引用（
std::weak_ptr）或延迟清理策略
最常被忽略的一点：单例的析构顺序和构造顺序相反，但跨编译单元的静态对象顺序不可控。哪怕你写了完美的单例，只要它依赖另一个源文件里的静态对象，就可能在对方析构后还去访问——这个问题没有银弹，只能靠设计规避。
