17370845950

C++单例模式最安全写法是C++11起用局部静态变量实现，线程安全且自动管理生命周期；带参数时推荐静态局部变量+工厂函数，避免双重检查锁定陷阱；非必要场景应优先考虑依赖注入或全局对象。

单例模式在C++中核心目标是：确保一个类只有一个实例，并提供全局访问点。它不难写，但容易写错——尤其在多线程、析构顺序和懒加载场景下。

最安全的现代C++写法（C++11起推荐）

利用局部静态变量的“首次调用时初始化”和线程安全特性，代码简洁且天然线程安全：

class Singleton {
public:
    static Singleton& getInstance() {
        static Singleton instance; // C++11保证：首次调用时构造，且线程安全
        return instance;
    }

    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;

private:
    Singleton() = default; // 私有构造，禁止外部创建
    ~Singleton() = default; // 析构可公开或私有，按需决定
};

✅ 优点：无锁、无内存泄漏风险、自动管理生命周期、符合RAII；
❌ 注意：析构时机由程序结束时静态对象销毁顺序决定，若其他静态对象依赖它，可能出问题（称为“静态初始化顺序惨案”）。

带参数的单例（延迟构造 + 参数传递）

如果构造函数需要参数（比如配置路径、日志级别），不能直接用静态局部变量。常用方案是“双重检查锁定 + 智能指针”：

#include 
#include 

class ConfigurableSingleton {
public:
    static ConfigurableSingleton& getInstance(const std::string& configPath) {
        // 第一次检查（无锁，快速返回）
        if (instance_ != nullptr) {
            return *instance_;
        }

        std::lock_guard lock(mutex_);
        // 第二次检查（加锁后再次确认）
        if (instance_ == nullptr) {
            instance_ = std::make_unique(configPath);
        }
        return *instance_;
    }

    static void destroy() {
        std::lock_guard lock(mutex_);
        instance_.reset();
    }

private:
    explicit ConfigurableSingleton(const std::string& path) {
        // 加载配置等耗时操作
    }

    ConfigurableSingleton(const ConfigurableSingleton&) = delete;
    ConfigurableSingleton& operator=(const ConfigurableSingleton&) = delete;

    static std::unique_ptr instance_;
    static std::mutex mutex_;
};

// 定义静态成员
std::unique_ptr ConfigurableSingleton::instance_;
std::mutex ConfigurableSingleton::mutex_;

⚠️ 注意：必须手动调用 destroy() 避免程序退出前未释放资源；若不想手动管理，可改用静态局部变量+工厂函数封装参数（更推荐）。

常见误写与陷阱

• 手写 double-checked locking（DCLP）不用 memory_order：C++11前易出错，现在应优先用 std::call_once 或静态局部变量
• 用 new 分配但忘了 delete：导致内存泄漏；建议统一用 std::unique_ptr 管理
• 把 getInstance 声明为 const 成员函数：错误！获取实例本身是可变操作（首次构造会修改状态）
• 在构造函数里调用 getInstance：引发死锁或未定义行为（递归初始化静态变量）

什么情况下不该用单例？

单例不是万能解药。以下情况建议绕开：

• 只是想共享数据 → 用普通全局变量或命名空间内静态对象更轻量
• 需要多种配置的多个实例（如多个数据库连接）→ 改用工厂 + 对象池
• 测试困难（全局状态干扰单元测试）→ 考虑依赖注入（传入接口引用）
• 模块间强耦合 → 单例会隐式引入依赖，破坏可维护性

基本上就这些。单例本身不复杂，但用得是否恰当，往往暴露架构思考深度。