现代C++中单例模式的全面分析：搭建、批判与替代方案

现代C++中单例模式的全面分析：实现、批判与替代方案

第1节：单例模式：核心原则与动机

本节旨在为单例（Singleton）模式建立一个正式的定义，超越简单的解释，深入探讨其在《设计模式：可复用面向对象软件的基础》一书中由“四人帮”（Gang of Four）所定义的核心职责。随后，将探讨历史上证明其应用合理性的典型用例。

1.1 定义单例：双重目的

单例模式的意图是确保一个类仅有一个实例，并提供一个访问它的全局访问点 1。这种双重职责是分析的关键点，也正是这一点使其在后续的批判中被视为违反了单一职责原则（Single Responsibility Principle）3。

此模式的实现机制通常结合了几个关键要素：一个私有构造函数，用以防止外部代码通过常规方式实例化该类；以及一个公共的静态工厂方法（通常命名为getInstance()），该方法负责控制并返回唯一的实例 2。通过这种方式，该类完全掌握了自身实例化的过程，从而强制执行了“单一实例”的约束。

这种设计的内在张力值得关注。一方面，它严格控制实例数量，这对于管理有限资源至关重要。另一方面，它提供了全局可访问性，这带来了极大的便利，但也正是这种便利性，使其与全局变量的弊端紧密相连。全局访问点意味着系统的任何部分都可以获取并可能修改这个唯一实例的状态，从而引入了全局状态。全局状态是软件工程中一个众所周知的问题，它会显著增加系统的复杂性，使代码行为难以推理、调试和测试 4。因此，单例模式的核心定义本身就蕴含了其争议的根源：它为解决一个问题（实例控制）而引入的便利性（全局访问），恰恰是导致其最大缺陷（全局状态）的直接原因。这种固有的冲突是理解围绕该模式的长期争论的关键。

1.2 意图与典型用例

单例模式的主要动机在于对共享的、有限的资源进行集中化管理与控制 1。在某些场景下，确保系统中只有一个特定对象的实例不仅是高效的，甚至是必要的。

以下是历史上被广泛接受的单例模式典型用例：

日志框架（Logging Frameworks）： 这是单例模式最经典的例子之一。在一个应用程序中，通常需要一个统一的日志记录器，以便所有组件都能将日志信息写入到同一个目的地（如文件或控制台），并保持格式一致。使用单例可以确保所有日志操作都通过一个中心点进行，避免了因多个日志实例导致的文件冲突或日志信息混乱 5。
配置管理器（Configuration Managers）： 应用程序通常需要从一个或多个配置文件中读取设置。一个单例的配置管理器可以加载这些设置，并在内存中持有一份唯一的副本。这为应用程序的所有部分提供了一个单一、全局的“事实来源”（source of truth），确保了所有组件都基于相同的配置运行，同时也避免了重复读取和解析配置文件的开销 1。
资源池（Resource Pools）： 对于那些创建成本高昂且数量有限的资源，如数据库连接或线程池，使用单例模式进行管理是常见的做法。一个单例的连接池可以维护一组可复用的数据库连接，应用程序的各个部分可以按需请求和释放连接，而不是每次都创建新的连接。这不仅提高了性能，还通过集中控制避免了资源耗尽的风险 2。
缓存（Caching）： 在需要缓存频繁访问的数据以提高性能的系统中，单例模式可用于创建一个全局缓存实例。这使得应用程序的不同部分能够高效地共享和访问缓存数据，减少了冗余计算或数据检索的需求 8。

这些用例的共同点在于，它们都涉及到一个需要在整个应用程序生命周期内保持唯一且易于访问的共享资源或服务。在这些场景下，单例模式提供了一个看似简单直接的解决方案。

第2节：C++中的实现策略与演进

本节将按时间顺序详细探讨C++中单例模式的实现技术，展示C++语言标准的演进如何直接影响了该模式的最佳实践。从早期的基本方法到现代C++提供的语言级别保障，这一演进过程本身就是C++并发编程模型成熟的缩影。

2.1 基础方法：饿汉式与懒汉式初始化

单例实例的创建时机是区分不同实现方式的关键，主要分为两种策略：饿汉式（Eager Initialization）和懒汉式（Lazy Initialization）。

饿汉式初始化（Eager Initialization）
在这种策略中，单例实例在程序启动时即被创建，作为类的一个静态成员变量进行初始化。
- 实现： 通常通过在类定义之外初始化一个静态成员指针（如std::shared_ptr或裸指针）来实现 1。

