全局访问很方便，为什么单例让测试和退出越来越难？

时间：2026/05/03

项目最初只有一处需要日志，写成 Logger::instance() 很方便。几个月后，业务对象内部到处主动取得 Logger、Config、Metrics 和 ResourceManager；单元测试无法替换实现，启动顺序依赖第一次调用，程序退出时一个单例的析构函数又访问了已经销毁的另一个单例。

单例解决的是“进程内受控地取得同一个实例”，却同时引入全局状态、隐藏依赖和静态生命周期。C++11 的函数局部静态让初始化本身安全可靠，但不会让对象方法自动线程安全，也不会解决配置、测试替换和析构顺序。

本文从 Meyers Singleton 的正确实现开始，讲清初始化失败、call_once、并发状态和销毁边界，再说明什么时候显式构造并注入一个唯一对象比单例更简单。

---

1. 单例真正承诺了什么？

经典单例通常承诺：

• 调用者不能公开构造第二个实例；
• 拷贝和移动被禁止；
• 所有调用者通过一个全局入口取得同一对象；
• 创建时机和销毁策略由实现控制。

它并不自动承诺：

• 每个动态库、插件或进程都共享同一物理实例；
• 对象成员操作线程安全；
• 第一次访问时外部依赖已经准备好；
• 测试可以替换实例；
• 静态销毁顺序满足其他全局对象需要。

因此，“全局只能有一个”要进一步问：这是业务不变量，还是当前程序只碰巧创建一个？数据库连接池、日志后端和配置对象可以只有一个所有者，却不一定要通过全局入口访问。

2. C++11 后最小实现为什么使用局部静态？

class Metrics {
public:
    static Metrics& instance() {
        static Metrics metrics;
        return metrics;
    }

    Metrics(const Metrics&) = delete;
    Metrics& operator=(const Metrics&) = delete;
    Metrics(Metrics&&) = delete;
    Metrics& operator=(Metrics&&) = delete;

private:
    Metrics() = default;
};

函数局部静态对象在控制流第一次经过声明时初始化。C++11 起，并发线程首次进入时，标准保证初始化只完成一次；其他线程会按规则等待，不需要手写双重检查锁。

私有构造限制外部创建，删除复制/移动阻止从现有实例再产生对象。析构函数可私有或公开，取决于实现和测试需要；若局部静态必须调用私有析构，成员函数作用域内的静态对象仍能访问它。

这个实现通常比裸静态指针简单：没有手工 new/delete，也没有自行编写初始化同步协议。

3. 初始化线程安全为什么不等于对象线程安全？

void increment() {
    ++count_; // 多线程同时调用会数据竞争
}

局部静态规则只保护构造过程。一旦 instance() 返回，成员状态由类型自己负责同步：

• 独立计数可用适当 atomic；
• 多字段不变量通常需要 mutex；
• 只读不可变数据可在构造后安全发布；
• I/O 与回调还要定义调用线程和重入规则。

把所有成员函数都加锁也不自动得到良好并发设计。跨多个调用的原子业务操作不能靠每个 getter/setter 各锁一次实现，接口应按不变量划分临界区。

4. 一个可运行的线程安全初始化示例

下面的 C++20 程序让两个线程并发首次访问同一个计数器，并用 atomic 保护初始化后的共享计数。

#include <atomic>
#include <cstdint>
#include <iostream>
#include <thread>

class GlobalCounter {
public:
    static GlobalCounter& instance() {
        static GlobalCounter counter;
        return counter;
    }

    GlobalCounter(const GlobalCounter&) = delete;
    GlobalCounter& operator=(const GlobalCounter&) = delete;

    void increment() noexcept {
        value_.fetch_add(1, std::memory_order_relaxed);
    }

    std::uint64_t value() const noexcept {
        return value_.load(std::memory_order_relaxed);
    }

private:
    GlobalCounter() = default;
    std::atomic<std::uint64_t> value_{0};
};

int main() {
    auto work = [] {
        for (int index = 0; index < 1000; ++index) {
            GlobalCounter::instance().increment();
        }
    };

    std::thread first(work);
    std::thread second(work);
    first.join();
    second.join();

    auto& left = GlobalCounter::instance();
    auto& right = GlobalCounter::instance();

    std::cout << "same instance = " << std::boolalpha << (&left == &right) << '\n';
    std::cout << "count = " << left.value() << '\n';
}

编译运行：

clang++ -std=c++20 -O2 -Wall -Wextra -pedantic -pthread \
  singleton.cpp -o singleton
./singleton

预期输出：

same instance = true
count = 2000

这里 relaxed 内存序足够，因为计数值只要求原子累加与最终读取，不承担发布其他数据的同步职责。若计数与其他状态存在顺序关系，就要重新设计同步，不能复制这一内存序结论。

5. 构造函数抛异常后发生什么？

若局部静态初始化抛异常：

static Config config; // Config 构造抛出

本次调用收到异常，对象不被视为初始化完成。以后控制流再次进入声明时会重新尝试初始化。并发等待线程的具体结果取决于后续尝试，但不会得到一个半构造完成的对象。

“自动重试”不代表业务应该无限重试。永久格式错误适合在启动边界报告并终止启动；临时外部失败是否重试，应有退避、上限和可观测状态。

构造期间若递归调用同一个 instance()，会重新进入正在初始化的声明，属于危险设计并可能产生未定义行为。构造函数不要依赖自己的全局入口，也应避免单例相互构造形成环。

6. 带参数的单例为什么语义混乱？

auto& first = Config::instance("dev.yaml");
auto& second = Config::instance("prod.yaml");

第二次参数通常不会参与构造，却看起来像会生效。调用结果依赖谁先到达，测试顺序和并发调度都可能改变配置。

