在 C++ 项目中，经常会遇到需要全局唯一对象的情况，比如日志系统、配置管理器或数据库连接池。传统的单例实现方式是使用静态局部变量或双重检查锁定（Double-Check Locking，DCL）等技术。然而，随着多线程环境的普及，单例实现必须保证线程安全，并尽可能减少性能开销。本文将介绍几种常见的线程安全单例实现方法，并对比它们的优缺点，帮助你在实际项目中选择合适的方案。
1. 传统静态局部变量（C++11 之后）
class Logger {
public:
static Logger& instance() {
static Logger instance; // 线程安全的静态局部变量
return instance;
}
void log(const std::string& msg) {
std::lock_guard<std::mutex> lock(mutex_);
std::cout << "[" << std::this_thread::get_id() << "] " << msg << std::endl;
}
private:
Logger() = default;
~Logger() = default;
Logger(const Logger&) = delete;
Logger& operator=(const Logger&) = delete;
std::mutex mutex_;
};优点
- 实现简单：只需一行
static变量。 - C++11 标准保证线程安全：编译器在初始化静态局部变量时会自动加锁，确保只创建一次。
- 懒加载：对象在第一次调用
instance()时才会创建，节省资源。
缺点
- 初始化顺序不确定：如果不同模块都需要单例，可能导致“静态初始化顺序问题”。
- 无法自定义初始化：如果单例需要接受参数，静态局部变量不方便。
2. 双重检查锁定（DCL）
class ConfigManager {
public:
static ConfigManager* getInstance() {
if (instance_ == nullptr) {
std::lock_guard<std::mutex> lock(mutex_);
if (instance_ == nullptr) {
instance_ = new ConfigManager();
}
}
return instance_;
}
private:
ConfigManager() { /* load config */ }
~ConfigManager() = default;
static std::atomic<ConfigManager*> instance_;
static std::mutex mutex_;
};
std::atomic<ConfigManager*> ConfigManager::instance_{nullptr};
std::mutex ConfigManager::mutex_;优点
- 延迟初始化：第一次调用时才实例化。
- 性能相对较好：在实例已创建后，后续访问无需加锁。
缺点
- 实现复杂：需要
std::atomic与std::mutex的配合。 - 易犯错误：若未使用
std::atomic，可能出现“指令重排”导致线程安全问题。 - C++11 以后不推荐：因为静态局部变量已提供更安全、更简单的方案。
3. std::call_once 与 std::once_flag
class HttpClient {
public:
static HttpClient& instance() {
std::call_once(initFlag_, []() {
instance_ = new HttpClient();
});
return *instance_;
}
private:
HttpClient() { /* init connection pool */ }
~HttpClient() = default;
HttpClient(const HttpClient&) = delete;
HttpClient& operator=(const HttpClient&) = delete;
static HttpClient* instance_;
static std::once_flag initFlag_;
};
HttpClient* HttpClient::instance_ = nullptr;
std::once_flag HttpClient::initFlag_;优点
- 明确线程安全：
std::call_once内部会使用原子操作和互斥锁，保证一次性初始化。 - 可接受构造参数：通过 lambda 捕获外部变量实现参数传递。
- 性能优秀：初始化后不再需要锁。
缺点
- 内存泄漏风险：若不手动删除
instance_，在程序退出时不释放资源（可通过atexit或智能指针解决）。 - 实现略显繁琐：相比静态局部变量需要更多代码。
4. 使用 std::shared_ptr 与 std::weak_ptr 实现懒惰单例
class Cache {
public:
static std::shared_ptr <Cache> getInstance() {
std::lock_guard<std::mutex> lock(mutex_);
if (auto ptr = instance_.lock()) {
return ptr;
}
auto ptrNew = std::make_shared <Cache>();
instance_ = ptrNew;
return ptrNew;
}
private:
Cache() { /* load data */ }
~Cache() = default;
Cache(const Cache&) = delete;
Cache& operator=(const Cache&) = delete;
static std::weak_ptr <Cache> instance_;
static std::mutex mutex_;
};
std::weak_ptr <Cache> Cache::instance_;
std::mutex Cache::mutex_;优点
- 自动管理生命周期：
std::shared_ptr会在最后一个引用消亡时自动析构，避免内存泄漏。 - 可在任意时刻销毁实例：如果所有引用都消失，单例会被销毁，适合需要动态资源释放的场景。
缺点
- 线程安全实现更复杂：需要在每次获取时加锁。
- 性能略低：每次获取时都需要
lock_guard，但后期访问相对较快。
5. 对比与选择
| 实现方式 | 线程安全 | 懒加载 | 代码简洁 | 适用场景 |
|---|---|---|---|---|
| 静态局部变量 | ✔ | ✔ | ✔ | 单纯需要唯一实例，无需传参 |
| 双重检查锁定 | ✔（复杂） | ✔ | ⚠ | 旧代码兼容，现代 C++ 中不推荐 |
std::call_once |
✔ | ✔ | ⚠ | 需要在初始化时传参，或使用 C++17 的 std::optional |
shared_ptr/weak_ptr |
✔ | ✔ | ⚠ | 需要按需销毁，或资源占用较大 |
小结
在 C++11 及以后，推荐使用 静态局部变量 或std::call_once进行线程安全单例实现。它们兼具易用性、性能与安全性。除非项目有特殊需求（如需要在运行时销毁单例、需要传递构造参数），否则不必使用双重检查锁定或shared_ptr/weak_ptr的复杂方案。
6. 进一步思考：单例与依赖注入
单例模式经常被批评为“全局状态”，导致测试困难和耦合度提升。现代 C++ 开发建议：
- 使用依赖注入（DI）框架：将单例替换为可注入的对象，方便替换实现或在测试中使用 mock。
- 限定作用域：将单例的生命周期限制在必要范围内，避免全局泄漏。
- 遵循“惰性加载+自动释放”原则：如上文的
shared_ptr/weak_ptr实现。
在实际项目中，权衡可维护性、性能与安全性，选择最合适的实现方式，才能真正做到“优雅地拥有唯一实例”。