第6章：实现 Singletons

为什么静态函数集合不等于 Singleton

Static Data + Static Functions != Singleton。一组静态函数更接近 namespace：没有对象身份、constructor invariant、可替换 implementation 或明确 destruction protocol。Singleton pattern 则声明“系统中恰有一个 T instance，并由受控入口创建、发布和销毁”。

Singleton 仍是 global state，会隐藏 dependency、污染 test isolation、制造 shutdown coupling。书中实现技巧的价值是把生命周期问题暴露并参数化，不是证明所有 service 都应成为 Singleton。能由 application root 构造并传入的 dependency，通常更容易测试和推理。

The Basic C++ Idioms Supporting Singleton

The Basic C++ Idioms Supporting Singleton 包括 private/protected constructor、deleted copy、static access function、保存 instance pointer，以及延迟初始化。class 自身阻止外部构造，holder 或 friend 负责创建。

class Logger {
public:
    static Logger& instance() {
        static Logger value;
        return value;
    }
    Logger(const Logger&) = delete;
    Logger& operator=(const Logger&) = delete;
private:
    Logger() = default;
};

现代 function-local static 从 C++11 起保证一次性线程安全初始化，解决书中手工 double-checked locking 的许多问题；但它仍不自动解决退出期依赖、可替换性、fork/plugin lifetime 或销毁后再次访问。

Enforcing the Singleton's Uniqueness

Enforcing the Singleton's Uniqueness 不只把 constructor private。还要禁止 copy/assignment，控制 derived construction，避免另一个 module 各自实例化 header-only holder，并定义 shared-library/DSO 边界。template SingletonHolder<T> 的每个 T/Policy combination 都是独立 static state，换一个 Policy 就可能得到第二个实例。

若 type 在多个 dynamic libraries 中有不同 runtime copy，语言层“一个 static”未必等于进程级一个。需要由 host module 导出唯一 accessor，或把 ownership 放入显式 service registry，并为 unload/reload 定义协议。

Destroying the Singleton

Destroying the Singleton 有三种常见选择：永不销毁并让 OS 回收；注册 atexit 在正常退出时销毁；由 application owner 显式停止。泄漏式 lifetime 避免 static destruction order，但会跳过 flush、transaction close 与 sanitizer leak expectations。

static T* instance_ = nullptr;
static bool destroyed_ = false;
 
static void destroySingleton() noexcept {
    delete instance_;
    instance_ = nullptr;
    destroyed_ = true;
}

destroy function 的状态顺序很重要：destructor 可能间接调用 Instance()，此时 pointer/flag 应让 dead-reference policy 看见一致状态。destructor 抛异常会在 atexit 路径造成严重后果，shutdown 应设计为 no-throw 或显式错误收集。

The Dead Reference Problem

The Dead Reference Problem 是某 Singleton 已销毁，另一个 static object's destructor 随后再次访问它。构造顺序若跨 translation units 不确定，销毁逆序也不能给出可靠 dependency order；延迟创建只把顺序变成“首次访问顺序”，依赖 cycle 仍存在。

正确分析要画 shutdown graph：节点是 global services，边 B -> A 表示 B destructor 需要 A；销毁必须按边的反向拓扑。若有 cycle，单纯调整 registration order 无法满足，需拆除 destructor dependency、引入 explicit shutdown phase 或允许某节点延长/泄漏。

Addressing Dead Reference I：The Phoenix Singleton

The Phoenix Singleton 在销毁后再次请求时重新创建 instance，像 Phoenix 重生。它适用于可无损重建、晚期调用仍有意义且能再次安排销毁的 service。书中 LifetimePolicy 可在 OnDeadReference 中决定重建还是抛错。

重生不是恢复原状态：cache、file position、transaction、metrics sink 都可能已关闭；dependent object 看到的是第二代 identity。若调用者要求同一状态，Phoenix 会掩盖 bug。它还可能在 shutdown 期间反复 create/destroy，必须有 generation 与 registration guard。

Addressing Dead Reference II：Singletons with Longevity