若必须保留全局入口，至少把启动阶段与使用阶段分开，并定义重复初始化策略：

init(config)：只允许启动阶段调用一次，相同配置幂等或重复即报错
instance()：只取得已初始化对象，未初始化时明确失败
shutdown()：若需要，只有所有使用者停止后调用

但实现这个状态机需要同步 init/instance/shutdown，并处理初始化失败和正在使用时关闭。复杂到这一步时，应用入口直接构造对象并传给需要者通常更容易证明。

7. std::call_once 何时有用？

std::once_flag flag;
std::unique_ptr<Service> service;

std::call_once(flag, [] {
    service = std::make_unique<Service>();
});

call_once 适合一次初始化动作不方便表达成单个局部静态构造，或多个数据需要共同建立。若调用函数抛异常，once flag 不会被标记完成，后续调用可以重试。

它只负责成功执行一次，不提供 reset，也不解决销毁同步。普通无参单例仍优先局部静态，更少状态、更容易阅读。

不要手写双重检查锁：正确实现需要原子发布、内存序和对象生命周期配合。现代语言已提供局部静态和 call_once，没有理由用脆弱模式重复实现。

8. 单例什么时候销毁？

Meyers Singleton 若完成构造，通常在程序正常退出的静态析构阶段销毁。不同翻译单元的静态对象销毁顺序很难形成直观的全局依赖图：

Logger 已析构
    ↓
Config 析构函数仍尝试写日志
    ↓
访问已结束生命周期对象

改善方法：

• 析构函数不要调用其他全局服务；
• 在 main/应用对象中显式按逆依赖顺序停止服务；
• worker、异步回调全部 join/取消后再销毁依赖；
• 将真正重要的 flush/close 设计为显式操作并处理失败。

有人用 static auto* service = new Service; 故意不析构来避开顺序问题。这会让工具报告进程级常驻分配，也跳过文件 flush、线程 join 等资源语义。只有明确证明对象无需析构且团队接受策略时才考虑，不能作为默认“修复”。

9. 为什么显式依赖注入往往更简单？

单例调用隐藏了函数的真实输入：

void handle_request() {
    Logger::instance().write("request");
}

显式传入引用：

void handle_request(Logger& logger) {
    logger.write("request");
}

现在调用图能看到依赖，测试可以传入内存 logger，应用入口仍然可以只构造一个真实 Logger：

int main() {
    Logger logger{Config{/*...*/}};
    Server server{logger};
    return server.run();
}

“只有一个实例”和“必须全局访问”是两件事。对象可以由应用根唯一拥有，再通过构造函数/引用传递，而不使用 DI 框架或 service locator。简单显式传参通常已经足够。

10. 哪些场景可能适合单例？

较合理的候选通常满足：

• 实例确实与进程/模块生命周期绑定；
• 没有调用方需要替换或并行存在第二配置；
• 初始化不依赖复杂运行期参数，或在应用启动前已明确；
• 销毁不会依赖其他静态对象；
• 全局访问带来的测试与依赖隐藏成本可接受。

无状态注册信息、极少量底层进程设施可能符合。业务服务、数据库客户端、配置可变的资源和测试替身需求强的组件通常更适合显式所有权。

动态库/插件边界还要谨慎：头文件中的局部静态或 inline 实体是否最终合并为进程唯一实例，受链接、符号可见性、加载方式和平台 ABI 影响。真正跨模块唯一资源应通过明确宿主接口传入，不要仅凭“同一段 singleton 代码”假设。

11. 单例与 service locator 有什么关系？

一个全局容器按类型/字符串返回任意服务，通常是 service locator。它把多个单例式隐藏依赖集中起来，却让函数签名更加看不出需要什么，并把缺失服务错误推迟到运行期。

若系统确实需要运行期服务发现，应限定边界并提供类型安全、生命周期和错误策略。普通业务对象优先构造函数参数，不要为少写几个参数引入全局注册表。

12. 工程中最容易踩哪些坑？

误区一：局部静态初始化安全，所以所有方法安全

构造只执行一次不代表成员读写有同步。共享可变状态仍要设计 happens-before。

误区二：多次 instance() 就是重复初始化

成功构造后只返回同一对象；真正棘手的是首次参数、失败重试和显式 init 重复。

误区三：单例比全局变量天然可测试

它封装了入口和构造，但依赖仍然全局隐藏，默认实例通常仍难替换或重置。

误区四：故意泄漏能解决生命周期

它只跳过析构，不能安全结束线程、刷新数据或取消回调。资源关闭仍需显式协议。

误区五：任何“理论上只有一个”的对象都该做成单例

应用根唯一拥有并显式传递同样能保证实际只有一个，而且更易测试和控制顺序。

误区六：单例在所有共享库中自然唯一

模块加载和符号规则可能产生不同实例。跨插件唯一性必须由宿主所有权/导出接口保证。

13. 总结

开头日志系统的问题不是 Meyers Singleton 写错，而是全局访问让依赖、配置和生命周期逐渐不可见。

1. C++11 函数局部静态提供线程安全的首次初始化，失败后后续进入会重试；
2. 初始化安全不等于成员状态线程安全，原子和锁要按业务不变量设计；
3. 带参数初始化、显式 shutdown 和跨单例依赖会迅速形成复杂状态机；
4. 静态析构顺序与动态库边界都可能破坏“进程唯一”的简单直觉；
5. 应用入口构造一个对象并显式注入，常常比全局单例更容易测试和销毁。

准备新增 instance() 前，先尝试在应用根创建对象并通过构造函数传入。如果只有少数调用链因此多一个引用参数，这份显式依赖通常比未来的全局生命周期问题便宜得多。