// EagerSingleton.h
class EagerSingleton {
public:
static EagerSingleton& getInstance();
private:
EagerSingleton();
static EagerSingleton* instance;
};
// EagerSingleton.cpp
EagerSingleton* EagerSingleton::instance = new EagerSingleton(); // 程序启动时即创建
EagerSingleton& EagerSingleton::getInstance() {
return *instance;
}

分析： 饿汉式实现简单，并且其初始化过程是线程安全的，因为它发生在程序的静态初始化阶段，此时通常还没有多个线程在活动 1。其主要缺点是，即使应用程序在整个运行期间从未使用过该实例，资源（内存和构造开销）也被消耗了，造成了潜在的浪费 1。此外，如果单例的构造函数依赖于其他静态对象，这种方法极易引发“静态初始化顺序灾难”（Static Initialization Order Fiasco），该问题将在第3节详细讨论。
懒汉式初始化（Lazy Initialization）
与饿汉式相反，懒汉式策略将实例的创建延迟到getInstance()方法首次被调用时。
- 实现 (Pre-C++11): 在getInstance()内部检查一个静态指针成员是否为nullptr。如果为空，则创建一个新实例并赋值给该指针 11。

// LazySingleton.h
class LazySingleton {
public:
static LazySingleton& getInstance();
private:
LazySingleton();
static LazySingleton* instance;
};
// LazySingleton.cpp
LazySingleton* LazySingleton::instance = nullptr;
LazySingleton& LazySingleton::getInstance() {
if (instance == nullptr) { // 检查
instance = new LazySingleton(); // 创建
}
return *instance;
}

分析： 这种方法通过延迟创建来节约资源，只有在实际需要时才进行初始化 11。然而，上述这种经典的懒汉式实现在多线程环境下是
完全不安全的。一个典型的竞态条件（race condition）是：两个或多个线程可能同时通过instance == nullptr的检查，然后每个线程都会尝试创建一个实例，这不仅破坏了单例的唯一性保证，还会导致内存泄漏 7。

2.2 在多线程环境中实现线程安全

为了解决懒汉式初始化的线程安全问题，开发者们探索了多种同步机制。这些机制的演变清晰地反映了C++语言并发能力的提升。

基于互斥锁的锁定（双重检查锁定模式 - DCLP）
双重检查锁定模式（Double-Checked Locking Pattern, DCLP）是一种旨在优化性能的线程安全懒汉式实现。
- 实现： 它在获取锁之前和之后各进行一次nullptr检查。第一次检查是为了避免在实例已创建的情况下产生不必要的锁开销 7。

#include <mutex>
  class DCLPSingleton {
  public:
  static DCLPSingleton& getInstance();
  private:
  DCLPSingleton();
  static DCLPSingleton* instance;
  static std::mutex mtx;
  };
  DCLPSingleton* DCLPSingleton::instance = nullptr;
  std::mutex DCLPSingleton::mtx;
  DCLPSingleton& DCLPSingleton::getInstance() {
  if (instance == nullptr) { // 第一次检查
  std::lock_guard<std::mutex> lock(mtx);
    if (instance == nullptr) { // 第二次检查
    instance = new DCLPSingleton();
    }
    }
    return *instance;
    }

分析： DCLP的目标是在实例初始化后，后续的getInstance()调用可以避免昂贵的锁同步操作 7。然而，在C++11之前的时代，由于缺乏标准的内存模型，DCLP的正确实现是出了名的困难。编译器优化和CPU的乱序执行可能导致一个线程看到了一个非nullptr的instance指针，但此时指针指向的内存中的对象尚未完全构造完成，从而引发严重错误 13。尽管在现代C++中，使用原子操作和正确的内存序可以正确实现DCLP，但鉴于存在更简单、更安全的替代方案，它现在基本上被认为是一种过于复杂且已过时的技术。
std::call_once 方法
C++11标准库提供了一个优雅的机制std::call_once，专门用于确保一个函数或可调用对象在多线程环境下仅被执行一次。
- 实现： 使用std::call_once和一个std::once_flag来保护实例化代码 14。

#include <mutex>
  class CallOnceSingleton {
  public:
  static CallOnceSingleton& getInstance();
  private:
  CallOnceSingleton();
  static CallOnceSingleton* instance;
  static std::once_flag flag;
  };
  CallOnceSingleton* CallOnceSingleton::instance = nullptr;
  std::once_flag CallOnceSingleton::flag;
  CallOnceSingleton& CallOnceSingleton::getInstance() {
  std::call_once(flag,() {
  instance = new CallOnceSingleton();
  });
  return *instance;
  }

