单例模式大概是C++面试中被问到频率最高的设计模式了，但真正能把它写对、写好的人并不多。很多人随手写一个全局静态变量就认为是单例，也有人在多线程环境下用了错误的加锁方式，导致程序出现难以排查的诡异问题。本文将从常见的几种写法入手，分析它们各自的问题所在，最终给出目前公认最优的实现方案。
最基础的两种写法：饿汉式与懒汉式
所谓饿汉式，就是在程序启动时就直接创建实例，写法非常简单：
class Singleton {
public:
static Singleton& getInstance() {
static Singleton instance; // 局部静态变量
return instance;
}
private:
Singleton() {}
~Singleton() {}
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
};而懒汉式则是在第一次使用时才创建实例，最早的写法通常是这样的：
class Singleton {
public:
static Singleton* getInstance() {
if (instance == nullptr) {
instance = new Singleton();
}
return instance;
}
private:
Singleton() {}
static Singleton* instance;
};
Singleton* Singleton::instance = nullptr;懒汉式的优点是延迟加载，如果这个对象很占内存且不一定被使用，可以节省资源。但上面这段代码在多线程环境下有明显缺陷：当两个线程同时判断instance == nullptr都为真时，会各自new一个对象，其中一个就发生了内存泄露，而且两个线程拿到的是不同的实例，单例的语义被彻底破坏了。
饿汉式则没有线程安全问题，因为实例在main函数之前就已经初始化完成。它的缺点是无论是否使用都会占用资源，另外如果多个编译单元中的全局对象存在初始化顺序依赖，饿汉式单例也可能引发静态初始化顺序问题（Static Initialization Order Fiasco），这一点在大型项目中尤其需要注意。
加锁方案与双重检查锁定的坑
解决懒汉式的线程安全问题，最直接的办法是加锁：
#include <mutex>
class Singleton {
public:
static Singleton* getInstance() {
std::lock_guard<std::mutex> lock(mtx);
if (instance == nullptr) {
instance = new Singleton();
}
return instance;
}
private:
Singleton() {}
static Singleton* instance;
static std::mutex mtx;
};这个写法是线程安全的，但每次调用getInstance都要加锁解锁，而单例的获取往往是非常高频的操作，锁的开销会成为性能瓶颈。于是很多人会想到双重检查锁定（Double-Checked Locking Pattern，简称DCLP）：
static Singleton* getInstance() {
if (instance == nullptr) { // 第一次检查，无锁
std::lock_guard<std::mutex> lock(mtx);
if (instance == nullptr) { // 第二次检查，有锁
instance = new Singleton();
}
}
return instance;
}DCLP的思路是：绝大多数情况下实例已经创建好了，第一次检查就能直接返回，避免每次都加锁。看起来很完美，但这里隐藏着一个经典陷阱：instance = new Singleton()这行代码并不是原子操作，它大致分为三步：分配内存、调用构造函数、把地址赋给instance。编译器和CPU都可能对这三步进行指令重排，可能出现内存已分配、地址已赋值、但构造函数还没执行完的情况。此时另一个线程在第一次检查时发现instance不为空，直接返回了一个尚未构造完成的对象，使用它就是未定义行为。
要修复这个问题，需要把instance声明为原子变量并配合内存序使用：
#include <atomic>
static std::atomic<Singleton*> instance;
static Singleton* getInstance() {
Singleton* tmp = instance.load(std::memory_order_acquire);
if (tmp == nullptr) {
std::lock_guard<std::mutex> lock(mtx);
tmp = instance.load(std::memory_order_relaxed);
if (tmp == nullptr) {
tmp = new Singleton();
instance.store(tmp, std::memory_order_release);
}
}
return tmp;
}这样写是正确的，但代码复杂度明显上升，维护成本也高。事实上在C++11之后，我们有更简洁的选择，这也引出了下面要讲的最优方案。
推荐方案：Meyers单例
C++11标准对局部静态变量的初始化做出了明确保证：如果多个线程同时执行到某个局部静态变量的初始化语句，只有一个线程会执行初始化，其他线程会等待初始化完成。这意味着文章开头提到的饿汉式代码中那个使用局部静态变量的版本，其实就是天然线程安全的懒汉式单例，它被称为Meyers单例，以C++大师Scott Meyers的名字命名：
class Singleton {
public:
static Singleton& getInstance() {
static Singleton instance; // C++11保证线程安全
return instance;
}
private:
Singleton() { std::cout << "构造" < std::endl; }
~Singleton() { std::cout < "析构" < std::endl; }
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
};这个方案集中了各种优点：它按需创建，具备懒加载特性；它由标准保证线程安全，不需要手写任何锁；实例在程序结束时自动析构，没有内存泄露问题；代码只有十几行，可读性极好。现代编译器（GCC 4.3以上、MSVC 2015以上）对局部静态变量的线程安全初始化都有良好支持，可以放心使用。
有几个细节需要注意。首先是构造函数要放在private区域，防止外部直接构造对象；其次要用= delete删除拷贝构造函数和赋值运算符，防止实例被复制，C++11之前的老写法是把它们声明为private且不实现，现在推荐直接用delete，意图更清晰；最后，析构函数也建议声明为private，避免外部代码错误地delete单例指针导致重复析构。
进阶技巧与常见误区
如果项目中有多个类都需要单例语义，可以把单例逻辑封装成模板基类，业务类只需要继承它即可：
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() {}
~Singleton() {}
};
class ConfigManager : public Singleton<ConfigManager> {
friend class Singleton<ConfigManager>; // 允许基类访问私有构造函数
public:
void load() { /* 读取配置 */ }
private:
ConfigManager() {}
};在使用上还有一个常见误区：不要在单例的构造函数或析构函数中再去获取其他单例。如果两个单例在析构时互相依赖，程序退出时可能访问一个已经析构的对象。如果确实有这种需求，可以提供一个显式的destroy()方法，在main函数结束前手动控制销毁顺序，而不是依赖静态对象的析构顺序。
另外，返回引用比返回指针更好。指针版本容易诱导使用者写出delete Singleton::getInstance()这样的危险代码，而引用从语法层面杜绝了这种可能。如果需要判断单例是否已创建，可以额外提供状态查询接口，而不是依赖指针是否为空。
总结一下：在C++11及以后的环境中，Meyers单例是最优选择——局部静态变量、私有构造、删除拷贝、返回引用，四个要素齐全就是一个生产可用的单例。只有在面对C++03这样的老标准，或者需要在实例创建前后做精细控制的特殊场景下，才需要考虑原子变量加锁的DCLP方案。理解了这些方案背后的线程安全和对象生命周期问题，才算真正掌握了C++的单例模式。