C++如何实现基于双重检查锁 (DCL) 的线程安全单例-C++-PHP中文网

std::call_once比手写dcl更可靠，因其由标准库保证“仅执行一次”，自动处理内存序、编译器/cpu重排等问题；而dcl易因遗漏内存栅栏或非原子访问导致未完全构造对象被读取。

c++如何实现基于双重检查锁 (dcl) 的线程安全单例

为什么直接用 `std::call_once` 比手写 DCL 更可靠

绝大多数 C++ 项目里，手写双重检查锁（DCL）单例既没必要，又容易出错。现代 C++（C++11 起）保证了静态局部变量的首次初始化是线程安全的，且编译器会自动生成等效于 std::call_once 的保护逻辑。这意味着最简、最安全的实现就是：

class Singleton {
public:
    static Singleton& instance() {
        static Singleton inst;  // 线程安全，无需锁
        return inst;
    }
private:
    Singleton() = default;
    ~Singleton() = default;
    Singleton(const Singleton&) = delete;
    Singleton& operator=(const Singleton&) = delete;
};

手写 DCL 的主要动机（如延迟初始化 + 避免全局构造）在静态局部变量方案中已天然满足；而它引入的复杂度——内存序、指针重排序、编译器优化干扰——全是隐患。

`std::atomic<singleton></singleton>` 是 DCL 中唯一能用的指针类型

如果非要用 DCL（比如要兼容旧标准、或需控制构造时机），std::shared_ptr 或裸指针都不行：std::shared_ptr 的赋值不是原子的；裸指针无法防止编译器/处理器重排。必须用 std::atomic<singleton></singleton>，且初始化时需指定 memory_order_relaxed，后续读写用 memory_order_acquire/memory_order_release。

第一次检查用 load(std::memory_order_acquire)
构造完成后写入用 store(inst, std::memory_order_release)
第二次检查（在锁内）仍需再 load 一次，避免其他线程看到未完全构造的对象

漏掉任意一个内存序，都可能在多核 CPU 上出现“部分构造对象被返回”的 UB。

常见错误：忘记 `volatile` 不解决 DCL 问题

老式 DCL 实现常加 volatile Singleton* instance_，这是无效的。C++ 中 volatile 只影响编译器优化，不提供线程同步语义，也不约束 CPU 内存序。它既不能阻止指令重排，也不能保证缓存一致性。这种写法在 GCC/Clang 下可能偶然工作，但属于未定义行为，不应依赖。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

真正需要的是原子操作 + 显式内存序，而不是 volatile。

构造函数抛异常时 DCL 会永久失效

如果单例构造函数抛出异常，基于 std::atomic 的 DCL 实现通常不会自动重试。例如：

if (instance_.load(std::memory_order_acquire) == nullptr) {
    std::lock_guard<:mutex> lock(mutex_);
    if (instance_.load(std::memory_order_relaxed) == nullptr) {
        try {
            instance_.store(new Singleton(), std::memory_order_release);
        } catch (...) {
            // 异常后 instance_ 仍是 nullptr，下次调用仍会尝试 new —— 可能反复失败
            throw;
        }
    }
}</:mutex>

这会导致每次调用都触发异常路径，除非手动加标志位记录“构造失败”，否则无法区分“未初始化”和“初始化失败”。而静态局部变量方案会自动捕获并缓存异常（C++11 标准规定：若初始化抛异常，后续调用直接 rethrow，不再尝试）。

DCL 的这个缺陷常被忽略，但它让错误恢复逻辑变得脆弱——尤其当构造依赖外部资源（网络、文件）时。