分析： 这是实现线程安全懒汉式初始化的一种清晰、明确且符合标准的方式 16。它比手动锁定的代码更不容易出错，并且能清晰地传达“只执行一次”的意图。相较于DCLP，它是一个巨大的进步。虽然它可能比接下来要介绍的Meyers’ Singleton在性能上略有开销（因为每次调用都需要检查once_flag的状态），但对于初始化逻辑较为复杂的场景，它是一个非常好的选择 16。

2.3 现代C++的黄金标准：Meyers’ Singleton

C++11标准的出台为单例模式的实现带来了革命性的简化，催生了目前被广泛认为是最佳实践的方法，即Meyers’ Singleton。

实现： 这种方法将单例实例声明为getInstance()函数内部的一个static局部变量 7。

class MeyersSingleton {
public:
static MeyersSingleton& getInstance();
private:
MeyersSingleton();
// 禁止拷贝和赋值
MeyersSingleton(const MeyersSingleton&) = delete;
MeyersSingleton& operator=(const MeyersSingleton&) = delete;
};
MeyersSingleton& MeyersSingleton::getInstance() {
static MeyersSingleton instance; // C++11保证线程安全初始化
return instance;
}

C++11标准保证： C++11及后续标准明确规定，函数内部的局部静态变量的初始化是线程安全的 12。编译器会自动生成代码（通常使用内部锁或等效机制）来确保，即使多个线程同时首次调用getInstance()，初始化过程也只会发生一次。其他线程将会阻塞等待，直到第一个线程完成初始化 20。
分析： 这种方法巧妙地结合了懒汉式初始化（实例在首次使用时创建）和由语言标准保证的、高效的、对开发者透明的线程安全性 12。它无需任何手动的锁代码，实现极为简洁，因此被广泛认为是现代C++中最简单、最安全、最符合语言习惯的单例实现方式 3。需要注意的是，一些旧的编译器（如Visual Studio 2013）未能完全正确实现这一标准特性，但在所有现代C++编译器中，这已不再是问题 13。

C++中单例实现方式的演进，清晰地展示了现代C++的一个核心设计哲学：将复杂且易错的任务（如并发同步）的负担从开发者转移到编译器和标准库。从脆弱的手动锁定（DCLP），到标准库提供的同步原语（std::call_once），再到最终由语言本身提供保证（Meyers’ Singleton），这个过程不仅是关于一个设计模式的实现，更是关于C++语言如何让并发编程变得更简单、更安全的范例。

2.4 C++单例实现技术对比

为了直观地总结各种实现方式的权衡，下表提供了一个高密度的比较，帮助开发者快速理解不同方法的优劣，并明晰为何Meyers’ Singleton成为当今的推荐标准。

技术	线程安全（初始化）	初始化时机	主要优势	主要缺点/风险
饿汉式初始化	是	程序启动时	实现简单，实例立即可用	浪费资源（若未使用），可能引发静态初始化顺序灾难（SIOF）
经典懒汉式 (指针)	否	首次使用时	节约资源，按需创建	在多线程环境下存在竞态条件，非线程安全
双重检查锁定 (DCLP)	是（需正确实现）	首次使用时	兼顾懒加载和性能（避免后续锁定）	实现复杂，历史上极易出错，在现代C++中已无必要
std::call_once	是	首次使用时	标准库保证线程安全，意图明确	相比Meyers’ Singleton可能有轻微性能开销，代码稍显繁琐
Meyers’ Singleton	是（C++11及以后）	首次使用时	语言标准保证线程安全，代码最简洁，懒加载	可能引发静态销毁顺序问题，依赖于现代编译器支持

第3节：单例的生命周期：初始化与销毁的风险

本节将深入探讨单例模式中常被忽视但至关重要的生命周期问题，特别是与静态对象初始化和销毁顺序相关的“灾难”（fiascos）。这些问题揭示了单例模式作为全局状态管理器的内在脆弱性。

3.1 静态初始化顺序灾难 (SIOF)

问题定义： C++标准保证在单个翻译单元（即单个.cpp源文件及其包含的头文件）内，静态对象的初始化顺序与它们的定义顺序一致。然而，标准对于不同翻译单元之间的静态对象初始化顺序不提供任何保证 25。
灾难的发生： 假设在a.cpp中有一个静态对象A，它的构造函数依赖于b.cpp中的另一个静态对象B。由于链接器可以按任意顺序链接a.o和b.o，因此A的构造函数被调用时，B可能尚未被构造。在这种情况下，访问B将导致未定义行为，通常表现为程序崩溃或数据损坏 25。这个问题对于采用饿汉式初始化的单例或其他全局对象来说，是一个常见且严重的隐患 26。

3.2 使用懒汉式初始化解决SIOF

