双重检查锁在C++11前不安全，因编译器和CPU重排序导致instance指针提前赋值而对象未构造完成，引发未定义行为；C++11后需用std::atomic+acquire-release内存序，或直接采用线程安全的静态局部变量。
为什么双重检查锁在 C++11 之前不安全
核心问题在于编译器重排序和 CPU 指令重排可能导致 instance 指针被提前赋值，而对象构造尚未完成。线程 A 执行到 if (instance == nullptr) 时看到非空指针，直接返回未初始化完毕的对象，引发未定义行为。
典型现象：程序偶发崩溃、成员变量为垃圾值、std::mutex 构造失败等难以复现的问题。
- C++11 之前没有内存模型约束，
volatile无法阻止编译器优化或提供跨线程同步语义 - 即使加了
pthread_mutex_lock，若只在第二次检查后加锁，第一次检查仍暴露竞态窗口 - 某些老编译器（如 GCC 4.6 前）对
__sync_*内置函数的支持也不足以保证顺序一致性
C++11 及以后的正确双重检查锁写法
必须使用 std::atomic + 显式内存序，且静态局部变量本身已是线程安全的替代方案——但双重检查锁仍有其适用场景（如需延迟初始化 + 控制析构时机）。
class Singleton {
public:
static Singleton* getInstance() {
Singleton* tmp = instance.load(std::memory_order_acquire);
if (tmp == nullptr) {
std::lock_guard 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() = default;
~Singleton() = default;
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
static std::atomic instance;
static s
td::mutex mutex_;
};
std::atomic Singleton::instance{nullptr};
std::mutex Singleton::mutex_;
-
instance 必须是 std::atomic，不能用原始指针 + volatile
- 首次读用
std::memory_order_acquire，确保后续读取不会被重排到它前面
- 写入用
std::memory_order_release，配合 acquire 实现同步点（acquire-release 语义）
- 中间的 relaxed 读是为了避免重复 acquire 开销，但必须在持锁后执行
更简单且推荐的替代方案：C++11 静态局部变量
如果不需要手动控制销毁时机（比如要确保在 main 返回前析构），直接用静态局部变量即可，标准保证其初始化是线程安全的，且无双重检查锁的复杂性。
class Singleton {
public:
static Singleton& getInstance() {
static Singleton instance; // C++11 起 guaranteed thread-safe
return instance;
}
private:
Singleton() = default;
~Singleton() = default;
Singleton(const Singleton&) = delete;
Singleton& operator=(const Singleton&) = delete;
};
- 初始化仅发生一次，且由编译器生成的 guard variable 和调用约定保障原子性
- 无需手动管理
new/delete，也规避了内存泄漏或析构顺序问题
- GCC/Clang/MSVC 均已完整支持；唯一限制是析构时机不可控（在首次调用后、程序退出时）
容易忽略的陷阱：delete 操作与析构竞争
若实现中允许显式销毁（如 destroy()），必须确保所有线程已停止访问实例，否则 delete 后其他线程仍可能解引用已释放内存。
- 不能只靠
std::atomic_store(nullptr) 就认为安全——指针置空不等于内存已回收完毕
- 需要引入引用计数或屏障（如
std::atomic_thread_fence(std::memory_order_acquire)）配合生命周期管理
- 更稳妥的做法是禁止显式销毁，依赖静态存储期或智能指针（如
std::shared_ptr 管理单例生命周期）
双重检查锁真正难的不是写法，而是确认是否真的需要它——多数情况下，静态局部变量已经足够；一旦选了手动管理，std::atomic 的 memory order 就不能凭感觉选。
