在多线程程序中，单例模式常被用来确保一个类只有一个实例并且在全局范围内可访问。传统的实现方式往往涉及到双重检查锁定（Double-Check Locking）或使用静态局部变量，但在C++11之前的实现很难保证线程安全。自C++11开始，编译器对局部静态变量的初始化提供了线程安全的保证，同时 std::call_once 也为“一次性初始化”提供了更灵活的工具。本文将详细介绍两种基于C++11的线程安全单例实现方式，并对比其优缺点。
1. 基于局部静态变量的实现
class Singleton {
public:
static Singleton& instance() {
static Singleton instance; // C++11 线程安全
return instance;
}
// 禁止拷贝与移动
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
Singleton(Singleton&&) = delete;
Singleton& operator=(Singleton&&) = delete;
void doSomething() {
// 业务逻辑
}
private:
Singleton() = default;
~Singleton() = default;
};1.1 工作原理
- 当
instance()被第一次调用时，static Singleton instance;会触发对象的构造。 - C++11 标准保证了该构造过程对所有线程是互斥的：如果多个线程同时进入
instance()，只有一个线程会真正执行构造，其余线程会等待直到构造完成，然后共享同一个实例。 - 之后再次调用
instance()时，局部静态对象已初始化，直接返回，性能低开销。
1.2 优点
- 代码简洁：只需一行静态局部变量，易于维护。
- 性能高：构造一次，后续只需一次访问，几乎没有锁开销。
- 资源释放：程序结束时，静态局部对象会自动析构，避免显式销毁的错误。
1.3 局限
- 延迟初始化：如果单例在程序生命周期后期才被访问，可能导致资源未及时释放或延迟启动。
- 无法自定义销毁顺序：所有静态局部对象的析构顺序是未定义的，可能导致在析构期间使用已被销毁的单例。
2. 基于 std::call_once 的实现
#include <mutex>
class Singleton {
public:
static Singleton& instance() {
std::call_once(initFlag, []() {
instancePtr = new Singleton();
});
return *instancePtr;
}
static void destroy() {
std::call_once(destroyFlag, []() {
delete instancePtr;
instancePtr = nullptr;
});
}
// 禁止拷贝与移动
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
Singleton(Singleton&&) = delete;
Singleton& operator=(Singleton&&) = delete;
void doSomething() {
// 业务逻辑
}
private:
Singleton() = default;
~Singleton() = default;
static Singleton* instancePtr;
static std::once_flag initFlag;
static std::once_flag destroyFlag;
};
// 静态成员定义
Singleton* Singleton::instancePtr = nullptr;
std::once_flag Singleton::initFlag;
std::once_flag Singleton::destroyFlag;2.1 工作原理
std::call_once确保传入的 lambda 只会被执行一次，即使有多个线程并发调用instance()。instancePtr用于保存单例对象的指针。首次调用时创建，后续返回相同指针。destroy()提供显式销毁单例的方法，保证销毁顺序可控，适合需要在程序结束前释放资源的场景。
2.2 优点
- 可控销毁：可在程序退出前显式调用
destroy()，确保资源按期释放。 - 延迟初始化：与局部静态变量类似，首次访问时才实例化，避免不必要的开销。
- 多线程安全：
std::call_once在多线程环境下完全安全。
2.3 局限
- 显式销毁：需要手动调用
destroy()，如果忘记会导致资源泄漏。 - 额外开销：每次访问都需要经过
std::call_once的检查，虽然开销极小，但比直接访问局部静态变量略高。 - 静态成员：需要定义静态指针和 once_flag，稍显繁琐。
3. 选择哪种实现？
| 需求 | 推荐实现 |
|---|---|
| 简单、只需一次性创建、无需手动销毁 | 局部静态变量 |
| 需要显式销毁、可能在多线程退出前释放资源 | std::call_once |
| 需要在单例初始化时执行额外逻辑（例如依赖其他单例） | std::call_once |
4. 常见陷阱与最佳实践
-
避免在单例构造中使用全局单例
单例构造函数中不应访问同一类型的其它单例，否则可能导致初始化顺序问题。 -
使用
inline成员函数
对于 C++17 及以上，inline关键字可使函数在多个翻译单元中被多次定义，避免链接错误。 -
考虑多继承
若单例是多继承的基类，std::call_once的实现更安全，防止不同基类的单例同时初始化导致冲突。 -
线程优先级
在极高并发环境下，建议使用std::call_once，因为其实现通常基于原子操作，性能更可预期。
5. 小结
C++11 的局部静态变量与 std::call_once 为实现线程安全的单例模式提供了两种简单而可靠的方案。前者以简洁高效为特点，适合大多数情况；后者则在资源释放控制上更为灵活，适用于需要显式销毁或初始化依赖更复杂的场景。根据项目需求与代码风格选择合适的实现方式，既能保证线程安全，又能保持代码的可维护性。