Meyers’ Singleton的解决方案： Meyers’ Singleton以其优雅的设计完美地解决了静态初始化顺序灾难 26。其核心在于，单例实例是一个函数局部静态变量。根据C++的规则，这类变量只在函数首次被调用时才进行初始化。这意味着初始化过程发生在常规的静态初始化阶段（即main函数执行前）之后，并且仅在对象被实际需要时触发。这种动态的初始化调度机制确保了当单例的构造函数执行时，程序已经进入了正常的执行流程，任何它可能依赖的其他静态对象都已经被安全地构造完毕 25。

3.3 静态销毁顺序灾难与“泄露的单例”

然而，解决了初始化问题并不意味着一劳永逸。单例的生命周期在程序结束时同样面临挑战。

问题定义： 静态对象的销毁顺序通常是其构造顺序的逆序，但这同样只在单个翻译单元内有保证。如果不同的单例之间存在依赖关系，在程序关闭阶段，一个单例的析构函数可能会尝试使用另一个已经被销毁的单例，从而导致与SIOF类似的问题，即静态销毁顺序灾难 24。
“泄露的单例” (Leaky Singleton) 习语： 面对销毁顺序的难题，一种务实但备受争议的解决方案是故意不销毁单例。这通常通过使用new在堆上分配单例实例，但从不调用delete来实现 24。
分析： 这种方法通过让操作系统在进程终止时自动回收内存，完全避免了析构函数之间的依赖冲突，从而避免了程序在退出时崩溃 24。对于许多长时间运行的服务或后台进程而言，这是一种可接受的策略。然而，这种做法的弊端也十分明显：它会触发内存泄漏检测工具的警报，并且如果单例持有的资源（如文件句柄、网络套接字、数据库连接等）需要优雅地关闭和释放，那么“泄露”它们会导致资源未被正确清理，这在很多情况下是不可接受的 24。

Meyers’ Singleton在这方面呈现出一种微妙的权衡。它完美地解决了静态初始化顺序灾难，但其自动销’毁的特性却可能引入静态销毁顺序灾难。这揭示了C++静态对象生命周期管理中的一种根本性的不对称性，并强调了在管理全局对象生命周期方面，不存在一个放之四海而皆准的完美方案。这个问题的根源在于，任何依赖于相互关联的全局对象的设计本身就是脆弱的。这进一步强化了一种观点：单例模式的核心问题在于其全局性，而不仅仅是其具体的实现细节。

第4节：批判性重估：作为反模式的单例

本节将从实现细节转向架构层面的批判性分析，阐述为何在现代软件工程实践中，单例模式常常被视为一种“反模式”（Anti-Pattern）。这些论点主要围绕其对系统可维护性、可测试性和设计原则的负面影响。

4.1 全局状态问题

单例是美化的全局变量： 单例模式通过其全局访问点，实质上在应用程序中引入了一个全局状态，这个状态可以从代码的任何地方被访问和修改 3。
代码推理与调试困难： 全局状态使得程序的行为难以预测和推理。一个模块中的错误可能由系统中一个完全不相关的部分通过单例修改其状态而引发。这种远距离、非显式的相互作用使得问题的根源难以追踪，极大地增加了调试的难度和时间成本 4。Misko Hevery将单例称为“骗子”，因为一个调用了单例方法的函数，其行为可能远不止其名称所暗示的那样，它可能产生了写入文件或修改全局配置等副作用 9。

4.2 紧密耦合与隐藏依赖

硬编码的依赖关系： 任何直接调用Singleton::getInstance()的类，都与那个具体的、特定的Singleton实现类产生了紧密的耦合关系。这种依赖关系是硬编码在类的实现内部的，并不会体现在类的公共接口（如构造函数或方法签名）中。因此，它是一种隐藏的依赖 。
缺乏灵活性： 这种紧密耦合使得替换单例的实现变得异常困难。如果想为系统的不同部分提供不同的实现，或者在不修改所有客户端代码的情况下升级单例，几乎是不可能的。它阻碍了多态和接口隔离原则的应用，严重削弱了系统的灵活性和可扩展性 6。

4.3 单元测试的困境

对可测试性的破坏是现代软件开发中对单例模式最强烈的批评之一。

无法隔离测试单元： 由于单例引入了持久的、跨测试用例的全局状态，单元测试的独立性被彻底打破。一个测试用例对单例状态的修改会“泄露”到下一个测试用例中，导致测试结果依赖于执行顺序，变得不稳定且不可靠 3。
难以使用测试替身（Mock/Stub）： 现代单元测试的核心实践之一是使用测试替身（如模拟对象）来替代被测单元的依赖项，从而实现隔离测试。单例模式的硬编码调用方式（Singleton::getInstance()）和私有构造函数使其几乎不可能在测试环境中注入一个模拟对象。这就意味着，依赖于单例的类无法在不启动单例及其所有依赖项的情况下进行测试，这违背了单元测试的基本原则 3。

