单例模式（Singleton）是软件设计模式之一，其核心目标是保证一个类只有一个实例，并为整个系统提供统一的访问点。随着多线程编程的普及，单例模式在多线程环境下的实现尤为重要，因为不当的实现可能导致竞态条件、重复实例化或性能瓶颈。本文将从C++11开始的标准特性出发，介绍几种常见且线程安全的单例实现方式，并讨论其优缺点、适用场景以及可能的陷阱。
一、背景：为什么多线程需要特殊处理？
在单线程环境下，最简单的单例实现就是在构造函数外部静态声明实例，并在第一次访问时创建：
class SimpleSingleton {
public:
static SimpleSingleton& getInstance() {
static SimpleSingleton instance;
return instance;
}
private:
SimpleSingleton() = default;
// 复制构造和赋值禁止
SimpleSingleton(const SimpleSingleton&) = delete;
SimpleSingleton& operator=(const SimpleSingleton&) = delete;
};这段代码在 C++11 之后是线程安全的，因为编译器保证了 static 变量的初始化是“只一次”的，并且在多线程环境下是互斥的（magic statics）。然而在 C++98/03 环境下，该实现不保证线程安全，导致在多线程首次访问时可能出现并发初始化。
如果你使用的是老版本编译器，或者想要更细粒度的控制，仍需要显式地实现线程同步。
二、使用互斥锁（std::mutex）的双重检查锁（Double-Check Locking）
双重检查锁是一种常见模式，旨在避免每次访问实例都产生锁开销。
#include <mutex>
class DCLSingleton {
public:
static DCLSingleton& getInstance() {
if (!instance_) { // 第一次检查（无锁）
std::lock_guard<std::mutex> lock(mutex_);
if (!instance_) { // 第二次检查（有锁）
instance_ = new DCLSingleton();
}
}
return *instance_;
}
// 复制构造与赋值禁止
DCLSingleton(const DCLSingleton&) = delete;
DCLSingleton& operator=(const DCLSingleton&) = delete;
~DCLSingleton() { delete instance_; }
private:
DCLSingleton() = default;
static DCLSingleton* instance_;
static std::mutex mutex_;
};
DCLSingleton* DCLSingleton::instance_ = nullptr;
std::mutex DCLSingleton::mutex_;优点
- 延迟初始化：只有第一次真正需要时才创建实例。
- 后续访问无锁：性能相对高。
缺点
- 实现复杂：需要手动管理指针和锁。
- 存在微妙的内存顺序问题：在 C++11 之前，可能出现“指针被写入后还未构造完毕”的可见性问题。使用
std::atomic或std::atomic<...>可以解决。
提示：在 C++11 之后，使用
std::atomic<...>进行指针的原子读写，或者直接使用std::call_once（见下文）更安全。
三、使用 std::call_once 与 std::once_flag
std::call_once 通过一次性执行函数来保证线程安全的初始化，既避免了多余的锁竞争，又不需要显式地处理原子性。
#include <mutex>
class CallOnceSingleton {
public:
static CallOnceSingleton& getInstance() {
std::call_once(initFlag_, []() {
instance_ = new CallOnceSingleton();
});
return *instance_;
}
// 复制构造与赋值禁止
CallOnceSingleton(const CallOnceSingleton&) = delete;
CallOnceSingleton& operator=(const CallOnceSingleton&) = delete;
private:
CallOnceSingleton() = default;
static CallOnceSingleton* instance_;
static std::once_flag initFlag_;
};
CallOnceSingleton* CallOnceSingleton::instance_ = nullptr;
std::once_flag CallOnceSingleton::initFlag_;优点
- 极简代码：不需要手动锁定、检查指针。
- 线程安全：
std::call_once确保初始化函数只执行一次，即使有多个线程同时调用。 - 性能：后续访问不需要锁。
缺点
- 内存管理：需要手动释放
instance_（在进程结束前），或者改用智能指针。 - 不支持 C++98：此特性依赖 C++11。
四、使用 C++11 的局部静态变量（Magic Statics）
正如在第一个例子中所展示的，C++11 引入了对局部静态变量初始化的线程安全保证：
class StaticLocalSingleton {
public:
static StaticLocalSingleton& getInstance() {
static StaticLocalSingleton instance; // 自动线程安全初始化
return instance;
}
private:
StaticLocalSingleton() = default;
StaticLocalSingleton(const StaticLocalSingleton&) = delete;
StaticLocalSingleton& operator=(const StaticLocalSingleton&) = delete;
};何时使用？
- 最简单：不需要手动锁、指针管理。
- 适合大多数 C++11+ 项目：符合标准，易维护。
需要注意的细节
- 销毁顺序：静态对象在程序结束时按逆序销毁，可能导致依赖关系错误（如“静态对象销毁顺序问题”）。如果单例需要在其他静态对象之后销毁，考虑使用
std::shared_ptr并在getInstance()时创建。
五、智能指针与懒汉式单例
结合 std::shared_ptr 可以简化内存管理，并让单例支持多重释放。
class SmartSingleton {
public:
static std::shared_ptr <SmartSingleton> getInstance() {
std::call_once(initFlag_, []() {
instance_ = std::make_shared <SmartSingleton>();
});
return instance_;
}
private:
SmartSingleton() = default;
static std::shared_ptr <SmartSingleton> instance_;
static std::once_flag initFlag_;
};
std::shared_ptr <SmartSingleton> SmartSingleton::instance_ = nullptr;
std::once_flag SmartSingleton::initFlag_;- 现在即使你忘记手动删除实例，也不会导致内存泄漏。
- 多个线程共享同一实例时，生命周期自动管理。
六、实际场景与最佳实践
| 场景 | 推荐实现 |
|---|---|
| 仅在 C++11+ 环境下 | 局部静态变量（Magic Statics） |
| 需要显式销毁或与资源管理耦合 | std::call_once + 智能指针 |
| 需要在 C++98/03 下兼容 | 双重检查锁 + 原子指针 |
| 需要最小化锁开销 | std::call_once（无后续锁） |
| 需要对单例生命周期做复杂控制（如延迟销毁） | 结合 std::shared_ptr 与 weak_ptr |
常见陷阱
- “饿汉式”单例：在全局对象初始化时创建实例，可能导致“静态对象销毁顺序”错误，尤其是在多模块项目中。
- 线程安全问题：若未使用 C++11 之后的特性，手动实现的单例很容易出现竞态条件。
- 不必要的复制：一定要删除拷贝构造和赋值运算符，否则会破坏单例约束。
- 内存泄漏：若使用裸指针，记得在
atexit或main结束前手动delete。 - 依赖注入：在测试环境中，单例往往难以替换，建议使用抽象接口与工厂模式，或利用
std::function注入自定义实例。
七、结语
在 C++ 里实现线程安全的单例并非一件难事。随着 C++11 及其之后的标准特性（std::call_once、std::once_flag、局部静态变量的线程安全初始化等）的加入，代码可以更简洁、更安全。根据项目的编译环境、性能要求以及可维护性，选择最合适的实现方式即可。
温馨提示：虽然单例模式在某些场景下非常有用，但在现代 C++ 开发中，过度使用单例往往导致代码耦合度过高、难以测试。若可行，优先考虑使用依赖注入、服务定位器或其他可组合的设计模式。