17370845950

C++11起static局部变量初始化线程安全，编译器自动生成双重检查锁，确保首次调用时仅一个线程执行构造，其余等待；但仅限初始化过程，内部状态读写仍需手动同步。

为什么 static 局部变量能保证线程安全？

从 C++11 开始，static 局部变量的初始化是线程安全的——标准明确要求编译器生成带双重检查锁（double-checked locking）语义的代码。这意味着第一次调用时，多个线程同时进入函数，也只会有一个线程执行构造，其余阻塞等待，且无需手动加锁。

这是 Meyers' Singleton 的核心依据，也是它比手写 std::call_once 或互斥量更简洁的根本原因。

• 必须使用 C++11 或更高标准（-std=c++11 及以上）
• 构造函数不能是 explicit（否则无法隐式构造）
• 不要在构造函数中抛异常：若初始化失败，后续调用会再次尝试，但行为未定义（可能 crash 或重复抛出）

getInstance() 的标准写法与常见误写

正确实现仅需一个函数、一个静态局部变量，返回引用：

class Singleton {
public:
    static Singleton& getInstance() {
        static Singleton instance;  // C++11 线程安全初始化
        return instance;
    }

private:
    Singleton() = default;           // 防止外部构造
    ~Singleton() = default;          // 非虚析构（无继承时 OK）
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;
};

常见错误包括：

• 返回 Singleton* 并在堆上 new：失去自动生命周期管理，易内存泄漏，且破坏线程安全前提（new 本身不安全）
• 把 static Singleton instance; 提到类外全局作用域：C++98 风格，不保证线程安全（尤其 DLL/so 加载顺序复杂时）
• 在 getInstance() 中加 std::mutex：冗余，且可能引入死锁（比如构造函数内又调用 getInstance()）

析构时机与静态对象生命周期风险

静态局部变量的析构发生在 main() 返回后、程序退出前，按构造逆序执行。这意味着：

• 单例对象在 main() 结束后才被销毁，其他静态对象若在析构期访问它，会触发未定义行为（已析构访问）
• 若单例持有资源（如线程、文件句柄、网络连接），应在析构函数中显式清理，不能依赖 RAII 自动释放（因为析构顺序不可控）
• 跨 DLL 边界使用时，不同模块可能看到不同实例（Windows 下每个 DLL 有独立静态变量空间），此时需导出符号或改用指针+显式初始化

什么时候不该用 Meyers' Singleton？

它简单可靠，但不是万能解。以下情况需谨慎或换方案：

• 需要控制析构顺序（例如日志单例必须最后销毁）→ 改用 std::unique_ptr + std::call_once 手动管理生命周期
• 构造开销极大，且 90% 场景下根本不会用到 → 考虑延迟初始化 + 原子指针（std::atomic），避免首次调用卡顿
• 测试时需替换实现（mock）→ Meyers 版本无法重置或注入，应改用依赖注入或工厂接口
• 目标平台不支持 C++11（如某些嵌入式环境）→ 必须退回到 Pthreads / Win32 API + 双重检查锁

最常被忽略的一点：Meyers 单例的“线程安全”仅限于初始化过程。如果单例内部状态可变，所有读写操作仍需自行同步（比如加 std::mutex 或用原子变量）。