4.4 对核心设计原则的违背

单一职责原则 (SRP)： 一个类应该只有一个引起它变化的原因。单例类通常承担了至少两个职责：1) 它自身的业务逻辑；2) 管理自己的生命周期并保证其唯一性。这种职责的混合是SRP的明显违例 3。
开闭原则 (OCP)： 软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。扩展单例的行为很困难。因为客户端代码直接耦合到具体的单例类，所以很难通过继承等方式引入新的行为，而不去修改getInstance()方法或单例类本身，这违背了开闭原则 3。

单例模式从一个备受推崇的设计模式沦为备受争议的反模式，其根本原因在于软件工程价值观的演变。早期的软件设计更侧重于对象交互的结构化，而对自动化单元测试的关注较少。在那个背景下，单例是管理全局资源的合理方案。然而，现代软件开发实践，尤其是在敏捷开发和测试驱动开发（TDD）的影响下，将代码的可测试性、模块化和松耦合提升到了前所未有的高度 3。单元测试要求组件能够被隔离，而单例的设计（私有构造函数和静态访问器）从根本上抵制了这种隔离 6。因此，单例模式的“陨落”并非因为它本身“失效”了，而是因为“优秀设计”的评判标准发生了变化。可测试性和灵活性已成为衡量一个设计模式优劣的头等大事。这也解释了为何大量现代文献的讨论焦点已从“如何正确实现单例”转向了“为何应该用依赖注入替代单例”3。

第5节：面向稳健系统设计的现代替代方案

本节将介绍并分析一系列现代设计模式和方法，它们能够实现单例模式的目标（对服务或资源的集中访问），同时避免其严重的架构缺陷。这些替代方案的核心思想是促进显式的依赖管理，从而构建更模块化、可测试和可维护的系统。

5.1 依赖注入 (DI)：为灵活性与可测试性反转控制

依赖注入是目前公认的替代单例模式的最佳方案。

核心概念： 依赖注入是一种控制反转（Inversion of Control, IoC）的具体形式。一个组件（客户端）不应自己创建其依赖的服务，而应由外部的某个实体（注入器）将这些依赖“注入”给它 34。这种做法将客户端与其依赖的具体实现解耦，客户端只需关心其依赖的接口（抽象）35。
C++中的DI技术：
- 构造函数注入 (Constructor Injection)： 依赖项作为构造函数的参数传入。这是最常用且最稳健的形式，因为它能确保对象在构造完成后即处于一个完整有效的状态 34。

class Service { /*... */ };
class Client {
private:
Service& service;
public:
// 依赖通过构造函数注入
Client(Service& svc) : service(svc) {}
};

Setter注入 (Setter Injection)： 依赖项通过公开的setter方法在对象构造后注入。这种方式允许在运行时动态地更换依赖，但缺点是对象可能在一段时间内处于没有依赖的不完整状态 34。

class Client {
private:
Service* service = nullptr;
public:
void setService(Service* svc) {
service = svc;
}
};

模板参数注入 (Template Parameter Injection)： 依赖项的类型作为模板参数传入。这是一种编译期的依赖注入，它能提供最佳性能（无虚函数调用开销），但缺乏运行时的灵活性 34。

template <typename ServiceType>
  class Client {
  private:
  ServiceType service;
  public:
  //...
  };

DI与单例的对比： 依赖注入通过将依赖关系显式化，极大地改善了系统的设计。它鼓励面向接口编程，并通过允许注入模拟对象（mock objects）来简化单元测试 34。DI直接解决了单例模式所导致的紧密耦合和可测试性差的核心问题。

5.2 服务定位器模式 (Service Locator)

服务定位器是另一种替代方案，它试图在全局访问的便利性和解耦之间找到一个平衡点。

概念： 该模式提供一个中央注册表（即“定位器”），其中包含了对各种服务的引用。组件不再直接调用Singleton::getInstance()，而是向服务定位器请求所需的服务实例 41。
实现： 在应用程序启动时，创建一个定位器对象，并将所有服务实例注册到其中。需要服务的客户端代码则持有对该定位器的引用 41。
分析： 服务定位器确实将客户端与服务的具体实现解耦了，这是一个优于单例之处。然而，它也常被批评为一种“伪装的依赖注入”，因为它仍然隐藏了类的真实依赖。客户端代码的依赖关系从依赖具体服务变成了依赖服务定位器本身，而这个定位器往往又是一个全局可访问的单例，从而可能引入新的全局依赖问题。与DI相比，它使得一个类的依赖关系不够明确 3。

