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 <memory>
#include <mutex>
class ConfigurableSingleton {
public:
static ConfigurableSingleton& getInstance(const std::string& configPath) {
// 第一次检查（无锁，快速返回）
if (instance_ != nullptr) {
return *instance_;
}
std::lock_guard<std::mutex> lock(mutex_);
// 第二次检查（加锁后再次确认）
if (instance_ == nullptr) {
instance_ = std::make_unique<ConfigurableSingleton>(configPath);
}
return *instance_;
}
static void destroy() {
std::lock_guard<std::mutex> lock(mutex_);
instance_.reset();
}
private:
explicit ConfigurableSingleton(const std::string& path) {
// 加载配置等耗时操作
}
ConfigurableSingleton(const ConfigurableSingleton&) = delete;
ConfigurableSingleton& operator=(const ConfigurableSingleton&) = delete;
static std::unique_ptr<ConfigurableSingleton> instance_;
static std::mutex mutex_;
};
// 定义静态成员
std::unique_ptr<ConfigurableSingleton> ConfigurableSingleton::instance_;
std::mutex ConfigurableSingleton::mutex_;
⚠️ 注意：必须手动调用 destroy() 避免程序退出前未释放资源；若不想手动管理，可改用静态局部变量+工厂函数封装参数（更推荐）。
立即学习“C++免费学习笔记（深入）”；
常见误写与陷阱
-
手写 double-checked locking（DCLP）不用 memory_order：C++11前易出错，现在应优先用
std::call_once或静态局部变量 -
用 new 分配但忘了 delete：导致内存泄漏；建议统一用
std::unique_ptr管理 - 把 getInstance 声明为 const 成员函数：错误！获取实例本身是可变操作（首次构造会修改状态）
- 在构造函数里调用 getInstance：引发死锁或未定义行为（递归初始化静态变量）
什么情况下不该用单例？
单例不是万能解药。以下情况建议绕开：
- 只是想共享数据 → 用普通全局变量或命名空间内静态对象更轻量
- 需要多种配置的多个实例（如多个数据库连接）→ 改用工厂 + 对象池
- 测试困难（全局状态干扰单元测试）→ 考虑依赖注入（传入接口引用）
- 模块间强耦合 → 单例会隐式引入依赖，破坏可维护性
基本上就这些。单例本身不复杂，但用得是否恰当，往往暴露架构思考深度。
