1. 为什么需要线程安全的单例模式
单例模式是设计模式中最简单也最常用的一种，它的核心目标是确保一个类在任何情况下都只有一个实例，并提供一个全局访问点。但在多线程环境下，单例模式的实现会面临一些特殊的挑战。
想象一下这样的场景：在一个高并发的电商系统中，购物车服务需要被全局访问，同时又必须保证整个系统只有一份购物车数据。如果多个线程同时尝试获取购物车实例，就可能出现创建多个实例的情况，导致数据不一致。这就是典型的线程安全问题。
在C++中，实现线程安全的单例需要考虑以下几个关键点：
- 延迟初始化(Lazy Initialization)的线程安全问题
- 内存屏障(Memory Barrier)和指令重排问题
- 双重检查锁定(Double-Checked Locking)模式的正确实现
- C++11之后的现代实现方式
2. 传统单例模式实现及其问题
2.1 最简单的单例实现
我们先看一个最基本的单例实现：
cpp复制class Singleton {
public:
static Singleton* getInstance() {
if (instance == nullptr) {
instance = new Singleton();
}
return instance;
}
// 删除拷贝构造函数和赋值运算符
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
private:
Singleton() {} // 私有构造函数
static Singleton* instance;
};
// 静态成员初始化
Singleton* Singleton::instance = nullptr;
这个实现看似简单，但在多线程环境下会有严重问题。当多个线程同时调用getInstance()时，可能会创建多个实例。
2.2 加锁的简单解决方案
最直观的解决方案是加锁：
cpp复制class Singleton {
public:
static Singleton* getInstance() {
std::lock_guard<std::mutex> lock(mutex);
if (instance == nullptr) {
instance = new Singleton();
}
return instance;
}
private:
Singleton() {}
static Singleton* instance;
static std::mutex mutex;
};
这种方法虽然解决了线程安全问题，但每次获取实例都需要加锁，性能开销较大。实际上，我们只需要在第一次创建实例时加锁，后续访问应该可以直接返回实例。
3. 双重检查锁定模式
3.1 DCLP的基本实现
双重检查锁定模式(Double-Checked Locking Pattern)是一种优化方案：
cpp复制class Singleton {
public:
static Singleton* getInstance() {
if (instance == nullptr) { // 第一次检查
std::lock_guard<std::mutex> lock(mutex);
if (instance == nullptr) { // 第二次检查
instance = new Singleton();
}
}
return instance;
}
private:
Singleton() {}
static Singleton* instance;
static std::mutex mutex;
};
这种实现看起来很好：只有在实例未创建时才加锁，创建后直接返回实例。但实际上，在C++03及之前的标准中，这种实现仍然有问题。
3.2 指令重排问题
问题的根源在于指令重排。instance = new Singleton()实际上包含三个步骤：
- 分配内存
- 在内存上构造对象
- 将内存地址赋给instance变量
编译器可能会将步骤2和3重排，导致其他线程看到一个未完全构造的对象。这就是著名的"先发布后构造"问题。
3.3 C++11的解决方案
C++11引入了内存模型和原子操作，我们可以用std::atomic和std::memory_order来解决这个问题：
cpp复制class Singleton {
public:
static Singleton* getInstance() {
Singleton* tmp = instance.load(std::memory_order_acquire);
if (tmp == nullptr) {
std::lock_guard<std::mutex> lock(mutex);
tmp = instance.load(std::memory_order_relaxed);
if (tmp == nullptr) {
tmp = new Singleton();
instance.store(tmp, std::memory_order_release);
}
}
return tmp;
}
private:
Singleton() {}
static std::atomic<Singleton*> instance;
static std::mutex mutex;
};
这种实现既保证了线程安全，又避免了不必要的锁开销。
4. 现代C++的单例模板实现
4.1 使用局部静态变量
C++11之后，最简单的线程安全单例实现是利用局部静态变量的特性：
cpp复制class Singleton {
public:
static Singleton& getInstance() {
static Singleton instance;
return instance;
}
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
private:
Singleton() {}
};
C++11标准保证局部静态变量的初始化是线程安全的。这种实现简洁、安全，是大多数情况下的首选方案。
4.2 通用单例模板类
为了复用单例模式，我们可以实现一个线程安全的单例模板类：
cpp复制template <typename T>
class Singleton {
public:
static T& getInstance() {
static T instance;
return instance;
}
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
protected:
Singleton() = default;
~Singleton() = default;
};
使用方式：
cpp复制class MyClass : public Singleton<MyClass> {
friend class Singleton<MyClass>;
private:
MyClass() {} // 构造函数私有
// 其他成员...
};
4.3 模板实现的注意事项
- 派生类必须将Singleton设为友元，因为Singleton需要访问派生类的私有构造函数
- 派生类的构造函数必须私有或保护
- 如果需要传递构造参数，模板需要进一步扩展
- 要考虑单例的生命周期管理，特别是依赖关系
5. 单例模式的高级话题
5.1 单例的销毁时机
局部静态变量的销毁顺序与构造顺序相反，且在程序退出时进行。如果单例之间有依赖关系，可能会出现问题。一种解决方案是使用智能指针：
cpp复制template <typename T>
class Singleton {
public:
static std::shared_ptr<T> getInstance() {
static std::shared_ptr<T> instance(new T);
return instance;
}
protected:
Singleton() = default;
virtual ~Singleton() = default;
};
5.2 单例与依赖注入
在现代软件设计中，过度使用单例可能不利于测试和模块解耦。可以考虑使用依赖注入框架来管理"单例"对象，这样既能保证全局唯一性，又便于测试。
5.3 单例的性能考量
即使是线程安全的单例实现，不同方案的性能差异也很大。在极端性能敏感的场景下，可以考虑以下优化：
- 使用pthread_once或std::call_once
- 饿汉式单例（在程序启动时就初始化）
- 无锁实现（适用于特定架构）
6. 实际项目中的经验分享
在实际项目中实现和使用线程安全单例时，有几个容易踩的坑：
-
跨DLL的单例问题：在Windows平台上，如果单例实现位于DLL中，不同模块可能有自己的静态变量实例。解决方案是显式导出单例实例。
-
单例的单元测试：由于单例的全局性，单元测试中可能需要重置单例状态。可以添加一个reset方法（仅用于测试）。
-
单例的递归调用：如果单例的构造函数中又调用了其他单例，可能导致死锁或未定义行为。要特别注意单例之间的依赖关系。
-
内存泄漏检测：某些内存检测工具可能会将单例报告为内存泄漏。需要配置工具忽略这些合法"泄漏"。
-
日志系统的单例实现：日志系统是典型的单例应用场景，但要注意多线程下的性能问题。可以采用队列+后台线程的设计模式。