5.3 务实方法：组合根 (Composition Root)

对于许多应用程序而言，最简单、最清晰的解决方案往往不是一个正式的设计模式，而是一种架构原则。

概念： 组合根是指应用程序中一个尽可能靠近程序入口（例如main()函数）的、唯一的、负责构建对象图（object graph）的位置。
机制： 在组合根中，一次性地实例化所有需要的服务和对象。然后，通过构造函数注入的方式，将这些实例作为依赖项传递给需要它们的其他对象。这样，整个应用程序的对象依赖关系就像一棵树一样，从根部（main）开始，逐级向下传递 32。
分析： 这种方法以一种非常务实的方式实现了“单一实例”的目标，而没有引入单例模式“全局访问”的弊端。它使得依赖关系极为明确，系统易于理解、配置和测试。它不需要复杂的DI框架，对于大多数C++项目来说，是一种高度推荐的、简洁而强大的架构方法。

从单例到其现代替代方案的转变，本质上是从隐式依赖管理到显式依赖管理的转变。单例模式依赖于一种隐式的约定：任何函数都可以“秘密地”获取全局实例，而这一行为在其函数签名中是不可见的 3。正是这种隐式性导致了紧密耦合和测试难题。相反，依赖注入将依赖关系变得完全显式：它们直接出现在构造函数或方法的签名中 34。这种显式性是构建模块化、可测试、可维护系统的关键推动力。代码清晰地声明其依赖关系，远比为了所谓的便利而隐藏它们要好得多。

第6节：综合与建议

本节将综合报告的全部发现，为现代C++开发者提供一个细致的结论和可操作的指导方针，旨在平衡理论原则与工程实践。

6.1 单例模式的遗产

单例模式的历程反映了软件设计思想的演变。它诞生于一个旨在为共享资源提供受控、便捷访问的时代，解决了当时许多实际问题。作为“四人帮”设计模式之一，它在软件工程领域留下了深远的影响，其初衷——确保实例唯一性和提供全局访问点——至今仍在许多系统设计需求中有所体现。然而，随着软件工程的成熟，特别是对可测试性、可维护性和松耦合的日益重视，单例模式的固有缺陷——全局状态、隐藏依赖和对单元测试的阻碍——变得愈发不可接受。它从一个基础的设计模式，逐渐演变为一个被广泛警惕甚至唾弃的“反模式”。

6.2 何时（如果真的有必要）使用单例

尽管对单例模式的批评声音占据主流，但在极少数特定场景下，它可能仍然是一个可以考虑的、务实的折衷方案。这些场景通常具备以下特征：

真正的全局性与不变性： 当一个服务是真正意义上的全局、无状态或状态不可变时（例如，一个封装了纯函数数学库或底层C-API的包装器），使用单例的负面影响较小。
小型、独立的应用程序： 在一个规模很小、生命周期短、且可测试性不是首要关注点的工具或脚本中，单例的便利性可能超过其架构上的缺点。
与遗留代码或第三方库集成： 当与一个强制使用全局访问点的系统集成时，使用单例作为适配器可能是最直接的解决方案。

即便在这些情况下，也应首先审慎评估替代方案。单例应被视为最后的选择，而不是默认的解决方案。

6.3 现代的默认选择：依赖注入

本报告强烈建议，将依赖注入作为管理服务和共享资源的默认模式。它通过将依赖关系显式化，从根本上解决了单例模式的诸多问题。采用DI能够带来深远的好处：

提高可测试性： 使得用测试替身替换依赖项变得轻而易举，是实现健壮单元测试的基石。
促进松耦合： 客户端代码依赖于抽象（接口）而非具体实现，增强了系统的灵活性和可扩展性。
提升代码清晰度： 类的依赖关系一目了然，降低了理解和维护代码的认知负荷。

6.4 最终建议

对于寻求构建稳健、可维护的现代C++应用程序的开发者，以下指导原则值得遵循：