Singletons with Longevity 为每个 instance 分配 longevity value；销毁管理器让数值较大的对象活得更久，按定义顺序调用 destroyer。这样 dependency 可以显式表达：被依赖 service 的 longevity 高于依赖者。

longevity 是 partial dependency graph 的数值编码。若两个对象有复杂条件依赖，数字很快变成隐晦 priority；更稳妥的是显式 DAG/topological shutdown。数字相等时也要定义 stable tie-break，否则 nondeterminism 重新出现。

Implementing Singletons with Longevity

Implementing Singletons with Longevity 保存一组 LifetimeTracker，每项记录 longevity 与 polymorphic destroyer；注册时按顺序插入，atexit callback 每次销毁当前应退出的对象并安排下一项。

struct LifetimeTracker {
    explicit LifetimeTracker(unsigned longevity) : longevity_(longevity) {}
    virtual ~LifetimeTracker() = default;
    virtual void destroy() noexcept = 0;
    unsigned longevity_;
};
 
template<class T>
struct ConcreteLifetimeTracker final : LifetimeTracker {
    ConcreteLifetimeTracker(T* p, unsigned value)
        : LifetimeTracker(value), pointer_(p) {}
    void destroy() noexcept override { delete pointer_; }
    T* pointer_;
};

tracker registry 本身也是 global lifetime state，必须先于 trackers 可用且最后消失；这会出现“管理 Singleton 的 Singleton”递归。实现常选择 intentionally leaked registry 或 function-local static，并把 allocation failure 与 duplicate registration 纳入测试。

Living in a Multithreaded World

Living in a Multithreaded World 的核心是 safe publication：多个 threads 首次调用时只能构造一次，其他线程看到 fully initialized T；destroy 与 concurrent access 也不能 data race。旧式检查 pointer、加锁、再检查在弱 memory model 下容易读到未完全构造对象。

modern magic static 或 std::call_once 应优先于手写 double-checked locking。若 instance 可在运行中销毁/reload，reference 返回就无法自动保护 lifetime，需要 shared ownership、epoch/hazard 机制或外部 stop-the-world protocol。

Putting It All Together

Putting It All Together 时，holder 状态机大致为 never-created -> alive -> destroyed，dead-reference policy 可能从 destroyed 回到 alive。CreationPolicy 负责 raw create/destroy，LifetimePolicy 注册退出并处理 dead access，ThreadingModel 保护初始化临界区。

policy boundaries 要清楚：CreationPolicy 不决定何时创建；LifetimePolicy 不直接知道 mutex；ThreadingModel 不改变 T 的业务 thread safety。若三个策略互相读取私有状态，回到第 1 章的不兼容 Policy 问题。

Working with SingletonHolder

Working with SingletonHolder 通常通过 alias 定义一个具体 service：选择 creation/lifetime/thread policies，再只暴露窄 accessor。不要让业务代码到处拼不同 Policy combinations，否则“同一个 T”可能产生多个 Holder specializations。

testing 可通过把核心业务依赖写成 interface/reference，在 production composition root 才绑定 SingletonHolder；unit tests 注入 fake。若函数内部直接调用 GlobalLogger::Instance()，任何 test 都隐式共享 state，顺序与并行执行容易互相污染。

先预测：一个 metrics registry 被 Phoenix 重生后，退出期新产生的 metric 无处 flush，还可能再次注册 atexit。与其重生，不如让 late logging 写到 emergency sink 或拒绝；Policy 选择必须来自 shutdown product behavior。

小结

• static namespace 没有完整 instance lifecycle；Singleton 还需唯一性、创建、发布与销毁协议
• private constructor 只是起点，模板组合、DSO 与 scope 会改变唯一范围
• destroying Singleton 必须定义 late access；dead reference 来自退出期依赖顺序
• Phoenix 允许重建但改变 identity/state，longevity 用顺序编码 dependency，都不是普遍修复
• safe publication 应使用 magic static/call_once 等 memory-model-aware primitive，业务状态仍另需同步
• SingletonHolder 用 Creation/Lifetime/Threading Policies 组合变化点，集成层要固定唯一 alias
• 显式 dependency injection 通常更可测试；Holder 应限制在真正 process-global 且生命周期可证明的服务

名词解释