Chromium 源码剖析：base::NoDestructor——更安全的静态单例解决方案

John_ToDebug

455人浏览 · 2026-04-21 16:43:13

John_ToDebug · 2026-04-21 16:43:13 发布

C++ 静态对象的析构顺序是一个经常踩坑的话题，尤其是在 Chromium 这种超大工程里。

先说结论：

静态/全局对象的析构顺序与构造顺序相反（LIFO），但仅在同一个翻译单元（.cpp 文件）内有保证。跨翻译单元的构造/析构顺序是未定义的。

引言

在 Chromium 源码中，你经常会看到这样一种单例实现：

static ThreadSafeCache& GetInstance() {
    // C++11 ensures thread safe initialization of static local variables
    static base::NoDestructor<ThreadSafeCache> instance;
    return *instance;
}

这里的 base::NoDestructor 是什么？为什么 Chromium 要用它替代普通的静态局部变量？今天我们就来深入剖析这个看似简单却暗藏玄机的工具类。

传统静态局部单例的问题

在 C++11 之前，线程安全的单例实现是个复杂问题。C++11 虽然保证了函数内静态局部变量初始化的线程安全，但仍然存在一个棘手的问题——静态对象的析构顺序不确定性。

// 传统写法 - 存在隐患
class Logger {
public:
    static Logger& GetInstance() {
        static Logger instance;  // 程序退出时会析构
        return instance;
    }
    
    void Log(const std::string& msg) { /* ... */ }
};

class Database {
public:
    ~Database() {
        Logger::GetInstance().Log("Database shutting down");  // 危险！
    }
    
    static Database& GetInstance() {
        static Database instance;
        return instance;
    }
};

上面的代码存在严重问题：当程序退出时，Logger 和 Database 的析构顺序是未定义的。如果 Database 先于 Logger 析构，那么 Database 的析构函数中调用 Logger::GetInstance() 时，可能访问到一个已经被销毁的对象，导致程序崩溃。

这就是著名的 “静态析构顺序崩溃” 问题（Static Initialization Order Fiasco 的析构版本）。

base::NoDestructor 的设计哲学

base::NoDestructor 的解决方案简单而优雅：既然析构顺序难以控制，那就干脆不要析构。

核心实现原理

template <typename T>
class NoDestructor {
public:
    template <typename... Args>
    explicit NoDestructor(Args&&... args) {
        // placement new：在预分配的内存上构造对象
        new (storage_) T(std::forward<Args>(args)...);
    }
    
    T* operator->() { return get(); }
    const T* operator->() const { return get(); }
    
    T& operator*() { return *get(); }
    const T& operator*() const { return *get(); }
    
private:
    T* get() { return reinterpret_cast<T*>(storage_); }
    
    alignas(T) char storage_[sizeof(T)];  // 原始内存缓冲区
    // 注意：没有析构函数的调用！
};

关键设计决策

1. 永不析构
NoDestructor 故意不调用 T 的析构函数。这意味着即使程序退出，T 占用的内存也不会被显式释放。这不是一个疏漏，而是经过深思熟虑的设计选择。

2. 内存安全
进程退出时，操作系统会回收整个进程的地址空间。在现代操作系统（Linux、macOS、Windows NT 系）上，所有进程分配的内存都会被内核回收，包括栈、堆、静态数据段等。因此，"泄漏" 一个进程生命周期内的单例是完全可接受的——进程退出本身就是最彻底的垃圾回收。

3. 避免析构依赖
因为没有析构，所以根本不存在析构顺序问题。这直接消除了跨翻译单元析构顺序不确定性这个大类 bug。如果你的 T 持有非内存资源（如临时文件、共享内存、硬件句柄等），OS 回收机制无法覆盖这些资源，此时应注册 atexit 钩子手动清理，而不是依赖析构函数。另外需注意，Valgrind、ASan 等内存检测工具会将此报告为内存泄漏，实际使用中需要配置抑制规则来过滤这些"良性噪音"。

使用场景对比

✅ 适合使用 NoDestructor 的场景

// 1. 进程级单例
class NetworkService {
public:
    static NetworkService& GetInstance() {
        static base::NoDestructor<NetworkService> instance;
        return *instance;
    }
};

// 2. 全局配置管理器
class PrefService {
public:
    static PrefService& GetInstance() {
        static base::NoDestructor<PrefService> instance;
        return *instance;
    }
};

// 3. 缓存池（析构清理意义不大）
class ResourceCache {
public:
    static ResourceCache& GetInstance() {
        static base::NoDestructor<ResourceCache> instance;
        return *instance;
    }
};

❌ 不适合使用 NoDestructor 的场景

// 1. 需要显式释放资源（如文件句柄、网络连接）
class FileWriter {
    ~FileWriter() {
        fclose(file_);  // 这个析构很重要！
    }
};

// 2. 需要刷写数据的场景
class MetricsReporter {
    ~MetricsReporter() {
        FlushToServer();  // 需要确保数据上报
    }
};

// 3. 单元测试（需要反复创建销毁）
class TestFixture {
    // 测试场景下需要析构来验证状态
};

Chromium 中的实际应用

与 LazyInstance 的对比

Chromium 旧代码中广泛使用 base::LazyInstance，但新代码推荐使用 NoDestructor：

// 旧方式（已废弃）
static base::LazyInstance<MyClass>::Leaky g_instance = LAZY_INSTANCE_INITIALIZER;

// 新方式（推荐）
static base::NoDestructor<MyClass> g_instance;

NoDestructor 的优势：

更简洁的语法
自动内存对齐
更少的内存开销
更好的可读性

实际代码示例

在 Chromium 的网络栈中，可以看到这样的用法：

class HttpAuthPreferences {
public:
    static HttpAuthPreferences* Get() {
        static base::NoDestructor<HttpAuthPreferences> instance;
        return instance.get();
    }
    
    void SetServerAllowlist(const std::string& allowlist) {
        // 配置逻辑
    }
};

性能考量

内存开销

NoDestructor 本身几乎没有运行时开销
storage_ 的大小等于 sizeof(T)，没有额外内存浪费
不调用析构函数节省了退出时的时间开销

初始化性能

// 第一次调用时初始化（线程安全）
static base::NoDestructor<ExpensiveObject> instance;

C++11 保证了静态局部变量的初始化是线程安全的，但会有一点点锁的开销。一旦初始化完成，后续调用只是简单的指针解引用。

注意事项与最佳实践

1. 避免在析构函数中有必要逻辑的对象

// 危险：析构函数有重要清理工作
class ImportantCleanup {
    ~ImportantCleanup() {
        // 这个析构永远不会被调用！
        FlushCriticalData();
    }
};

// 改用普通静态对象
static ImportantCleanup g_cleanup;  // 会正确析构

2. 配合 NotReached() 使用

// Chromium 风格的错误处理
void DoSomething() {
    auto& instance = MyClass::GetInstance();
    CHECK(instance.IsInitialized());  // 断言检查
}

3. 注意依赖关系

虽然 NoDestructor 避免了析构顺序问题，但构造顺序仍然重要：

static Logger& GetLogger() {
    static base::NoDestructor<Logger> instance;
    return *instance;
}

static Database& GetDatabase() {
    static base::NoDestructor<Database> instance;  // 构造函数中可能调用 GetLogger()
    return *instance;  // 安全：Logger 会先被构造
}