优先考虑显式性： 始终选择那些让依赖关系清晰可见的设计。通过构造函数传递依赖项应成为标准实践。
为可测试性而设计： 从项目一开始就将可测试性作为核心设计目标。这一原则会自然而然地引导开发者远离单例等不利于测试的模式。
谨慎使用单例： 如果在经过深思熟虑后，单例被确定为唯一可行的方案，务必使用Meyers’ Singleton（基于函数局部静态变量的线程安全实现）来避免常见的初始化和线程安全陷阱。同时，要清醒地认识到其对测试和维护带来的长期成本。
拥抱组合根： 对于绝大多数应用程序，在main()函数或类似的程序入口点（即组合根）中创建一次依赖项，然后通过对象图将其传递下去，是最高效的策略。它既能满足“单一实例”的需求，又避免了“全局访问”的弊端，是理论与实践的最佳结合点。

引用的著作

C++ Singleton Design Patterns: A Comprehensive Deep Dive | by Chetanp Verma - Medium, 访问时间为十月 2, 2025， https://medium.com/@chetanp.verma98/c-singleton-design-patterns-a-comprehensive-deep-dive-84cf63d1e528
Singleton Method Design Pattern - GeeksforGeeks, 访问时间为十月 2, 2025， https://www.geeksforgeeks.org/system-design/singleton-design-pattern/
What No One Tells You About singleton design pattern c++ and Its Hidden Pitfalls - Verve AI, 访问时间为十月 2, 2025， https://www.vervecopilot.com/interview-questions/what-no-one-tells-you-about-singleton-design-pattern-c-and-its-hidden-pitfalls
Are Singletons Universally Bad? (and if so, why?) : r/cpp_questions - Reddit, 访问时间为十月 2, 2025， https://www.reddit.com/r/cpp_questions/comments/1kgvtz2/are_singletons_universally_bad_and_if_so_why/
Mastering the Singleton Pattern A Guide for Developers - MoldStud, 访问时间为十月 2, 2025， https://moldstud.com/articles/p-mastering-the-singleton-pattern-a-guide-for-developers
Why is Singleton Design Pattern is Considered an Anti-pattern …, 访问时间为十月 2, 2025， https://www.geeksforgeeks.org/system-design/why-is-singleton-design-pattern-is-considered-an-anti-pattern/
Implementing a Thread-Safe Singleton Pattern in C++ | by Tushar Malhotra - Medium, 访问时间为十月 2, 2025， https://medium.com/@tusharmalhotra_81114/implementing-a-thread-safe-singleton-pattern-in-c-9a5ec0efb520
Mastering the Singleton Pattern in Software Architecture: Efficiency and Global Access, 访问时间为十月 2, 2025， https://curatepartners.com/tech-skills-tools-platforms/mastering-the-singleton-pattern-in-software-architecture-efficiency-and-global-access/
Understanding What the Singleton Pattern Costs You - NDepend Blog, 访问时间为十月 2, 2025， https://blog.ndepend.com/singleton-pattern-costs/
Singleton Design Pattern - Step by step Guide - DEV Community, 访问时间为十月 2, 2025， https://dev.to/kurmivivek295/singleton-design-pattern-step-by-step-guide-2bbb
Singleton Pattern in c++. Singleton Pattern is a creational… | by …, 访问时间为十月 2, 2025， https://medium.com/@kamresh485/singleton-pattern-in-c-71c4bf61a3df
Lazy initialization of a C++ singleton in declaration or in implementation - Stack Overflow, 访问时间为十月 2, 2025， https://stackoverflow.com/questions/45053688/lazy-initialization-of-a-c-singleton-in-declaration-or-in-implementation
c++ - How do you implement a singleton efficiently and thread-safely? - Stack Overflow, 访问时间为十月 2, 2025， https://stackoverflow.com/questions/2576022/how-do-you-implement-a-singleton-efficiently-and-thread-safely
Thread Safe Singleton in C++ | Polyglot Blog, 访问时间为十月 2, 2025， https://www.bit-byter.com/blog/files/cpp-singleton.html
create singleTon class using std::call_once - c++ - Stack Overflow, 访问时间为十月 2, 2025， https://stackoverflow.com/questions/55235702/create-singleton-class-using-stdcall-once
C++ Singleton class. A Singleton design pattern for a class… | by Aasma Garg - Medium, 访问时间为十月 2, 2025， https://medium.com/@garg.aasma.08/c-singleton-class-6f8d37d10ae4
singleton class using std::call_once - GitHub Gist, 访问时间为十月 2, 2025， https://gist.github.com/a170304d0d62b80c2e6e23a395a3362a
std::call_once - cppreference.com - C++ Reference, 访问时间为十月 2, 2025， http://en.cppreference.com/w/cpp/thread/call_once.html
Singleton Design Pattern and Meyers Singleton | by Pawara Gunawardena - Medium, 访问时间为十月 2, 2025， https://medium.com/@pawara/singleton-design-pattern-and-meyers-singleton-b5bc5aa2f23c
C++11 Singleton. Static variable is thread safe? Why? - Stack Overflow, 访问时间为十月 2, 2025， https://stackoverflow.com/questions/34457432/c11-singleton-static-variable-is-thread-safe-why
How to Avoid Thread-Safety Cost for Functions’ static Variables - C++ Stories, 访问时间为十月 2, 2025， https://www.cppstories.com/2025/thread_safety_function_statics/
Is local static variable initialization thread-safe in C++11? [duplicate] - Stack Overflow, 访问时间为十月 2, 2025， https://stackoverflow.com/questions/8102125/is-local-static-variable-initialization-thread-safe-in-c11
C++ Singleton - Lei Mao’s Log Book, 访问时间为十月 2, 2025， https://leimao.github.io/blog/CPP-Singleton/
Thread-Safe leaky singleton : r/cpp - Reddit, 访问时间为十月 2, 2025， https://www.reddit.com/r/cpp/comments/7j3s46/threadsafe_leaky_singleton/
What is “static initialization order fiasco” in C++? - Quora, 访问时间为十月 2, 2025， https://www.quora.com/What-is-static-initialization-order-fiasco-in-C
Static initialization order fiasco | How to Avoid Singletons in Modern …, 访问时间为十月 2, 2025， https://www.informit.com/articles/article.aspx?p=3129450&seqNum=3
Mastering Static Objects in C++: Initialization, Destruction, and Best Practices - Medium, 访问时间为十月 2, 2025， https://medium.com/@martin00001313/mastering-static-objects-in-c-initialization-destruction-and-best-practices-760b17734195
Static variable initialization order fiasco : r/cpp - Reddit, 访问时间为十月 2, 2025， https://www.reddit.com/r/cpp/comments/1ia8vkz/static_variable_initialization_order_fiasco/
Static Initialization Order for Singletons - c++ - Stack Overflow, 访问时间为十月 2, 2025， https://stackoverflow.com/questions/53875858/static-initialization-order-for-singletons
Overcoming static initialization order fiasco when a singleton object is involved, 访问时间为十月 2, 2025， https://stackoverflow.com/questions/37833704/overcoming-static-initialization-order-fiasco-when-a-singleton-object-is-involve
C++ Singletons, 访问时间为十月 2, 2025， https://loosechainsaw.github.io/c++/2020/02/16/singleton/
So Singletons are bad, then what? - Software Engineering Stack Exchange, 访问时间为十月 2, 2025， https://softwareengineering.stackexchange.com/questions/40373/so-singletons-are-bad-then-what
c++ - Problems with Singleton Pattern - Stack Overflow, 访问时间为十月 2, 2025， https://stackoverflow.com/questions/1392315/problems-with-singleton-pattern
The Singleton: The Alternatives Monostate Pattern and Dependency …, 访问时间为十月 2, 2025， https://www.modernescpp.com/index.php/the-singleton-the-alternatives/
Dependency Injection in C++ | A Dependency Injected, 访问时间为十月 2, 2025， https://www.codymorterud.com/design/2018/09/07/dependency-injection-cpp.html
Dependency Management in C++ | CodeSignal Learn, 访问时间为十月 2, 2025， https://codesignal.com/learn/courses/clean-code-with-multiple-classes-1/lessons/dependency-management-in-cpp
Dependency Injection in C++ — Blog - Vlad Rișcuția, 访问时间为十月 2, 2025， https://vladris.com/blog/2016/07/06/dependency-injection-in-c.html
oop - Dependency Injection & Singleton Design pattern - Stack …, 访问时间为十月 2, 2025， https://stackoverflow.com/questions/2662842/dependency-injection-singleton-design-pattern
Relation of Singleton pattern with dependency injection - Stack Overflow, 访问时间为十月 2, 2025， https://stackoverflow.com/questions/9191942/relation-of-singleton-pattern-with-dependency-injection
Dependency Injection vs Singleton Pattern - Software Engineering Stack Exchange, 访问时间为十月 2, 2025， https://softwareengineering.stackexchange.com/questions/394026/dependency-injection-vs-singleton-pattern
rsaz/ServiceLocator: Service Locator Pattern Header-Only … - GitHub, 访问时间为十月 2, 2025， https://github.com/rsaz/ServiceLocator
So, singletons are evil; what to do then? - M. Cihan ÖZER, 访问时间为十月 2, 2025， http://www.mcihanozer.com/tips/design-patterns/so-singletons-are-evil-what-to-do-then/

posted @ 2025-10-17 10:58 yxysuanfa 阅读(4) 评论(0) 收藏举报

刷新页面返回顶部

yxysuanfa