005 《Folly Singleton 权威指南：从入门到精通》
🌟🌟🌟本文案由Gemini 2.0 Flash Thinking Experimental 01-21创作，用来辅助学习知识。🌟🌟🌟
书籍大纲
▮▮▮▮ 1. chapter 1： Singleton 模式与 folly::Singleton.h 概览 (Overview of Singleton Pattern and folly::Singleton.h)
▮▮▮▮▮▮▮ 1.1 Singleton 模式：设计模式中的单例 (Singleton Pattern: Singleton in Design Patterns)
▮▮▮▮▮▮▮ 1.2 Singleton 模式的应用场景与优缺点 (Application Scenarios, Advantages and Disadvantages of Singleton Pattern)
▮▮▮▮▮▮▮ 1.3 为什么选择 folly::Singleton.h？(Why Choose folly::Singleton.h?)
▮▮▮▮▮▮▮ 1.4 folly 库简介与环境搭建 (Introduction to Folly Library and Environment Setup)
▮▮▮▮▮▮▮▮▮▮▮ 1.4.1 folly 库的特性与模块 (Features and Modules of Folly Library)
▮▮▮▮▮▮▮▮▮▮▮ 1.4.2 快速开始：引入 folly::Singleton.h (Quick Start: Including folly::Singleton.h)
▮▮▮▮▮▮▮▮▮▮▮ 1.4.3 编译与链接 folly 库 (Compiling and Linking Folly Library)
▮▮▮▮ 2. chapter 2： folly::Singleton.h 基础入门：快速上手 (Basic Introduction to folly::Singleton.h: Getting Started Quickly)
▮▮▮▮▮▮▮ 2.1 最简单的 Singleton 实例：静态成员变量方式 (Simplest Singleton Instance: Static Member Variable Approach)
▮▮▮▮▮▮▮ 2.2 使用 folly::Singleton<T> 创建 Singleton (Creating Singleton using folly::Singleton<T>)
▮▮▮▮▮▮▮ 2.3 getInstance() 方法详解：获取 Singleton 实例 (Detailed Explanation of getInstance() Method: Getting Singleton Instance)
▮▮▮▮▮▮▮ 2.4 线程安全性：folly::Singleton.h 的默认保障 (Thread Safety: Default Guarantee of folly::Singleton.h)
▮▮▮▮ 3. chapter 3： 深入 folly::Singleton.h：核心概念与用法 (Deep Dive into folly::Singleton.h: Core Concepts and Usage)
▮▮▮▮▮▮▮ 3.1 Singleton 的生命周期管理 (Lifecycle Management of Singleton)
▮▮▮▮▮▮▮ 3.2 延迟初始化 (Lazy Initialization) 与提前初始化 (Eager Initialization)
▮▮▮▮▮▮▮ 3.3 自定义初始化函数 (Custom Initialization Function)
▮▮▮▮▮▮▮ 3.4 LeakySingleton：泄漏型 Singleton 的应用 (Application of LeakySingleton: Leaky Singleton)
▮▮▮▮▮▮▮ 3.5 SingletonVoid：无返回值 Singleton 的使用 (Usage of SingletonVoid: Void Return Singleton)
▮▮▮▮ 4. chapter 4： folly::Singleton.h 高级应用与技巧 (Advanced Applications and Techniques of folly::Singleton.h)
▮▮▮▮▮▮▮ 4.1 Singleton 的模板参数详解 (Detailed Explanation of Template Parameters of Singleton)
▮▮▮▮▮▮▮ 4.2 在多线程环境中使用 Singleton (Using Singleton in Multi-threaded Environments)
▮▮▮▮▮▮▮ 4.3 Singleton 与依赖注入 (Dependency Injection) 的结合 (Integration of Singleton and Dependency Injection)
▮▮▮▮▮▮▮ 4.4 使用 Singleton 管理全局资源 (Using Singleton to Manage Global Resources)
▮▮▮▮▮▮▮ 4.5 Singleton 在单元测试中的应用与 Mocking (Application and Mocking of Singleton in Unit Testing)
▮▮▮▮ 5. chapter 5： folly::Singleton.h API 全面解析 (Comprehensive API Analysis of folly::Singleton.h)
▮▮▮▮▮▮▮ 5.1 folly::Singleton<T> 类的详细 API 文档 (Detailed API Documentation of folly::Singleton<T> Class)
▮▮▮▮▮▮▮ 5.2 getInstance() 方法的各种重载形式 (Various Overload Forms of getInstance() Method)
▮▮▮▮▮▮▮ 5.3 reset() 方法：Singleton 重置与销毁 ( reset() Method: Singleton Reset and Destruction)
▮▮▮▮▮▮▮ 5.4 isInstanceCreated() 方法：检查实例是否已创建 (isInstanceCreated() Method: Checking if Instance is Created)
▮▮▮▮▮▮▮ 5.5 其他辅助 API 函数 (Other Auxiliary API Functions)
▮▮▮▮ 6. chapter 6： 实战案例分析： folly::Singleton.h 的应用场景 (Practical Case Study Analysis: Application Scenarios of folly::Singleton.h)
▮▮▮▮▮▮▮ 6.1 日志系统 (Logging System) 的 Singleton 实现 (Singleton Implementation of Logging System)
▮▮▮▮▮▮▮ 6.2 配置管理中心 (Configuration Management Center) 的 Singleton 设计 (Singleton Design of Configuration Management Center)
▮▮▮▮▮▮▮ 6.3 线程池 (Thread Pool) 的 Singleton 管理 (Singleton Management of Thread Pool)
▮▮▮▮▮▮▮ 6.4 缓存 (Cache) 系统的 Singleton 应用 (Singleton Application of Cache System)
▮▮▮▮▮▮▮ 6.5 游戏服务器中的全局管理器 (Global Manager in Game Server) 的 Singleton 模式 (Singleton Pattern of Global Manager in Game Server)
▮▮▮▮ 7. chapter 7： Singleton 模式的替代方案与最佳实践 (Alternatives and Best Practices of Singleton Pattern)
▮▮▮▮▮▮▮ 7.1 Singleton 模式的反模式 (Anti-patterns of Singleton Pattern)
▮▮▮▮▮▮▮ 7.2 依赖注入 (Dependency Injection) 与控制反转 (Inversion of Control) 原则 (Principles of Dependency Injection and Inversion of Control)
▮▮▮▮▮▮▮ 7.3 服务定位器 (Service Locator) 模式 (Service Locator Pattern)
▮▮▮▮▮▮▮ 7.4 何时应该避免使用 Singleton (When to Avoid Using Singleton)
▮▮▮▮▮▮▮ 7.5 folly::Singleton.h 的最佳实践总结 (Summary of Best Practices for folly::Singleton.h)
▮▮▮▮ 8. chapter 8： folly::Singleton.h 源码剖析与实现原理 (Source Code Analysis and Implementation Principles of folly::Singleton.h)
▮▮▮▮▮▮▮ 8.1 folly::Singleton 的内部结构 (Internal Structure of folly::Singleton)
▮▮▮▮▮▮▮ 8.2 线程安全机制的实现细节 (Implementation Details of Thread Safety Mechanism)
▮▮▮▮▮▮▮ 8.3 初始化与销毁流程分析 (Analysis of Initialization and Destruction Process)
▮▮▮▮▮▮▮ 8.4 LeakySingleton 的特殊实现 (Special Implementation of LeakySingleton)
▮▮▮▮▮▮▮ 8.5 与其他 Singleton 实现方式的对比 (Comparison with Other Singleton Implementation Methods)
▮▮▮▮ 9. chapter 9： 总结与展望 (Summary and Outlook)
▮▮▮▮▮▮▮ 9.1 folly::Singleton.h 的优势与局限性总结 (Summary of Advantages and Limitations of folly::Singleton.h)
▮▮▮▮▮▮▮ 9.2 C++ 新标准与 Singleton 模式的未来发展 (Future Development of C++ New Standards and Singleton Pattern)
▮▮▮▮▮▮▮ 9.3 结语：成为 folly::Singleton.h 专家之路 (Conclusion: The Road to Becoming an Expert in folly::Singleton.h)
▮▮▮▮▮▮▮ 附录 A： folly 库的安装与配置 (Installation and Configuration of Folly Library)
▮▮▮▮▮▮▮ 附录 B： 常用 Singleton 实现代码示例 (Code Examples of Common Singleton Implementations)
▮▮▮▮▮▮▮ 附录 C： 术语表 (Glossary)
1. chapter 1： Singleton 模式与 folly::Singleton.h 概览 (Overview of Singleton Pattern and folly::Singleton.h)
1.1 Singleton 模式：设计模式中的单例 (Singleton Pattern: Singleton in Design Patterns)
在软件工程浩瀚的设计模式 (Design Patterns) 星空中，Singleton 模式犹如一颗璀璨的明星，以其简洁而强大的特性，在众多场景中发挥着不可替代的作用。Singleton 模式，又称单例模式，属于创建型模式 (Creational Patterns)，其核心思想在于确保一个类仅有一个实例，并提供一个全局访问点，以便在整个应用程序生命周期内都能够方便地访问和共享该实例。
在传统的面向对象编程中，我们通常通过 new 关键字来创建类的实例。然而，对于某些特殊的类，我们可能并不希望存在多个实例，而是希望全局范围内只有一个实例来协调和管理特定的资源或行为。例如，考虑一个配置管理器 (Configuration Manager) 类，它负责加载和管理应用程序的配置信息。如果允许创建多个配置管理器实例，那么每个实例都可能读取和缓存配置信息，这不仅造成了内存资源的浪费，还可能导致配置信息的不一致性，从而引发难以预料的错误。
Singleton 模式正是为了解决这类问题而诞生的。它通过限制类的实例化过程，确保在任何情况下都只创建一个实例。这个唯一的实例通常被设计为静态成员变量，并通过一个静态的公共方法（通常命名为 getInstance()）来返回该实例。客户端代码无需关心实例的创建细节，只需要通过 getInstance() 方法即可获取到唯一的 Singleton 实例，从而实现对特定资源的集中管理和控制。
Singleton 模式在设计模式家族中占据着重要的地位，它体现了封装变化和控制访问的设计原则。通过将实例化的过程封装在 Singleton 类内部，客户端代码无需关心实例是如何创建和管理的，只需要关注如何使用该实例提供的功能。同时，通过提供全局访问点，Singleton 模式方便了对唯一实例的访问和共享，简化了系统设计，并提高了代码的可维护性和可扩展性。
然而，Singleton 模式并非银弹，它也存在一些潜在的缺点和适用性限制。在后续章节中，我们将深入探讨 Singleton 模式的应用场景、优缺点、以及 folly::Singleton.h 如何优雅地实现和管理 Singleton 实例，帮助读者全面理解和掌握这一重要的设计模式。
1.2 Singleton 模式的应用场景与优缺点 (Application Scenarios, Advantages and Disadvantages of Singleton Pattern)
Singleton 模式以其独有的特性，在软件开发中找到了广泛的应用场景。理解其应用场景和优缺点，有助于我们更好地判断何时以及如何使用 Singleton 模式。
应用场景 (Application Scenarios):
① 资源管理器 (Resource Manager): 例如线程池 (Thread Pool)、数据库连接池 (Database Connection Pool)、设备管理器 (Device Manager) 等。这些管理器负责管理有限的系统资源，使用 Singleton 模式可以确保只有一个实例来协调资源的分配和释放，避免资源竞争和浪费。
② 配置管理器 (Configuration Manager): 应用程序通常只需要一个配置管理器来加载和管理全局配置信息。Singleton 模式可以确保配置信息的一致性和全局访问的便利性。
③ 日志系统 (Logging System): 日志系统通常需要全局唯一的实例来记录应用程序的运行日志。Singleton 模式可以方便地提供全局日志记录服务，并确保日志记录的顺序性和完整性。
④ 缓存 (Cache): 缓存系统可以使用 Singleton 模式来管理全局缓存实例，提高数据访问效率。
⑤ 全局唯一 ID 生成器 (Global Unique ID Generator): 在分布式系统中，可能需要全局唯一的 ID 生成器。Singleton 模式可以确保只有一个 ID 生成器实例，避免 ID 冲突。
⑥ 硬件接口 (Hardware Interface): 当应用程序需要与特定的硬件设备交互时，通常只需要一个硬件接口实例来控制硬件设备。Singleton 模式可以确保对硬件设备的独占访问。
优点 (Advantages):
① 控制实例数量 (Controlled Instantiation): Singleton 模式确保类只有一个实例，严格控制了实例的数量，节省了系统资源。
② 全局访问点 (Global Access Point): Singleton 模式提供了一个全局访问点，方便在程序的任何地方访问唯一的实例，简化了代码的编写和维护。
③ 延迟初始化 (Lazy Initialization): Singleton 模式可以实现延迟初始化，即在第一次访问时才创建实例，避免了不必要的资源消耗。
④ 灵活性 (Flexibility): 相对于全局变量，Singleton 模式提供了更高的灵活性。例如，可以更容易地修改 Singleton 实例的创建方式，而无需修改客户端代码。
缺点 (Disadvantages):
① 违背单一职责原则 (Violation of Single Responsibility Principle): Singleton 模式的类通常承担了两个职责：一是自身的业务逻辑，二是 Singleton 实例的管理。这可能导致类的职责不清，降低代码的可维护性。
② 难以测试 (Difficult to Test): 由于 Singleton 实例是全局唯一的，这使得单元测试变得更加困难。难以对 Singleton 实例进行 Mocking (模拟) 和隔离测试。
③ 隐藏依赖 (Hidden Dependencies): Singleton 模式可能隐藏了类之间的依赖关系。客户端代码可能会隐式地依赖于 Singleton 实例，而这种依赖关系在接口上并不明显，增加了代码的耦合性。
④ 线程安全问题 (Thread Safety Issues): 在多线程环境下，Singleton 实例的创建和访问可能存在线程安全问题，需要额外的同步机制来保证线程安全。
⑤ 生命周期管理问题 (Lifecycle Management Issues): Singleton 实例的生命周期通常与应用程序的生命周期相同步，这可能导致一些资源无法及时释放，或者在某些场景下需要手动管理 Singleton 实例的生命周期。
总而言之，Singleton 模式是一种强大的设计模式，但在使用时需要权衡其优缺点，并根据具体的应用场景进行选择。在某些情况下，过度使用 Singleton 模式可能会导致代码的耦合性增加，可测试性降低。因此，在选择使用 Singleton 模式时，需要仔细评估其必要性和潜在的风险。
1.3 为什么选择 folly::Singleton.h？(Why Choose folly::Singleton.h?)
在 C++ 中，实现 Singleton 模式有多种方法，例如使用静态成员变量、静态局部变量、以及 Meyers' Singleton 等。然而，这些传统的实现方式或多或少存在一些问题，例如线程安全问题、生命周期管理问题、以及代码的复杂性等。folly::Singleton.h 作为 Facebook 开源库 Folly (Facebook Open Source Library) 的一部分，提供了一种更加现代化、高效、且易于使用的 Singleton 模式实现方案。
选择 folly::Singleton.h 的理由:
① 线程安全 (Thread Safety): folly::Singleton.h 默认提供线程安全的 Singleton 实例创建和访问机制。它使用了高效的同步原语，例如双重检查锁定 (Double-Checked Locking) 和原子操作 (Atomic Operations)，确保在多线程环境下 Singleton 实例的正确性和性能。开发者无需手动编写复杂的线程同步代码，即可轻松获得线程安全的 Singleton 实例。
② 延迟初始化 (Lazy Initialization): folly::Singleton.h 默认采用延迟初始化策略。Singleton 实例只在第一次通过 getInstance() 方法访问时才会被创建，避免了程序启动时就创建所有 Singleton 实例的开销，提高了程序的启动速度和资源利用率。
③ 易于使用 (Easy to Use): folly::Singleton.h 提供了简洁明了的 API 接口，使用起来非常方便。只需要简单的几行代码，即可将一个类声明为 Singleton 类，并获取其唯一的实例。
④ 灵活性 (Flexibility): folly::Singleton.h 提供了丰富的配置选项，例如可以自定义初始化函数、选择不同的生命周期管理策略 (例如 LeakySingleton)、以及支持无返回值 Singleton (SingletonVoid) 等。这些选项使得 folly::Singleton.h 能够适应各种不同的应用场景和需求。
⑤ 高性能 (High Performance): folly::Singleton.h 在实现线程安全和延迟初始化的同时，也注重性能优化。它使用了高效的同步原语和内存管理策略，尽量减少锁的竞争和内存分配的开销，保证了 Singleton 实例的访问性能。
⑥ 与 Folly 库的集成 (Integration with Folly Library): folly::Singleton.h 是 Folly 库的一部分，可以方便地与其他 Folly 库的组件集成使用。Folly 库提供了丰富的 C++ 基础库，包括并发、异步、网络、序列化等方面的工具和组件，可以帮助开发者构建高性能、高可靠性的 C++ 应用程序。
⑦ 现代 C++ 特性 (Modern C++ Features): folly::Singleton.h 使用了现代 C++ 的特性，例如模板 (Templates)、移动语义 (Move Semantics)、完美转发 (Perfect Forwarding) 等，代码简洁、高效、且易于维护。
综上所述，folly::Singleton.h 相比于传统的 Singleton 实现方式，具有线程安全、易于使用、灵活、高性能等诸多优点。尤其是在现代 C++ 开发中，以及在需要构建高性能、高并发应用程序的场景下，folly::Singleton.h 是一个更加优秀和值得推荐的选择。通过学习和掌握 folly::Singleton.h，开发者可以更加高效、可靠地实现和管理 Singleton 模式，提高代码质量和开发效率。
1.4 folly 库简介与环境搭建 (Introduction to Folly Library and Environment Setup)
为了深入理解和使用 folly::Singleton.h，我们首先需要对 Folly 库有一个基本的了解，并搭建好 Folly 库的开发环境。Folly (Facebook Open Source Library) 是 Facebook 开源的一套 C++ 基础库，它包含了许多高性能、高可靠性的组件，旨在解决大型互联网应用开发中遇到的各种挑战。
1.4.1 folly 库的特性与模块 (Features and Modules of Folly Library)
Folly 库的设计目标是提供高效、实用、且易于扩展的 C++ 基础库。它在性能、可靠性、和易用性方面都做了很多优化和改进，是构建高性能 C++ 应用的强大工具。
Folly 库的主要特性:
① 高性能 (High Performance): Folly 库在设计和实现上都非常注重性能。它使用了许多优化技术，例如零拷贝 (Zero-Copy)、无锁数据结构 (Lock-Free Data Structures)、高效的内存管理 (Efficient Memory Management) 等，以提高程序的运行效率。
② 现代 C++ (Modern C++): Folly 库大量使用了现代 C++ 的特性，例如模板、Lambda 表达式、移动语义、智能指针 (Smart Pointers) 等。这使得 Folly 库的代码更加简洁、高效、且易于维护。
③ 跨平台 (Cross-Platform): Folly 库支持多种操作系统平台，包括 Linux、macOS、Windows 等。这使得开发者可以方便地在不同的平台上使用 Folly 库。
④ 丰富的组件 (Rich Components): Folly 库包含了丰富的组件，涵盖了并发、异步、网络、序列化、字符串处理、时间处理、容器 (Containers)、函数式编程 (Functional Programming) 等多个方面。这些组件可以帮助开发者快速构建各种类型的 C++ 应用程序。
⑤ 良好的文档 (Good Documentation): Folly 库提供了较为完善的文档，包括 API 文档、示例代码、以及设计文档等。这方便了开发者学习和使用 Folly 库。
⑥ 活跃的社区 (Active Community): Folly 库拥有一个活跃的开源社区，Facebook 也在持续维护和更新 Folly 库。这意味着开发者可以获得及时的技术支持和 bug 修复。
Folly 库的主要模块 (部分):
⚝ folly/Singleton.h: Singleton 模式的实现。
⚝ folly/futures: 异步编程框架，基于 Future 和 Promise。
⚝ folly/io: 高性能 I/O 库，包括异步 I/O、网络编程等。
⚝ folly/json: JSON 解析和生成库。
⚝ folly/Memory.h: 内存管理工具，包括 ArenaAllocator、PoolAllocator 等。
⚝ folly/String.h: 字符串处理工具，包括 FBString、StringPiece 等。
⚝ folly/ThreadLocal.h: 线程局部存储 (Thread-Local Storage) 的实现。
⚝ folly/container: 各种高性能容器，例如 FBVector、F14Map 等。
⚝ folly/concurrency: 并发编程工具，例如 ConcurrentQueue、AtomicHashMap 等。
1.4.2 快速开始：引入 folly::Singleton.h (Quick Start: Including folly::Singleton.h)
要开始使用 folly::Singleton.h，首先需要确保你的项目中已经包含了 Folly 库。具体的 Folly 库安装和配置方法将在附录 A 中详细介绍。在本节，我们假设你已经成功安装了 Folly 库，并配置好了编译环境。
引入 folly::Singleton.h 非常简单，只需要在你的 C++ 代码文件中包含头文件即可：
1
#include <folly/Singleton.h>
一旦包含了头文件，你就可以使用 folly::Singleton<T> 模板类来创建 Singleton 实例了。例如，假设我们有一个名为 MyConfig 的配置类，我们希望将其实现为 Singleton 模式。我们可以这样定义 MyConfig 类：
1
#include <iostream>
2
#include <string>
3
#include <folly/Singleton.h>
4
5
class MyConfig {
6
public:
7
MyConfig() {
8
std::cout << "MyConfig instance created." << std::endl;
9
config_value_ = "default_value";
10
}
11
12
std::string getConfigValue() const {
13
return config_value_;
14
}
15
16
void setConfigValue(const std::string& value) {
17
config_value_ = value;
18
}
19
20
private:
21
std::string config_value_;
22
};
23
24
// 使用 folly::Singleton<MyConfig> 创建 Singleton 实例
25
folly::Singleton<MyConfig> myConfigSingleton;
26
27
int main() {
28
// 通过 getInstance() 方法获取 Singleton 实例
29
MyConfig* config = myConfigSingleton.getInstance();
30
std::cout << "Config value: " << config->getConfigValue() << std::endl;
31
32
// 修改配置值
33
config->setConfigValue("new_value");
34
std::cout << "Config value after modification: " << config->getConfigValue() << std::endl;
35
36
// 再次获取 Singleton 实例，验证是否是同一个实例
37
MyConfig* config2 = myConfigSingleton.getInstance();
38
std::cout << "Config value from config2: " << config2->getConfigValue() << std::endl;
39
40
return 0;
41
}
在这个例子中，我们首先定义了一个 MyConfig 类，然后使用 folly::Singleton<MyConfig> myConfigSingleton; 声明了一个 folly::Singleton 实例 myConfigSingleton，用于管理 MyConfig 类的 Singleton 实例。在 main() 函数中，我们通过 myConfigSingleton.getInstance() 方法获取 MyConfig 的 Singleton 实例，并对其进行操作。
运行这段代码，你将会看到类似以下的输出：
1
MyConfig instance created.
2
Config value: default_value
3
Config value after modification: new_value
4
Config value from config2: new_value
从输出结果可以看出，MyConfig 的实例只被创建了一次，并且通过 getInstance() 方法获取到的始终是同一个实例。这验证了 folly::Singleton.h 成功地实现了 Singleton 模式。
1.4.3 编译与链接 folly 库 (Compiling and Linking Folly Library)
要编译和链接使用了 folly::Singleton.h 的 C++ 代码，你需要确保编译器能够找到 Folly 库的头文件和库文件。具体的编译和链接命令会根据你使用的构建系统 (例如 CMake, Bazel, Make 等) 和操作系统平台而有所不同。
使用 CMake 构建系统 (示例):
假设你的项目使用 CMake 构建系统，并且 Folly 库已经安装在系统的标准路径下 (例如 /usr/local)。你可以在你的 CMakeLists.txt 文件中添加以下内容来链接 Folly 库：
1
cmake_minimum_required(VERSION 3.10)
2
project(MySingletonApp)
3
4
find_package(Folly REQUIRED)
5
6
add_executable(my_singleton_app main.cpp)
7
target_link_libraries(my_singleton_app PRIVATE folly)
在这个 CMakeLists.txt 文件中，find_package(Folly REQUIRED) 命令会查找 Folly 库的配置信息，target_link_libraries(my_singleton_app PRIVATE folly) 命令会将 folly 库链接到你的可执行文件 my_singleton_app。
然后，你可以使用 CMake 来构建你的项目：
1
mkdir build
2
cd build
3
cmake ..
4
make
这将会在 build 目录下生成可执行文件 my_singleton_app。
手动编译和链接 (示例):
如果你不使用构建系统，也可以手动编译和链接 Folly 库。假设 Folly 库的头文件安装在 /usr/local/include/folly 目录下，库文件安装在 /usr/local/lib 目录下。你可以使用类似以下的命令来编译和链接你的代码：
1
g++ -std=c++17 -I/usr/local/include -L/usr/local/lib main.cpp -o my_singleton_app -lfolly -lglog -lgflags -lz -lbz2 -llz4 -lsnappy
这个命令中，-I/usr/local/include 指定了头文件搜索路径，-L/usr/local/lib 指定了库文件搜索路径，-lfolly 指定了链接 folly 库，-lglog -lgflags -lz -lbz2 -llz4 -lsnappy 指定了 Folly 库的依赖库。你需要根据你的实际环境和 Folly 库的依赖关系来调整编译和链接命令。
注意: Folly 库依赖于一些其他的库，例如 glog, gflags, zlib, bzip2, lz4, snappy 等。在编译和链接 Folly 库时，需要确保这些依赖库也已经安装并正确链接。具体的依赖关系和安装方法请参考 Folly 库的官方文档和附录 A。
通过以上步骤，你就可以成功地编译和链接使用了 folly::Singleton.h 的 C++ 代码，并开始使用 folly::Singleton.h 来实现和管理 Singleton 模式了。在接下来的章节中，我们将深入探讨 folly::Singleton.h 的核心概念、用法、高级应用、以及源码实现原理，帮助你全面掌握 folly::Singleton.h，并在实际项目中灵活运用。
END_OF_CHAPTER
2. chapter 2： folly::Singleton.h 基础入门：快速上手 (Basic Introduction to folly::Singleton.h: Getting Started Quickly)
2.1 最简单的 Singleton 实例：静态成员变量方式 (Simplest Singleton Instance: Static Member Variable Approach)
在深入 folly::Singleton.h 之前，我们首先回顾一下最基本、最常见的 Singleton 模式实现方式 —— 静态成员变量（Static Member Variable） 法。这种方法利用 C++ 中静态成员变量的特性，确保类的实例只被创建一次，并提供全局访问点。
知识框架
① Singleton 模式的核心思想：确保一个类只有一个实例，并提供一个全局访问点来访问该实例。
② 静态成员变量法的实现原理：
▮▮▮▮⚝ 将 Singleton 类的构造函数声明为私有（private）或保护（protected），防止外部直接实例化。
▮▮▮▮⚝ 在类内部声明一个静态成员变量，用于存储唯一的 Singleton 实例。
▮▮▮▮⚝ 提供一个静态的公共方法，作为全局访问点，该方法负责创建（如果实例尚未创建）并返回 Singleton 实例的引用或指针。
③ 优点：
▮▮▮▮⚝ 实现简单，代码简洁易懂。
▮▮▮▮⚝ 延迟初始化（Lazy Initialization）：实例在第一次被访问时才创建。
④ 缺点：
▮▮▮▮⚝ 线程安全性问题：在多线程环境下，如果没有额外的同步机制，静态成员变量的初始化可能存在竞争条件（Race Condition），导致创建多个实例。
▮▮▮▮⚝ 缺乏灵活性：初始化逻辑固定，不易扩展和定制。
▮▮▮▮⚝ 生命周期管理不够明确：依赖于静态变量的生命周期，销毁时机不确定。
实战代码
1
#include <iostream>
2
#include <string>
3
4
class SimpleSingleton {
5
private:
6
SimpleSingleton(const std::string& name) : name_(name) {
7
std::cout << "SimpleSingleton instance created with name: " << name_ << std::endl;
8
}
9
~SimpleSingleton() {
10
std::cout << "SimpleSingleton instance destroyed." << std::endl;
11
}
12
SimpleSingleton(const SimpleSingleton&) = delete;
13
SimpleSingleton& operator=(const SimpleSingleton&) = delete;
14
15
std::string name_;
16
17
public:
18
static SimpleSingleton& getInstance() {
19
static SimpleSingleton instance("Default Singleton"); // 静态成员变量，延迟初始化
20
return instance;
21
}
22
23
void printName() const {
24
std::cout << "Singleton Name: " << name_ << std::endl;
25
}
26
};
27
28
int main() {
29
SimpleSingleton::getInstance().printName();
30
SimpleSingleton::getInstance().printName(); // 多次调用 getInstance()，仍然是同一个实例
31
return 0;
32
}
代码解析
⚝ 私有构造函数：SimpleSingleton(const std::string& name) 被声明为 private，阻止了外部直接创建 SimpleSingleton 类的对象。
⚝ 删除拷贝构造函数和赋值运算符：SimpleSingleton(const SimpleSingleton&) = delete; 和 SimpleSingleton& operator=(const SimpleSingleton&) = delete; 防止通过拷贝或赋值创建新的 Singleton 实例，进一步保证单例性。
⚝ 静态成员变量 instance：static SimpleSingleton instance("Default Singleton"); 在 getInstance() 函数内部声明了一个静态的 SimpleSingleton 对象 instance。
▮▮▮▮⚝ 延迟初始化：instance 只会在 getInstance() 函数第一次被调用时初始化。
▮▮▮▮⚝ 局部静态变量的线程安全初始化 (C++11 起)：C++11 标准保证了局部静态变量的初始化是线程安全的。这意味着在多线程环境下，instance 的初始化只会被执行一次，不会出现竞争条件。
⚝ 静态方法 getInstance()：static SimpleSingleton& getInstance() 提供了全局访问 Singleton 实例的入口。它返回静态成员变量 instance 的引用。
总结
静态成员变量方式是实现 Singleton 模式最简洁的方法之一。它利用 C++ 语言的特性，实现了延迟初始化和基本的单例模式。然而，需要注意的是，虽然 C++11 以后局部静态变量的初始化是线程安全的，但这种方法在更复杂的 Singleton 场景下，例如需要更精细的初始化控制、生命周期管理或更强的线程安全保障时，可能会显得力不从心。 这也正是 folly::Singleton.h 诞生的原因之一，它旨在提供更强大、更灵活、更可靠的 Singleton 实现方案。
2.2 使用 folly::Singleton<T> 创建 Singleton (Creating Singleton using folly::Singleton<T>)
folly::Singleton.h 是 Facebook 开源库 Folly (Facebook Open Source Library) 提供的一个强大的 Singleton 模板工具。它在静态成员变量 Singleton 的基础上进行了增强，提供了更完善的功能和更高的灵活性，尤其是在线程安全和生命周期管理方面。
知识框架
① folly::Singleton<T> 的核心优势：
▮▮▮▮⚝ 线程安全：默认提供强大的线程安全保障，无需手动编写复杂的同步代码。
▮▮▮▮⚝ 灵活的初始化：支持自定义初始化函数，可以执行更复杂的初始化逻辑。
▮▮▮▮⚝ 生命周期管理：提供 reset() 方法，允许在程序运行期间销毁和重建 Singleton 实例（在特定场景下）。
▮▮▮▮⚝ 多种 Singleton 变体：提供 LeakySingleton 和 SingletonVoid 等变体，满足不同的 Singleton 需求。
② folly::Singleton<T> 的基本用法：
▮▮▮▮⚝ 使用 folly::Singleton<T>::getInstance() 获取 Singleton 实例。
▮▮▮▮⚝ 模板参数 T 指定 Singleton 类的类型。
▮▮▮▮⚝ 默认情况下，folly::Singleton<T> 使用延迟初始化。
实战代码
首先，确保你已经正确引入了 folly 库，并包含了 folly/Singleton.h 头文件。 关于 folly 库的安装和配置，请参考 附录 A： folly 库的安装与配置 (Installation and Configuration of Folly Library)。
1
#include <iostream>
2
#include <string>
3
#include <folly/Singleton.h>
4
5
class FollySingleton {
6
private:
7
FollySingleton(const std::string& name) : name_(name) {
8
std::cout << "FollySingleton instance created with name: " << name_ << std::endl;
9
}
10
~FollySingleton() {
11
std::cout << "FollySingleton instance destroyed." << std::endl;
12
}
13
FollySingleton(const FollySingleton&) = delete;
14
FollySingleton& operator=(const FollySingleton&) = delete;
15
16
std::string name_;
17
18
public:
19
friend class folly::Singleton<FollySingleton>; // 声明 folly::Singleton<FollySingleton> 为友元类，允许访问私有构造函数
20
21
static FollySingleton& getInstance() {
22
return folly::Singleton<FollySingleton>::getInstance();
23
}
24
25
void printName() const {
26
std::cout << "Singleton Name: " << name_ << std::endl;
27
}
28
};
29
30
int main() {
31
FollySingleton::getInstance().printName();
32
FollySingleton::getInstance().printName(); // 多次调用 getInstance()，仍然是同一个实例
33
return 0;
34
}
代码解析
⚝ 包含头文件：#include <folly/Singleton.h> 引入 folly::Singleton.h 头文件，才能使用 folly::Singleton 模板。
⚝ 友元声明：friend class folly::Singleton<FollySingleton>; 这是使用 folly::Singleton<T> 的关键步骤。由于 folly::Singleton<T> 需要负责创建 FollySingleton 类的实例，因此需要将其声明为 FollySingleton 类的友元类，以便 folly::Singleton<T> 可以访问 FollySingleton 类的私有构造函数。
⚝ 静态方法 getInstance()：
1
static FollySingleton& getInstance() {
2
return folly::Singleton<FollySingleton>::getInstance();
3
}
▮▮▮▮⚝ 这里的 getInstance() 方法实际上是转发调用了 folly::Singleton<FollySingleton>::getInstance()。
▮▮▮▮⚝ folly::Singleton<FollySingleton>::getInstance() 才是真正负责创建和返回 FollySingleton 实例的方法。
▮▮▮▮⚝ 通过这种方式，我们将 Singleton 实例的创建和管理委托给了 folly::Singleton<T> 模板类。
对比静态成员变量方式
| 特性 | 静态成员变量方式 | folly::Singleton<T> |
|---|---|---|
| 线程安全 | C++11 后局部静态变量初始化线程安全，但功能有限 | 默认提供强大的线程安全保障，机制更完善 |
| 初始化方式 | 静态初始化，灵活性较差 | 支持自定义初始化函数，更灵活 |
| 生命周期管理 | 依赖静态变量生命周期，管理能力弱 | 提供 reset() 方法，可进行更精细的生命周期控制（特定场景） |
| 代码复杂度 | 简单 | 稍复杂，需要友元声明，但功能更强大 |
| 适用场景 | 简单 Singleton 场景，对线程安全和灵活性要求不高 | 各种 Singleton 场景，尤其是在多线程和需要灵活控制的场景 |
总结
folly::Singleton<T> 提供了一种更加强大和灵活的方式来创建 Singleton。它通过模板类封装了 Singleton 的创建和管理逻辑，并提供了线程安全、灵活初始化和生命周期管理等增强功能。 使用 folly::Singleton<T>，开发者可以更专注于 Singleton 类的业务逻辑，而无需过多关注 Singleton 模式的底层实现细节，尤其是在线程安全方面，folly::Singleton<T> 提供了默认的保障，大大简化了多线程环境下的 Singleton 开发。
2.3 getInstance() 方法详解：获取 Singleton 实例 (Detailed Explanation of getInstance() Method: Getting Singleton Instance)
getInstance() 方法是访问 folly::Singleton<T> 管理的 Singleton 实例的唯一入口。理解 getInstance() 方法的工作原理和使用方式，是掌握 folly::Singleton.h 的关键。
知识框架
① getInstance() 方法的作用：
▮▮▮▮⚝ 获取 folly::Singleton<T> 管理的 Singleton 实例的引用。
▮▮▮▮⚝ 负责 Singleton 实例的延迟初始化：如果实例尚未创建，getInstance() 会负责创建实例；如果实例已经创建，则直接返回已存在的实例。
▮▮▮▮⚝ 提供线程安全的实例获取机制。
② getInstance() 方法的用法：
▮▮▮▮⚝ 通过 folly::Singleton<T>::getInstance() 静态方法调用获取实例。
▮▮▮▮⚝ 返回值类型为 T&，即 Singleton 类的引用。
③ getInstance() 方法的重载形式：
▮▮▮▮⚝ folly::Singleton<T>::getInstance()：最常用的形式，使用默认构造函数创建 Singleton 实例。
▮▮▮▮⚝ folly::Singleton<T>::getInstance(Args&&... args)：允许传递参数给 Singleton 类的构造函数，用于创建实例。 这在需要根据不同参数创建 Singleton 实例时非常有用。
▮▮▮▮⚝ folly::Singleton<T>::getInstance(InitializationFunction initFunction)：允许自定义初始化函数，在 Singleton 实例创建后执行额外的初始化逻辑。
实战代码
1. 使用默认构造函数获取实例
这是最基本的使用方式，如之前的例子所示：
1
FollySingleton& singletonInstance = FollySingleton::getInstance();
2
singletonInstance.printName();
2. 使用带参数的构造函数获取实例
假设 FollySingleton 类的构造函数可以接受一个 std::string 类型的参数来设置 name。
1
#include <iostream>
2
#include <string>
3
#include <folly/Singleton.h>
4
5
class FollySingleton {
6
private:
7
FollySingleton(const std::string& name) : name_(name) {
8
std::cout << "FollySingleton instance created with name: " << name_ << std::endl;
9
}
10
~FollySingleton() {
11
std::cout << "FollySingleton instance destroyed." << std::endl;
12
}
13
FollySingleton(const FollySingleton&) = delete;
14
FollySingleton& operator=(const FollySingleton&) = delete;
15
16
std::string name_;
17
18
public:
19
friend class folly::Singleton<FollySingleton>;
20
21
static FollySingleton& getInstance(const std::string& name) { // 注意 getInstance 接受参数
22
return folly::Singleton<FollySingleton>::getInstance(name); // 转发参数给 folly::Singleton::getInstance
23
}
24
25
void printName() const {
26
std::cout << "Singleton Name: " << name_ << std::endl;
27
}
28
};
29
30
int main() {
31
FollySingleton::getInstance("Custom Name Singleton").printName(); // 传递参数 "Custom Name Singleton"
32
FollySingleton::getInstance("Another Name").printName(); // 再次调用，参数将被忽略，仍然是同一个实例
33
return 0;
34
}
代码解析
⚝ getInstance(const std::string& name) 重载：我们在 FollySingleton 类中添加了一个静态方法 getInstance(const std::string& name)。
⚝ 参数转发：return folly::Singleton<FollySingleton>::getInstance(name); 这个重载的 getInstance() 方法将接收到的参数 name 转发给了 folly::Singleton<FollySingleton>::getInstance(name)。 这样，folly::Singleton<T> 内部在创建 FollySingleton 实例时，就会使用这个参数来调用 FollySingleton 的构造函数。
⚝ 首次调用生效：需要注意的是，参数只在 第一次 调用 getInstance(Args&&... args) 时生效，用于创建 Singleton 实例。后续的 getInstance() 调用将直接返回已经创建的实例，忽略 传入的参数。
3. 使用自定义初始化函数获取实例
1
#include <iostream>
2
#include <string>
3
#include <folly/Singleton.h>
4
#include <memory>
5
6
class FollySingleton {
7
private:
8
FollySingleton(const std::string& name) : name_(name) {
9
std::cout << "FollySingleton instance created with name: " << name_ << std::endl;
10
}
11
~FollySingleton() {
12
std::cout << "FollySingleton instance destroyed." << std::endl;
13
}
14
FollySingleton(const FollySingleton&) = delete;
15
FollySingleton& operator=(const FollySingleton&) = delete;
16
17
std::string name_;
18
int count_ = 0; // 新增成员变量
19
20
public:
21
friend class folly::Singleton<FollySingleton>;
22
23
static FollySingleton& getInstance() {
24
return folly::Singleton<FollySingleton>::getInstance([](FollySingleton* instance) { // Lambda 表达式作为初始化函数
25
instance->count_ = 100; // 在实例创建后，设置 count_ 的初始值
26
std::cout << "Custom initialization function called." << std::endl;
27
});
28
}
29
30
void printInfo() const {
31
std::cout << "Singleton Name: " << name_ << ", Count: " << count_ << std::endl;
32
}
33
};
34
35
int main() {
36
FollySingleton::getInstance().printInfo();
37
return 0;
38
}
代码解析
⚝ 自定义初始化函数 (Initialization Function)：
1
folly::Singleton<FollySingleton>::getInstance([](FollySingleton* instance) {
2
instance->count_ = 100;
3
std::cout << "Custom initialization function called." << std::endl;
4
});
▮▮▮▮⚝ 我们使用了 Lambda 表达式作为初始化函数，传递给 getInstance() 方法。
▮▮▮▮⚝ Lambda 表达式的参数 instance 是指向新创建的 FollySingleton 实例的指针。
▮▮▮▮⚝ 在 Lambda 表达式内部，我们可以对 instance 指针指向的对象进行任何初始化操作，例如设置成员变量 count_ 的值。
▮▮▮▮⚝ 初始化函数会在 Singleton 实例 创建之后，但在 getInstance() 方法返回实例引用之前被调用。
总结
getInstance() 方法是 folly::Singleton<T> 的核心 API，它提供了多种重载形式，以满足不同的 Singleton 实例化和初始化需求。 开发者可以根据实际场景选择合适的 getInstance() 方法，灵活地创建和获取 Singleton 实例。 无论是使用默认构造函数、带参数的构造函数，还是自定义初始化函数，folly::Singleton<T>::getInstance() 都保证了线程安全和延迟初始化，并提供了统一的访问入口。
2.4 线程安全性：folly::Singleton.h 的默认保障 (Thread Safety: Default Guarantee of folly::Singleton.h)
线程安全性是 Singleton 模式在多线程环境下需要重点关注的问题。 传统的 Singleton 实现方式，例如静态成员变量法，在没有额外同步机制的情况下，可能存在线程安全问题。 folly::Singleton.h 的一个重要优势就是它默认提供了强大的线程安全保障，使得开发者可以放心地在多线程环境中使用 Singleton，而无需手动编写复杂的同步代码。
知识框架
① 线程安全问题：在多线程环境下，多个线程可能同时尝试访问和初始化 Singleton 实例，如果没有适当的同步机制，可能会导致：
▮▮▮▮⚝ 竞态条件 (Race Condition)：多个线程同时进入 Singleton 实例的创建逻辑，导致创建多个实例，破坏单例性。
▮▮▮▮⚝ 数据竞争 (Data Race)：多个线程同时访问和修改 Singleton 实例的内部状态，导致数据不一致或程序崩溃。
② folly::Singleton.h 的线程安全机制：
▮▮▮▮⚝ 内部同步机制：folly::Singleton.h 内部使用了高效的同步机制（例如，基于原子操作和互斥锁的组合），确保在多线程环境下，Singleton 实例的创建和访问是线程安全的。
▮▮▮▮⚝ Double-Checked Locking (DCL) 的变体：folly::Singleton.h 的实现原理类似于 Double-Checked Locking，但进行了优化，避免了传统 DCL 的一些潜在问题（例如，内存模型问题）。
▮▮▮▮⚝ 保证只初始化一次：无论多少个线程同时调用 getInstance()，folly::Singleton.h 都能保证 Singleton 实例只被初始化一次。
③ 默认线程安全：folly::Singleton.h 的线程安全是默认提供的，开发者无需显式地编写任何同步代码，即可获得线程安全的 Singleton 实例。
实战代码
为了演示 folly::Singleton.h 的线程安全性，我们可以创建一个多线程程序，让多个线程同时尝试获取 Singleton 实例，并观察是否会创建多个实例。
1
#include <iostream>
2
#include <string>
3
#include <folly/Singleton.h>
4
#include <thread>
5
#include <vector>
6
7
class ThreadSafeSingleton {
8
private:
9
ThreadSafeSingleton() {
10
std::cout << "ThreadSafeSingleton instance created by thread: " << std::this_thread::get_id() << std::endl;
11
}
12
~ThreadSafeSingleton() {
13
std::cout << "ThreadSafeSingleton instance destroyed." << std::endl;
14
}
15
ThreadSafeSingleton(const ThreadSafeSingleton&) = delete;
16
ThreadSafeSingleton& operator=(const ThreadSafeSingleton&) = delete;
17
18
public:
19
friend class folly::Singleton<ThreadSafeSingleton>;
20
21
static ThreadSafeSingleton& getInstance() {
22
return folly::Singleton<ThreadSafeSingleton>::getInstance();
23
}
24
25
void doSomething() const {
26
// 模拟 Singleton 实例的操作
27
}
28
};
29
30
void threadFunction() {
31
ThreadSafeSingleton::getInstance().doSomething();
32
}
33
34
int main() {
35
std::vector<std::thread> threads;
36
int numThreads = 10;
37
38
for (int i = 0; i < numThreads; ++i) {
39
threads.emplace_back(threadFunction); // 创建多个线程，同时调用 getInstance()
40
}
41
42
for (auto& thread : threads) {
43
thread.join(); // 等待所有线程结束
44
}
45
46
std::cout << "Main thread finished." << std::endl;
47
return 0;
48
}
代码解析
⚝ 多线程环境模拟：main() 函数中创建了 numThreads (例如 10) 个线程，每个线程都执行 threadFunction() 函数。
⚝ 并发调用 getInstance()：threadFunction() 函数中调用 ThreadSafeSingleton::getInstance() 获取 Singleton 实例。 多个线程会并发地执行这个操作。
⚝ 观察输出：运行程序，观察控制台输出。 如果 folly::Singleton.h 的线程安全机制工作正常，你将只会看到 一次 "ThreadSafeSingleton instance created..." 的输出，即使有多个线程同时调用 getInstance()。 这表明 folly::Singleton.h 成功地保证了在多线程环境下只创建了一个 Singleton 实例。
总结
folly::Singleton.h 提供的默认线程安全保障是其最重要的特性之一。 它通过内部高效的同步机制，确保了 Singleton 实例在多线程环境下的正确创建和访问，避免了竞态条件和数据竞争等问题。 开发者可以充分利用 folly::Singleton.h 的线程安全特性，简化多线程 Singleton 的开发，提高程序的可靠性和稳定性。 在后续章节中，我们将更深入地探讨 folly::Singleton.h 的线程安全实现原理，以及在更复杂的多线程场景下的应用。
END_OF_CHAPTER
3. chapter 3： 深入 folly::Singleton.h：核心概念与用法 (Deep Dive into folly::Singleton.h: Core Concepts and Usage)
3.1 Singleton 的生命周期管理 (Lifecycle Management of Singleton)
Singleton 模式的核心目标是确保一个类只有一个实例，并提供一个全局访问点。然而，与任何对象一样，Singleton 实例也有其生命周期，即从创建到销毁的过程。有效地管理 Singleton 的生命周期对于确保程序的正确性和资源利用率至关重要。folly::Singleton.h 提供了机制来简化和安全地管理 Singleton 的生命周期。
① Singleton 的创建：
在传统的 Singleton 模式实现中，实例通常在第一次被请求时创建（延迟初始化），或者在程序启动时立即创建（提前初始化）。folly::Singleton 默认采用延迟初始化（Lazy Initialization）策略。这意味着只有当第一次调用 getInstance() 方法时，Singleton 实例才会被创建。这种方式的优点是避免了程序启动时可能不必要的资源消耗，只有在真正需要 Singleton 实例时才进行初始化。
② Singleton 的使用：
一旦 Singleton 实例被创建，它就可以在程序的任何地方通过 getInstance() 方法被访问和使用。folly::Singleton 确保在多线程环境下，getInstance() 方法是线程安全的，这意味着即使多个线程同时尝试获取 Singleton 实例，也只有一个实例会被创建，并且所有线程都将获得对同一实例的引用。
③ Singleton 的销毁：
Singleton 的销毁是生命周期管理中一个容易被忽视但非常重要的环节。在传统的 Singleton 实现中，由于实例通常是静态的，其销毁时机和方式可能比较复杂，尤其是在涉及资源管理时。folly::Singleton 提供了 reset() 方法来显式地销毁 Singleton 实例。
⚝ 默认销毁行为：默认情况下，folly::Singleton 使用 default_delete 来销毁 Singleton 实例，这意味着它会调用实例类型的析构函数。对于大多数情况，这已经足够了。
⚝ 显式销毁 reset()：你可以显式地调用 folly::Singleton<T>::reset() 方法来销毁 Singleton 实例。reset() 方法会执行以下操作：
▮▮▮▮⚝ 如果 Singleton 实例已经创建，它会调用实例的析构函数。
▮▮▮▮⚝ 然后，它会将内部的实例指针重置为空，表示 Singleton 实例已被销毁。
▮▮▮▮⚝ 下一次调用 getInstance() 时，将会创建一个新的 Singleton 实例。
1
#include <folly/Singleton.h>
2
#include <iostream>
3
4
class MySingleton {
5
public:
6
MySingleton() {
7
std::cout << "MySingleton 构造函数被调用" << std::endl;
8
}
9
~MySingleton() {
10
std::cout << "MySingleton 析构函数被调用" << std::endl;
11
}
12
13
void doSomething() {
14
std::cout << "MySingleton 正在工作" << std::endl;
15
}
16
};
17
18
// 定义 folly::Singleton
19
folly::Singleton<MySingleton> singletonInstance;
20
21
int main() {
22
// 第一次获取实例，会触发构造函数
23
MySingleton* instance1 = singletonInstance.getInstance();
24
instance1->doSomething();
25
26
// 第二次获取实例，不会再次构造，返回相同的实例
27
MySingleton* instance2 = singletonInstance.getInstance();
28
instance2->doSomething();
29
30
// 显式重置 Singleton，触发析构函数
31
singletonInstance.reset();
32
33
// 再次获取实例，会重新构造
34
MySingleton* instance3 = singletonInstance.getInstance();
35
instance3->doSomething();
36
37
return 0;
38
}
代码解释：
⚝ 当第一次调用 singletonInstance.getInstance() 时，MySingleton 的构造函数被调用，实例被创建。
⚝ 第二次调用 singletonInstance.getInstance() 时，由于实例已经存在，构造函数不会再次被调用，返回的是同一个实例。
⚝ 调用 singletonInstance.reset() 时，MySingleton 的析构函数被调用，实例被销毁。
⚝ 第三次调用 singletonInstance.getInstance() 时，由于之前的实例已被销毁，构造函数再次被调用，创建一个新的实例。
④ 生命周期管理的注意事项：
⚝ 避免过早销毁：在程序运行期间，如果 Singleton 实例被意外销毁（例如，错误地调用了 reset()），可能会导致依赖于该 Singleton 的代码出现错误。因此，应该谨慎使用 reset() 方法，确保在确实需要销毁 Singleton 实例时才调用。
⚝ 资源释放：如果 Singleton 实例持有重要的资源（例如，文件句柄、网络连接等），确保在 Singleton 销毁时正确释放这些资源。这通常在 Singleton 类的析构函数中完成。
⚝ 全局销毁顺序问题：在 C++ 中，全局对象的销毁顺序是不确定的，这可能会导致 Singleton 依赖的其他全局对象在 Singleton 销毁时已经被销毁，从而引发问题。folly::Singleton 自身并不能完全解决全局销毁顺序问题，但通过显式的 reset() 方法，可以提供更精细的控制，在某些场景下可以缓解这类问题。最佳实践是尽量减少 Singleton 对其他全局对象的依赖，或者使用更明确的生命周期管理策略，例如依赖注入（Dependency Injection）。
总而言之，folly::Singleton.h 通过提供 getInstance() 和 reset() 方法，为 Singleton 模式的生命周期管理提供了清晰的接口。开发者可以利用这些接口来控制 Singleton 实例的创建、访问和销毁，从而更好地管理程序的资源和状态。
3.2 延迟初始化 (Lazy Initialization) 与 提前初始化 (Eager Initialization)
在 Singleton 模式中，实例的初始化时机是一个重要的设计决策。主要有两种初始化策略：延迟初始化（Lazy Initialization） 和 提前初始化（Eager Initialization）。folly::Singleton.h 默认采用延迟初始化，但也允许通过一些方式实现提前初始化。
① 延迟初始化（Lazy Initialization）：
⚝ 定义：延迟初始化指的是 Singleton 实例在第一次被请求时才创建。换句话说，只有当调用 getInstance() 方法时，如果实例尚未创建，才会执行 Singleton 对象的构造过程。
⚝ 优点：
▮▮▮▮⚝ 节省资源：如果 Singleton 实例在程序的运行过程中不一定会被用到，延迟初始化可以避免在程序启动时就创建实例，从而节省了启动时间和内存资源。这对于资源敏感的应用或者启动速度要求高的应用尤其重要。
▮▮▮▮⚝ 避免循环依赖问题：在复杂的系统中，全局对象的初始化顺序可能导致循环依赖问题。延迟初始化可以推迟 Singleton 实例的创建，直到真正需要时才进行，从而在某些情况下可以避免或简化循环依赖的处理。
⚝ 缺点：
▮▮▮▮⚝ 线程安全问题：在多线程环境下，延迟初始化需要考虑线程安全问题。如果多个线程同时首次调用 getInstance()，需要确保只有一个线程能够成功创建实例，并且其他线程能够安全地获取到该实例。folly::Singleton.h 已经默认处理了线程安全问题，开发者无需额外关注。
▮▮▮▮⚝ 首次访问性能开销：由于实例在首次访问时才创建，因此首次调用 getInstance() 方法可能会有一定的性能开销，尤其是在初始化过程比较耗时的情况下。
⚝ folly::Singleton 的默认延迟初始化：folly::Singleton 默认采用延迟初始化。当你定义一个 folly::Singleton<T> 对象时，实例 T 并不会立即被创建。只有当你第一次调用 getInstance() 方法时，实例 T 的构造函数才会被调用，实例才会被真正创建。
② 提前初始化（Eager Initialization）：
⚝ 定义：提前初始化指的是 Singleton 实例在程序启动时，在任何代码请求之前就创建好。通常，这可以通过静态初始化来实现。
⚝ 优点：
▮▮▮▮⚝ 线程安全简单：提前初始化在程序启动的单线程阶段完成，因此不存在多线程并发创建实例的线程安全问题。
▮▮▮▮⚝ 首次访问无性能开销：由于实例在程序启动时已经创建好，后续任何对 getInstance() 的调用都只是简单地返回已创建的实例，没有额外的初始化开销。
▮▮▮▮⚝ 初始化时机确定：实例的初始化时机在程序启动阶段，更容易预测和管理。
⚝ 缺点：
▮▮▮▮⚝ 资源浪费：如果 Singleton 实例在程序的运行过程中始终没有被用到，提前初始化会造成资源浪费，尤其是在实例的创建和初始化过程比较耗资源的情况下。
▮▮▮▮⚝ 可能增加启动时间：如果程序中有很多 Singleton 实例都采用提前初始化，并且它们的初始化过程比较耗时，可能会增加程序的启动时间。
▮▮▮▮⚝ 可能引发初始化顺序问题：全局对象的静态初始化顺序在 C++ 中并非完全确定，提前初始化可能会受到全局对象初始化顺序问题的影响，尤其是在 Singleton 实例依赖于其他全局对象时。
⚝ folly::Singleton 实现提前初始化：虽然 folly::Singleton 默认是延迟初始化，但可以通过一些技巧来实现提前初始化。一种方式是在程序启动的早期阶段，例如在 main 函数的开始处，显式地调用一次 getInstance() 方法，强制 Singleton 实例被创建。
1
#include <folly/Singleton.h>
2
#include <iostream>
3
4
class MySingleton {
5
public:
6
MySingleton() {
7
std::cout << "MySingleton 构造函数被调用 (提前初始化)" << std::endl;
8
}
9
void doSomething() {
10
std::cout << "MySingleton 正在工作" << std::endl;
11
}
12
};
13
14
folly::Singleton<MySingleton> singletonInstance;
15
16
int main() {
17
// 提前初始化 Singleton 实例
18
MySingleton* earlyInstance = singletonInstance.getInstance();
19
std::cout << "Singleton 提前初始化完成" << std::endl;
20
21
// 后续使用
22
earlyInstance->doSomething();
23
MySingleton* laterInstance = singletonInstance.getInstance();
24
laterInstance->doSomething();
25
26
return 0;
27
}
代码解释：
⚝ 在 main 函数的开始处，我们立即调用 singletonInstance.getInstance()。这将强制 MySingleton 的实例在程序启动的早期就被创建，实现了提前初始化。
⚝ 后续对 getInstance() 的调用将直接返回已经创建的实例，不会再次触发构造函数。
③ 选择初始化策略：
选择延迟初始化还是提前初始化，取决于具体的应用场景和需求。
⚝ 优先考虑延迟初始化：在大多数情况下，延迟初始化是更合理的选择，因为它能够节省资源，避免不必要的开销。特别是当 Singleton 实例的创建成本较高，或者不一定会被用到时，延迟初始化是更好的选择。
⚝ 考虑提前初始化的场景：在以下情况下，可以考虑提前初始化：
▮▮▮▮⚝ 性能敏感的应用：如果对首次访问 Singleton 的性能要求非常高，不希望有任何初始化延迟，可以采用提前初始化。
▮▮▮▮⚝ 线程安全要求极高：虽然 folly::Singleton 已经处理了延迟初始化的线程安全问题，但在某些极端的性能敏感场景下，提前初始化可以完全避免任何线程同步的开销。
▮▮▮▮⚝ 初始化过程必须在程序启动时完成：某些 Singleton 实例的初始化可能依赖于程序启动时的一些环境或配置，必须在程序启动的早期阶段完成，这时也需要采用提前初始化。
总而言之，folly::Singleton.h 默认提供了延迟初始化的便利性和线程安全性。开发者可以根据具体需求，选择默认的延迟初始化，或者通过显式调用 getInstance() 等方式实现提前初始化，灵活地管理 Singleton 实例的初始化时机。
3.3 自定义初始化函数 (Custom Initialization Function)
在某些情况下，简单的默认构造函数可能无法满足 Singleton 实例的初始化需求。例如，Singleton 实例可能需要从配置文件中读取数据，或者进行一些复杂的初始化操作。folly::Singleton.h 允许开发者提供自定义初始化函数（Custom Initialization Function），以便在创建 Singleton 实例时执行特定的初始化逻辑。
① 为什么需要自定义初始化函数：
⚝ 复杂的初始化逻辑：Singleton 实例的初始化可能不仅仅是简单的对象构造，可能涉及到读取配置文件、连接数据库、初始化网络资源等复杂操作。这些操作无法在默认构造函数中完成，或者放在构造函数中会使构造函数过于臃肿。
⚝ 参数化初始化：有时 Singleton 实例的初始化需要一些参数，例如配置文件的路径、数据库连接字符串等。默认的 getInstance() 方法无法传递参数给构造函数。
⚝ 初始化失败处理：在初始化过程中，可能会发生错误，例如配置文件不存在、数据库连接失败等。自定义初始化函数可以提供更灵活的错误处理机制，例如抛出异常、记录日志、或者返回错误码。
② 如何使用自定义初始化函数：
folly::Singleton<T> 允许你通过模板参数来指定自定义初始化函数。这个初始化函数必须是一个可调用对象（Callable Object），例如普通函数、Lambda 表达式、函数对象等。当第一次调用 getInstance() 方法，并且 Singleton 实例尚未创建时，folly::Singleton 将会调用你提供的自定义初始化函数来创建和初始化实例。
1
#include <folly/Singleton.h>
2
#include <iostream>
3
#include <fstream>
4
#include <stdexcept>
5
6
class ConfigManager {
7
public:
8
std::string configValue;
9
10
ConfigManager(const std::string& value) : configValue(value) {
11
std::cout << "ConfigManager 构造函数被调用，配置值: " << configValue << std::endl;
12
}
13
14
static ConfigManager* createFromConfigFile(const std::string& filePath) {
15
std::ifstream configFile(filePath);
16
if (!configFile.is_open()) {
17
throw std::runtime_error("无法打开配置文件: " + filePath);
18
}
19
std::string line;
20
std::getline(configFile, line);
21
return new ConfigManager(line);
22
}
23
24
void printConfigValue() const {
25
std::cout << "配置值: " << configValue << std::endl;
26
}
27
};
28
29
// 使用自定义初始化函数 createFromConfigFile 创建 Singleton
30
folly::Singleton<ConfigManager, ConfigManager*(*)(const std::string&)> configManagerInstance(
31
ConfigManager::createFromConfigFile, "config.txt");
32
33
int main() {
34
try {
35
ConfigManager* config = configManagerInstance.getInstance();
36
config->printConfigValue();
37
} catch (const std::exception& e) {
38
std::cerr << "初始化 ConfigManager 失败: " << e.what() << std::endl;
39
return 1;
40
}
41
return 0;
42
}
代码解释：
⚝ 我们定义了一个 ConfigManager 类，它的构造函数接受一个配置值。
⚝ 我们提供了一个静态成员函数 createFromConfigFile，它负责从配置文件中读取配置值，并创建 ConfigManager 实例。这个函数就是我们的自定义初始化函数。
⚝ 在定义 folly::Singleton 实例 configManagerInstance 时，我们使用了模板参数来指定自定义初始化函数 ConfigManager::createFromConfigFile，并传递了配置文件路径 "config.txt" 作为参数。
⚝ 当第一次调用 configManagerInstance.getInstance() 时，folly::Singleton 会调用 ConfigManager::createFromConfigFile("config.txt") 来创建 ConfigManager 实例。
③ 自定义初始化函数的签名：
自定义初始化函数的签名需要与 folly::Singleton 的模板参数相匹配。对于 folly::Singleton<T, Initializer>，Initializer 应该是一个函数类型，其返回类型是指向 T 的指针，并且可以接受任意数量的参数（这些参数将在 folly::Singleton 的构造函数中传递）。
在上面的例子中，ConfigManager::createFromConfigFile 的签名是 ConfigManager*(*)(const std::string&)，它返回 ConfigManager*，并接受一个 const std::string& 参数。我们在 folly::Singleton 的构造函数中传递了 "config.txt" 字符串，这个字符串会被传递给 createFromConfigFile 函数。
④ Lambda 表达式作为初始化函数：
除了静态成员函数，你也可以使用 Lambda 表达式作为自定义初始化函数，这在初始化逻辑比较简单或者只需要在局部作用域内使用时非常方便。
1
#include <folly/Singleton.h>
2
#include <iostream>
3
4
class MyService {
5
public:
6
MyService(int port) : port_(port) {
7
std::cout << "MyService 构造函数被调用，端口: " << port_ << std::endl;
8
}
9
void start() {
10
std::cout << "MyService 在端口 " << port_ << " 启动" << std::endl;
11
}
12
private:
13
int port_;
14
};
15
16
// 使用 Lambda 表达式作为初始化函数
17
folly::Singleton<MyService, MyService*(*)(int)> serviceInstance(
18
[](int port) { return new MyService(port); }, 8080);
19
20
int main() {
21
MyService* service = serviceInstance.getInstance();
22
service->start();
23
return 0;
24
}
代码解释：
⚝ 我们使用一个 Lambda 表达式 [](int port) { return new MyService(port); } 作为自定义初始化函数。这个 Lambda 表达式接受一个 int 类型的端口号，并返回一个新的 MyService 实例。
⚝ 在 folly::Singleton 的构造函数中，我们传递了 Lambda 表达式和端口号 8080。
⑤ 自定义初始化函数的优势：
⚝ 灵活性：自定义初始化函数提供了极大的灵活性，可以处理各种复杂的初始化场景。
⚝ 可测试性：将初始化逻辑封装在单独的函数中，可以提高代码的可测试性。你可以更容易地对初始化函数进行单元测试。
⚝ 错误处理：自定义初始化函数可以提供更完善的错误处理机制，例如抛出异常或者返回错误码，使得初始化过程更加健壮。
总而言之，自定义初始化函数是 folly::Singleton.h 提供的一个非常强大的特性，它使得 folly::Singleton 能够适应各种复杂的初始化需求，而不仅仅局限于简单的默认构造。通过合理地使用自定义初始化函数，可以更好地管理 Singleton 实例的创建和初始化过程。
3.4 LeakySingleton：泄漏型 Singleton 的应用 (Application of LeakySingleton: Leaky Singleton)
在 folly::Singleton.h 中，除了 Singleton<T>，还提供了一个变体 LeakySingleton<T>。LeakySingleton 被称为泄漏型 Singleton（Leaky Singleton），因为它在程序结束时不会自动销毁 Singleton 实例，从而导致内存泄漏（在严格意义上，但通常是可接受的）。理解 LeakySingleton 的特性和应用场景，有助于在合适的场合选择正确的 Singleton 类型。
① LeakySingleton 的特性：
⚝ 不自动销毁：与 Singleton<T> 不同，LeakySingleton<T> 创建的 Singleton 实例在程序结束时不会被自动销毁。这意味着不会调用实例的析构函数，实例所占用的内存也不会被释放，直到操作系统回收进程资源。
⚝ 避免全局销毁顺序问题：由于 LeakySingleton 不会主动销毁实例，因此可以避免与全局对象销毁顺序相关的问题。在 C++ 中，全局对象的销毁顺序是不确定的，如果 Singleton 实例依赖于其他全局对象，并且这些全局对象在 Singleton 销毁之前已经被销毁，可能会导致程序崩溃或未定义行为。LeakySingleton 通过不销毁实例，可以规避这类问题。
⚝ 更快的程序退出：由于不需要执行 Singleton 实例的析构函数，程序退出时可能会更快一些，尤其是在 Singleton 实例的析构函数执行时间较长的情况下。
② 为什么使用 LeakySingleton：
⚝ 避免全局销毁顺序问题：这是 LeakySingleton 最主要的应用场景。当 Singleton 实例依赖于其他全局对象，并且全局对象的销毁顺序难以控制或可能导致问题时，使用 LeakySingleton 可以避免这类问题。例如，Singleton 实例可能使用了全局的日志系统，而日志系统本身也是一个全局对象。如果日志系统在 Singleton 销毁之前就被销毁，Singleton 的析构函数中如果尝试使用日志系统，就会出错。
⚝ 程序生命周期与 Singleton 生命周期一致：在某些情况下，Singleton 实例的生命周期与程序的生命周期完全一致。也就是说，Singleton 实例在程序启动时创建，并在程序结束时才“结束生命”。在这种情况下，是否显式销毁 Singleton 实例意义不大，因为程序结束时操作系统会回收所有进程资源，包括 Singleton 实例占用的内存。使用 LeakySingleton 可以简化管理，避免显式调用 reset()。
⚝ 性能优化（在特定场景下）：虽然通常情况下析构函数的开销很小，但在某些极端性能敏感的应用中，如果 Singleton 实例的析构函数执行时间较长，并且程序退出非常频繁，使用 LeakySingleton 可以避免析构函数的开销，从而略微提升性能。但这通常不是选择 LeakySingleton 的主要原因。
③ LeakySingleton 的使用示例：
1
#include <folly/Singleton.h>
2
#include <iostream>
3
4
class GlobalResource {
5
public:
6
GlobalResource() {
7
std::cout << "GlobalResource 构造函数被调用" << std::endl;
8
}
9
~GlobalResource() {
10
std::cout << "GlobalResource 析构函数被调用" << std::endl;
11
}
12
void useResource() {
13
std::cout << "使用全局资源" << std::endl;
14
}
15
};
16
17
// 使用 LeakySingleton
18
folly::LeakySingleton<GlobalResource> globalResourceInstance;
19
20
int main() {
21
GlobalResource* resource = globalResourceInstance.getInstance();
22
resource->useResource();
23
std::cout << "程序即将退出" << std::endl;
24
return 0;
25
}
代码解释：
⚝ 我们定义了一个 GlobalResource 类，它有构造函数和析构函数，用于观察对象的生命周期。
⚝ 我们使用 folly::LeakySingleton<GlobalResource> 定义了 globalResourceInstance。
⚝ 在 main 函数中，我们获取并使用 GlobalResource 实例。
⚝ 当程序退出时，你将看到 "GlobalResource 构造函数被调用" 的输出，但不会看到 "GlobalResource 析构函数被调用" 的输出，因为 LeakySingleton 不会主动销毁实例。
④ LeakySingleton 的适用场景：
⚝ 全局日志系统：日志系统通常需要在程序的整个生命周期内可用，并且可能被其他全局对象使用。使用 LeakySingleton 实现日志系统可以避免全局销毁顺序问题。
⚝ 全局配置管理器：配置管理器通常在程序启动时加载配置，并在整个程序运行期间提供配置信息。使用 LeakySingleton 可以简化配置管理器的生命周期管理。
⚝ 某些类型的全局缓存：对于一些全局缓存，如果其生命周期与程序生命周期一致，并且销毁过程不重要或者可能引发问题，可以使用 LeakySingleton。
⑤ LeakySingleton 的注意事项：
⚝ 内存泄漏：虽然 LeakySingleton 被称为“泄漏型”，但它导致的内存泄漏通常是良性的。在现代操作系统中，进程结束时，操作系统会回收进程的所有资源，包括内存。因此，LeakySingleton 导致的内存泄漏只会在程序运行期间存在，程序退出后内存会被回收。对于长时间运行的程序，如果 LeakySingleton 实例占用的内存很大，仍然需要考虑内存管理问题。但对于大多数应用，这种“泄漏”是可以接受的。
⚝ 资源释放：如果 LeakySingleton 实例持有重要的系统资源（例如，文件句柄、网络连接等），并且需要在程序结束前显式释放这些资源，LeakySingleton 可能不是最佳选择。在这种情况下，应该使用 Singleton<T> 并显式调用 reset()，或者考虑其他的资源管理策略。
⚝ 不适用于所有 Singleton 场景：LeakySingleton 并非 Singleton<T> 的替代品，而是一种特殊的 Singleton 类型，适用于特定的场景。在大多数情况下，如果不需要避免全局销毁顺序问题，并且需要正常的资源管理，应该优先使用 Singleton<T>。
总而言之，folly::LeakySingleton<T> 提供了一种特殊的 Singleton 实现，它通过不自动销毁实例来避免全局销毁顺序问题，并简化某些全局资源的生命周期管理。开发者应该根据具体的应用场景和需求，权衡 LeakySingleton 的优缺点，选择合适的 Singleton 类型。
3.5 SingletonVoid：无返回值 Singleton 的使用 (Usage of SingletonVoid: Void Return Singleton)
folly::Singleton.h 还提供了一个特殊的 Singleton 类型 SingletonVoid。与 Singleton<T> 和 LeakySingleton<T> 不同，SingletonVoid 用于创建不返回实例的 Singleton。这听起来可能有些反直觉，但 SingletonVoid 在某些特定的场景下非常有用。
① SingletonVoid 的特性：
⚝ 不返回实例：SingletonVoid 的 getInstance() 方法不返回任何值（返回 void）。这意味着你无法直接获取到 Singleton 实例的指针或引用。
⚝ 主要用于执行初始化代码：SingletonVoid 的主要目的是确保一段代码（通常是初始化代码）只被执行一次，并且是线程安全的。它并不用于获取 Singleton 实例本身，而是利用 Singleton 机制来控制代码的执行。
⚝ 延迟初始化：SingletonVoid 也采用延迟初始化策略。只有当第一次调用 getInstance() 方法时，才会执行与 SingletonVoid 关联的代码。
⚝ 线程安全：SingletonVoid 的 getInstance() 方法也是线程安全的，确保在多线程环境下，关联的代码只会被执行一次。
② 为什么使用 SingletonVoid：
⚝ 全局初始化：有时需要在程序启动时执行一些全局初始化操作，例如注册全局服务、初始化全局配置、设置全局日志级别等。这些初始化操作可能不需要返回任何实例，只需要确保它们在程序启动时被执行一次即可。SingletonVoid 可以用来管理这些全局初始化操作。
⚝ 静态初始化替代方案：在 C++ 中，静态初始化顺序问题是一个常见的难题。使用 SingletonVoid 可以作为静态初始化的替代方案，将初始化代码放在 SingletonVoid 的 getInstance() 方法中，利用 folly::Singleton 的线程安全性和延迟初始化特性，来更安全、更可控地执行全局初始化代码。
⚝ 模块初始化管理：在大型系统中，可能需要对不同的模块进行初始化管理，确保每个模块的初始化代码只执行一次。SingletonVoid 可以用来管理每个模块的初始化过程。
③ SingletonVoid 的使用示例：
1
#include <folly/Singleton.h>
2
#include <iostream>
3
4
void initializeLogging() {
5
std::cout << "全局日志系统初始化完成" << std::endl;
6
// ... 实际的日志系统初始化代码 ...
7
}
8
9
void initializeConfig() {
10
std::cout << "全局配置加载完成" << std::endl;
11
// ... 实际的配置加载代码 ...
12
}
13
14
// 使用 SingletonVoid 管理全局初始化
15
folly::SingletonVoid loggingInitializer(initializeLogging);
16
folly::SingletonVoid configInitializer(initializeConfig);
17
18
int main() {
19
// 触发日志系统初始化
20
loggingInitializer.getInstance();
21
22
// 触发配置加载
23
configInitializer.getInstance();
24
25
std::cout << "程序主逻辑开始执行" << std::endl;
26
return 0;
27
}
代码解释：
⚝ 我们定义了两个全局初始化函数 initializeLogging 和 initializeConfig，分别用于初始化日志系统和加载配置。
⚝ 我们使用 folly::SingletonVoid 定义了 loggingInitializer 和 configInitializer，并将初始化函数作为参数传递给 SingletonVoid 的构造函数。
⚝ 在 main 函数中，我们分别调用 loggingInitializer.getInstance() 和 configInitializer.getInstance() 来触发初始化操作。注意，getInstance() 方法返回 void，我们不需要接收返回值。
④ SingletonVoid 的适用场景：
⚝ 全局服务注册：例如，注册各种全局服务到服务定位器（Service Locator）或依赖注入容器中。
⚝ 全局配置加载：在程序启动时加载全局配置信息。
⚝ 模块初始化：在大型系统中，对各个模块进行初始化，例如数据库模块、网络模块、UI 模块等。
⚝ 静态数据初始化：初始化一些全局的静态数据结构，例如查找表、缓存等。
⑤ SingletonVoid 的注意事项：
⚝ 不用于获取实例：SingletonVoid 的目的不是为了获取 Singleton 实例，而是为了执行初始化代码。如果你需要获取 Singleton 实例，应该使用 Singleton<T> 或 LeakySingleton<T>。
⚝ 初始化代码应尽量简单：虽然 SingletonVoid 可以管理复杂的初始化代码，但为了保持代码的清晰和可维护性，建议将初始化代码尽量模块化，并封装在单独的函数中，然后传递给 SingletonVoid。
⚝ 错误处理：如果初始化代码可能会抛出异常，需要确保异常被正确捕获和处理，避免程序崩溃。
总而言之，folly::SingletonVoid 提供了一种独特的 Singleton 用法，它不返回实例，而是用于管理和执行全局初始化代码。通过 SingletonVoid，开发者可以更安全、更可控地执行全局初始化操作，避免静态初始化顺序问题，并提高代码的可维护性和可测试性。在需要进行全局初始化，但不需要获取 Singleton 实例的场景下，SingletonVoid 是一个非常有用的工具。
END_OF_CHAPTER
4. chapter 4： folly::Singleton.h 高级应用与技巧 (Advanced Applications and Techniques of folly::Singleton.h)
4.1 Singleton 的模板参数详解 (Detailed Explanation of Template Parameters of Singleton)
folly::Singleton<T> 是一个模板类，其核心在于模板参数 T。理解 T 的作用以及如何选择合适的 T 类型，是深入掌握 folly::Singleton.h 的关键。本节将详细解析 Singleton 的模板参数，帮助读者更好地运用这一强大的工具。
首先，T 代表了你希望单例化的类型。这意味着 folly::Singleton<T> 将负责创建、管理和提供类型为 T 的单例实例。T 可以是任何 C++ 类型，包括：
⚝ 基本数据类型 (Primitive Data Types)：例如 int, double, bool 等。虽然单例模式通常不用于基本数据类型，但在某些特定场景下，例如全局计数器或标志位，也可能用到。
⚝ 自定义类 (Custom Classes)：这是 Singleton 最常见的应用场景。你可以将任何自定义类 MyClass 作为 T，从而创建一个 MyClass 类型的单例。
⚝ 复杂类型 (Complex Types)：例如容器 std::vector, std::map，智能指针 std::unique_ptr, std::shared_ptr 等。这使得 Singleton 可以管理更复杂对象的单例实例。
⚝ 抽象类和接口 (Abstract Classes and Interfaces)：虽然不能直接实例化抽象类，但可以通过指向具体实现类的指针或智能指针来单例化抽象接口，实现多态单例。
选择 T 类型的考量因素：
① 单例的职责 (Responsibility of Singleton)：T 的类型应该与单例模式在该应用中的职责相符。例如，如果单例用于管理配置信息，T 可能是一个配置类；如果单例用于提供日志服务，T 可能是一个日志管理器类。
② 生命周期管理 (Lifecycle Management)：folly::Singleton<T> 负责管理 T 类型实例的生命周期。你需要考虑 T 类型的对象是否需要复杂的构造和析构过程。对于需要自定义初始化或清理操作的类型，可以通过 folly::Singleton 的初始化函数机制来处理（将在后续章节详细介绍）。
③ 线程安全性 (Thread Safety)：folly::Singleton<T> 默认提供线程安全的单例创建和访问。但是，T 类型本身的操作是否线程安全也需要考虑。如果 T 类型的成员函数或操作不是线程安全的，即使 Singleton 实例是线程安全的，多线程并发访问仍然可能导致问题。
④ 资源占用 (Resource Consumption)：T 类型的对象所占用的资源（内存、文件句柄、网络连接等）需要评估。单例实例通常在应用程序的整个生命周期内存在，因此需要确保 T 类型的资源占用是可接受的，并且资源管理是合理的。
代码示例：不同类型的 T
1
#include <folly/Singleton.h>
2
#include <iostream>
3
#include <string>
4
5
// 1. 单例化基本数据类型 (不太常见，仅为示例)
6
using CounterSingleton = folly::Singleton<int>;
7
8
// 2. 单例化自定义类
9
class MyConfig {
10
public:
11
MyConfig() : configValue_("default_value") {
12
std::cout << "MyConfig instance created." << std::endl;
13
}
14
std::string getConfigValue() const { return configValue_; }
15
void setConfigValue(const std::string& value) { configValue_ = value; }
16
private:
17
std::string configValue_;
18
};
19
using ConfigSingleton = folly::Singleton<MyConfig>;
20
21
// 3. 单例化复杂类型 (例如 std::string)
22
using GlobalStringSingleton = folly::Singleton<std::string>;
23
24
int main() {
25
// 使用 CounterSingleton
26
CounterSingleton::getInstance() = 100;
27
std::cout << "CounterSingleton value: " << CounterSingleton::getInstance() << std::endl;
28
29
// 使用 ConfigSingleton
30
ConfigSingleton::getInstance().setConfigValue("new_config_value");
31
std::cout << "ConfigSingleton value: " << ConfigSingleton::getInstance().getConfigValue() << std::endl;
32
33
// 使用 GlobalStringSingleton
34
GlobalStringSingleton::getInstance() = "Hello, Singleton!";
35
std::cout << "GlobalStringSingleton value: " << GlobalStringSingleton::getInstance() << std::endl;
36
37
return 0;
38
}
总结：
选择 folly::Singleton<T> 的模板参数 T 时，需要综合考虑单例的职责、生命周期管理、线程安全性以及资源占用等因素。合理的选择 T 类型，能够充分发挥 folly::Singleton.h 的优势，构建健壮、高效的单例模式应用。
4.2 在多线程环境中使用 Singleton (Using Singleton in Multi-threaded Environments)
多线程环境是现代软件开发中常见的场景。在多线程程序中使用单例模式时，线程安全性至关重要。folly::Singleton.h 的设计充分考虑了线程安全，为多线程环境下的单例使用提供了默认保障。本节将深入探讨如何在多线程环境中使用 folly::Singleton.h，以及其线程安全机制的原理。
folly::Singleton.h 的线程安全保障：
folly::Singleton.h 默认是线程安全的，这意味着在多线程并发访问 getInstance() 方法时，能够保证只创建一个单例实例，并且多个线程可以安全地访问该实例。其线程安全主要通过以下机制实现：
① 静态局部变量 (Static Local Variable) 的线程安全初始化：folly::Singleton 内部通常会使用静态局部变量来存储单例实例。C++11 标准保证了静态局部变量的初始化是线程安全的。这意味着，即使多个线程同时首次调用 getInstance() 方法，只有一个线程会成功初始化静态局部变量，其他线程会被阻塞，直到初始化完成。
② 双重检查锁定 (Double-Checked Locking) 的优化：虽然 folly::Singleton.h 的具体实现可能有所不同，但其线程安全机制通常会采用类似双重检查锁定的优化策略，以减少锁的竞争。在大多数情况下，获取单例实例时不需要加锁，只有在首次创建实例时才需要进行同步。
多线程环境下的 Singleton 使用示例：
1
#include <folly/Singleton.h>
2
#include <iostream>
3
#include <thread>
4
#include <vector>
5
6
class ThreadSafeCounter {
7
public:
8
ThreadSafeCounter() : count_(0) {
9
std::cout << "ThreadSafeCounter instance created." << std::endl;
10
}
11
void increment() {
12
// 假设 increment 操作本身是线程安全的 (例如使用原子操作或互斥锁)
13
++count_;
14
}
15
int getCount() const { return count_; }
16
private:
17
int count_;
18
};
19
using CounterSingleton = folly::Singleton<ThreadSafeCounter>;
20
21
void increment_counter() {
22
for (int i = 0; i < 10000; ++i) {
23
CounterSingleton::getInstance().increment();
24
}
25
}
26
27
int main() {
28
std::vector<std::thread> threads;
29
for (int i = 0; i < 4; ++i) {
30
threads.emplace_back(increment_counter);
31
}
32
33
for (auto& thread : threads) {
34
thread.join();
35
}
36
37
std::cout << "Final counter value: " << CounterSingleton::getInstance().getCount() << std::endl;
38
return 0;
39
}
在这个例子中，多个线程并发地调用 CounterSingleton::getInstance().increment() 来增加计数器。由于 folly::Singleton.h 的线程安全保障，以及 ThreadSafeCounter 类内部 increment() 方法的线程安全性（这里假设 increment() 内部使用了适当的同步机制，例如原子操作或互斥锁，以保证计数器操作的线程安全），最终的计数结果是正确的。
注意事项：
① 确保 T 类型操作的线程安全：folly::Singleton.h 保证了单例实例的创建和获取是线程安全的，但这并不意味着 T 类型的所有操作都是线程安全的。如果 T 类型的成员函数或操作本身不是线程安全的，你仍然需要自行保证线程安全，例如使用互斥锁、原子操作等同步机制。
② 避免死锁 (Deadlock)：在多线程环境中使用单例时，需要注意避免死锁。如果单例的初始化或操作依赖于其他资源，并且这些资源的获取也可能被其他线程持有，就可能发生死锁。设计单例时，应尽量减少对外部资源的依赖，或者采用合理的资源获取顺序和超时机制来避免死锁。
③ 性能考量 (Performance Considerations)：虽然 folly::Singleton.h 提供了高效的线程安全机制，但在高并发场景下，锁竞争仍然可能成为性能瓶颈。如果单例的访问非常频繁，并且性能要求极高，可以考虑以下优化策略：
▮▮▮▮⚝ 减少锁的粒度 (Reduce Lock Granularity)：如果可能，将锁的范围缩小到只保护必要的临界区，而不是整个单例实例。
▮▮▮▮⚝ 使用无锁数据结构 (Lock-Free Data Structures)：如果 T 类型的数据结构允许，可以考虑使用无锁数据结构来提高并发性能。
▮▮▮▮⚝ 考虑其他并发模式 (Consider Other Concurrency Patterns)：在某些极端情况下，单例模式可能不是最佳选择。可以考虑其他并发模式，例如线程局部存储 (Thread-Local Storage) 或 actor 模型，来解决特定的并发问题。
总结：
folly::Singleton.h 为多线程环境下的单例使用提供了强大的线程安全保障。开发者可以放心地在多线程程序中使用 folly::Singleton.h 创建和访问单例实例。但同时，也需要注意确保 T 类型操作的线程安全，并避免潜在的死锁和性能问题。合理地运用 folly::Singleton.h，可以构建高效、可靠的多线程应用程序。
4.3 Singleton 与依赖注入 (Dependency Injection) 的结合 (Integration of Singleton and Dependency Injection)
依赖注入 (Dependency Injection, DI) 是一种重要的软件设计模式，旨在降低组件之间的耦合度，提高代码的可维护性和可测试性。单例模式和依赖注入在某些方面存在一定的关联，但也存在一些冲突。本节将探讨 folly::Singleton.h 如何与依赖注入结合使用，以及在 DI 环境下使用单例模式的最佳实践。
依赖注入的核心思想：
依赖注入的核心思想是将组件的依赖关系从组件内部移除，转而由外部容器或框架来管理和注入。这意味着，组件不再主动创建或查找其依赖的对象，而是通过构造函数参数、setter 方法或接口注入的方式，由外部提供所需的依赖。
Singleton 与依赖注入的关联与冲突：
⚝ 关联 (Association)：单例模式和依赖注入都旨在管理对象的生命周期和作用域。单例模式确保一个类只有一个实例，而依赖注入容器也通常管理对象的生命周期，包括单例、瞬态、作用域等。在某些简单的 DI 场景中，单例模式可以作为一种简单的依赖管理方式。
⚝ 冲突 (Conflict)：传统的单例模式（例如静态成员变量方式）与依赖注入的核心原则存在冲突。单例模式通常将对象的创建和访问逻辑硬编码在类内部，这使得组件难以测试和替换依赖。而依赖注入提倡将依赖关系外部化，以便于组件的测试、配置和扩展。
folly::Singleton.h 在依赖注入中的应用：
folly::Singleton.h 相对于传统的单例模式，在依赖注入方面具有更好的适应性。主要体现在以下几点：
① 延迟初始化 (Lazy Initialization)：folly::Singleton.h 默认支持延迟初始化，这意味着单例实例只有在首次被访问时才会被创建。这与依赖注入容器的按需创建对象的理念相符。
② 可定制的初始化函数 (Customizable Initialization Function)：folly::Singleton.h 允许用户自定义初始化函数，这使得在创建单例实例时可以执行更复杂的操作，例如从配置文件加载数据、初始化依赖对象等。这为单例与依赖注入容器的集成提供了灵活性。
③ reset() 方法：folly::Singleton.h 提供了 reset() 方法，可以销毁单例实例并重置状态。这在单元测试和某些需要动态重置单例的场景中非常有用，也使得单例在依赖注入环境中更易于管理。
与依赖注入框架集成：
folly::Singleton.h 可以与各种依赖注入框架（例如 Google Guice, Spring Framework, PicoContainer 等）集成使用。集成方式主要有两种：
① 手动注册单例 (Manual Singleton Registration)：在依赖注入容器中，将 folly::Singleton<T>::getInstance() 返回的实例注册为单例组件。这样，当其他组件需要依赖 T 类型时，容器会返回 folly::Singleton 管理的单例实例。
② 自定义 Provider (Custom Provider)：为 folly::Singleton<T> 创建一个自定义 Provider 类，该 Provider 负责获取 folly::Singleton<T>::getInstance() 返回的实例。然后将该 Provider 注册到依赖注入容器中。这种方式更加灵活，可以对单例的创建和管理进行更精细的控制。
代码示例：与简单的依赖注入容器集成
假设我们有一个简单的依赖注入容器 Container (仅为演示概念，并非完整的 DI 框架)：
1
#include <folly/Singleton.h>
2
#include <iostream>
3
#include <map>
4
#include <memory>
5
6
// 简单的依赖注入容器 (仅为演示概念)
7
class Container {
8
public:
9
template <typename Interface, typename Implementation>
10
void registerType() {
11
// 假设 Implementation 可以通过默认构造函数创建
12
factories_[typeid(Interface)] = []() {
13
return std::make_shared<Implementation>();
14
};
15
}
16
17
template <typename Interface, typename Implementation, typename SingletonType>
18
void registerSingleton() {
19
factories_[typeid(Interface)] = []() {
20
return std::shared_ptr<Interface>(&SingletonType::getInstance(), [](void*){ /* do nothing, prevent delete */ });
21
};
22
}
23
24
25
template <typename Interface>
26
std::shared_ptr<Interface> resolve() {
27
auto it = factories_.find(typeid(Interface));
28
if (it != factories_.end()) {
29
return std::static_pointer_cast<Interface>(it->second());
30
}
31
return nullptr; // 或者抛出异常
32
}
33
34
private:
35
std::map<std::type_index, std::function<std::shared_ptr<void>()>> factories_;
36
};
37
38
// 示例接口和实现
39
class Logger {
40
public:
41
virtual void log(const std::string& message) = 0;
42
virtual ~Logger() = default;
43
};
44
45
class ConsoleLogger : public Logger {
46
public:
47
void log(const std::string& message) override {
48
std::cout << "[ConsoleLogger] " << message << std::endl;
49
}
50
};
51
using LoggerSingleton = folly::Singleton<ConsoleLogger>;
52
53
54
class UserService {
55
public:
56
UserService(std::shared_ptr<Logger> logger) : logger_(logger) {}
57
void createUser(const std::string& username) {
58
logger_->log("Creating user: " + username);
59
// ... 创建用户的逻辑 ...
60
}
61
private:
62
std::shared_ptr<Logger> logger_;
63
};
64
65
int main() {
66
Container container;
67
// 注册 Logger 为单例，使用 LoggerSingleton 管理
68
container.registerSingleton<Logger, ConsoleLogger, LoggerSingleton>();
69
// 注册 UserService，依赖 Logger 接口
70
container.registerType<UserService, UserService>();
71
72
// 解析 UserService，容器会自动注入 Logger 单例
73
auto userService = container.resolve<UserService>();
74
if (userService) {
75
userService->createUser("example_user");
76
}
77
78
return 0;
79
}
在这个示例中，我们将 ConsoleLogger 使用 LoggerSingleton 管理，并在 Container 中注册为 Logger 接口的单例实现。当解析 UserService 时，容器会自动注入 Logger 接口的单例实例。
最佳实践：
① 谨慎使用单例：在依赖注入环境中，应谨慎使用单例模式。过度使用单例可能导致全局状态蔓延，降低代码的可测试性和灵活性。优先考虑使用瞬态或作用域对象，只有在真正需要全局唯一实例的场景下才使用单例。
② 接口化单例：如果需要在依赖注入环境中使用单例，建议将单例类实现为接口，并使用 folly::Singleton<ConcreteImplementation> 管理具体的实现类。这样可以提高组件的可替换性和可测试性。
③ 避免单例的全局状态：尽量避免在单例类中存储可变的全局状态。如果必须存储状态，应考虑使用线程安全的数据结构，并谨慎管理状态的生命周期。
④ 利用 DI 容器管理单例生命周期：如果使用依赖注入框架，应尽量将单例的生命周期管理交给 DI 容器。容器可以提供更完善的单例管理机制，例如延迟初始化、销毁回调等。
总结：
folly::Singleton.h 可以与依赖注入模式良好地结合使用。通过合理的集成方式和最佳实践，可以在享受单例模式便利性的同时，保持代码的可维护性和可测试性。在依赖注入环境中使用单例时，需要权衡单例的优点和缺点，并根据具体场景做出合适的选择。
4.4 使用 Singleton 管理全局资源 (Using Singleton to Manage Global Resources)
全局资源是指在应用程序的多个模块或组件中都需要访问和共享的资源，例如数据库连接、配置信息、日志服务、缓存系统等。单例模式非常适合用于管理全局资源，因为它可以确保全局资源只有一个实例，并提供统一的访问入口。folly::Singleton.h 为全局资源的管理提供了便捷且线程安全的解决方案。本节将探讨如何使用 folly::Singleton.h 管理各种类型的全局资源，并分析其优势和注意事项。
常见的全局资源类型：
① 配置信息 (Configuration Information)：应用程序的配置参数，例如数据库连接字符串、API 密钥、日志级别等。通常需要在应用程序启动时加载配置信息，并在运行时供多个模块访问。
② 日志服务 (Logging Service)：负责记录应用程序运行日志的组件。通常需要全局唯一的日志实例，以便于统一管理和输出日志信息。
③ 数据库连接池 (Database Connection Pool)：用于管理数据库连接的连接池。通常需要全局唯一的连接池实例，以提高数据库访问性能和资源利用率。
④ 缓存系统 (Cache System)：用于缓存热点数据的缓存组件。通常需要全局唯一的缓存实例，以便于在多个模块之间共享缓存数据。
⑤ 线程池 (Thread Pool)：用于管理线程的线程池。通常需要全局唯一的线程池实例，以便于在应用程序中统一管理和调度线程。
使用 folly::Singleton.h 管理全局资源的优势：
① 全局唯一实例 (Globally Unique Instance)：folly::Singleton.h 确保全局资源只有一个实例，避免了资源重复创建和浪费，保证了数据的一致性。
② 线程安全访问 (Thread-Safe Access)：folly::Singleton.h 提供了线程安全的单例创建和访问机制，使得在多线程环境下可以安全地共享全局资源。
③ 延迟初始化 (Lazy Initialization)：folly::Singleton.h 支持延迟初始化，全局资源只有在首次被访问时才会被创建，提高了应用程序的启动速度和资源利用率。
④ 统一访问入口 (Unified Access Point)：通过 folly::Singleton<ResourceType>::getInstance() 可以方便地获取全局资源实例，提供了统一的访问入口，简化了代码。
代码示例：使用 Singleton 管理配置信息
1
#include <folly/Singleton.h>
2
#include <iostream>
3
#include <string>
4
#include <fstream>
5
#include <sstream>
6
#include <stdexcept>
7
8
class ConfigManager {
9
public:
10
ConfigManager() {
11
loadConfigFromFile("config.ini");
12
std::cout << "ConfigManager instance created." << std::endl;
13
}
14
15
std::string getConfigValue(const std::string& key) const {
16
auto it = configMap_.find(key);
17
if (it != configMap_.end()) {
18
return it->second;
19
}
20
return ""; // 或者抛出异常
21
}
22
23
private:
24
void loadConfigFromFile(const std::string& filename) {
25
std::ifstream configFile(filename);
26
if (!configFile.is_open()) {
27
throw std::runtime_error("Failed to open config file: " + filename);
28
}
29
30
std::string line;
31
while (std::getline(configFile, line)) {
32
std::stringstream ss(line);
33
std::string key, value;
34
if (std::getline(ss, key, '=') && std::getline(ss, value)) {
35
configMap_[key] = value;
36
}
37
}
38
configFile.close();
39
}
40
41
private:
42
std::map<std::string, std::string> configMap_;
43
};
44
using GlobalConfig = folly::Singleton<ConfigManager>;
45
46
int main() {
47
// 获取配置信息
48
std::string dbHost = GlobalConfig::getInstance().getConfigValue("db_host");
49
std::string dbPort = GlobalConfig::getInstance().getConfigValue("db_port");
50
std::string logLevel = GlobalConfig::getInstance().getConfigValue("log_level");
51
52
std::cout << "Database Host: " << dbHost << std::endl;
53
std::cout << "Database Port: " << dbPort << std::endl;
54
std::cout << "Log Level: " << logLevel << std::endl;
55
56
return 0;
57
}
在这个例子中，ConfigManager 类负责加载和管理配置信息。GlobalConfig 使用 folly::Singleton<ConfigManager> 将 ConfigManager 类单例化，从而在应用程序中提供全局唯一的配置管理实例。其他模块可以通过 GlobalConfig::getInstance() 方便地访问配置信息。
注意事项：
① 全局状态的副作用 (Side Effects of Global State)：过度依赖全局资源可能导致全局状态蔓延，降低代码的模块化和可测试性。应谨慎使用全局资源，并尽量减少全局状态的副作用。
② 资源初始化顺序 (Resource Initialization Order)：如果多个全局资源之间存在依赖关系，需要仔细考虑资源的初始化顺序，避免循环依赖和初始化失败。可以使用 folly::Singleton 的自定义初始化函数来控制资源的初始化顺序。
③ 资源销毁与清理 (Resource Destruction and Cleanup)：全局资源的生命周期通常与应用程序的生命周期相同。需要确保在应用程序退出时，全局资源能够被正确地销毁和清理，释放占用的资源。folly::Singleton 的 reset() 方法可以用于手动销毁单例实例，但需要谨慎使用，避免在程序运行过程中意外销毁全局资源。对于 LeakySingleton，则无需手动销毁，由操作系统在进程退出时回收资源。
④ 单元测试的挑战 (Unit Testing Challenges)：全局资源可能会给单元测试带来挑战，因为全局状态可能会影响测试的隔离性和可重复性。在单元测试中，可以考虑使用 Mock 对象或依赖注入等技术来隔离和替换全局资源，提高测试的质量。
最佳实践：
① 接口化全局资源：将全局资源抽象为接口，并使用 folly::Singleton<ConcreteImplementation> 管理具体的实现类。这样可以提高全局资源的可替换性和可测试性。
② 最小化全局状态：尽量减少全局资源中存储的可变状态。如果必须存储状态，应考虑使用线程安全的数据结构，并谨慎管理状态的生命周期。
③ 使用依赖注入管理全局资源依赖：如果应用程序使用了依赖注入框架，可以将全局资源注册为单例组件，并使用依赖注入来管理全局资源与其他组件之间的依赖关系。
④ 考虑使用服务定位器 (Service Locator) 模式：在某些场景下，服务定位器模式可能是比单例模式更合适的全局资源管理方案。服务定位器模式提供了一种集中式的服务注册和查找机制，可以更好地管理全局资源的生命周期和依赖关系。
总结：
folly::Singleton.h 是管理全局资源的强大工具。通过合理地使用 folly::Singleton.h，可以方便地创建和管理各种类型的全局资源，提高应用程序的效率和可维护性。但在使用全局资源时，也需要注意全局状态的副作用、资源初始化顺序、资源销毁与清理以及单元测试的挑战，并遵循最佳实践，以确保应用程序的健壮性和可测试性。
4.5 Singleton 在单元测试中的应用与 Mocking (Application and Mocking of Singleton in Unit Testing)
单元测试是保证软件质量的重要手段。然而，单例模式由于其全局性和紧耦合性，常常给单元测试带来挑战。直接依赖单例的组件难以进行隔离测试，因为单例实例的状态是全局共享的，测试用例之间可能会相互影响。此外，单例实例的创建和销毁逻辑通常是硬编码的，难以在测试环境中进行定制和替换。本节将探讨 folly::Singleton.h 在单元测试中的应用，以及如何对单例进行 Mocking (模拟)，以提高单元测试的质量和效率。
Singleton 给单元测试带来的挑战：
① 全局状态 (Global State)：单例实例的状态是全局共享的，测试用例可能会修改单例的状态，从而影响后续测试用例的结果。这使得测试用例之间存在依赖关系，降低了测试的隔离性和可重复性。
② 紧耦合 (Tight Coupling)：组件直接依赖于单例实例，这使得组件难以进行隔离测试。如果要测试一个依赖单例的组件，必须先创建和初始化单例实例，这增加了测试的复杂性。
③ 难以 Mocking (Difficult to Mock)：传统的单例模式（例如静态成员变量方式）难以进行 Mocking。由于单例实例的创建和访问逻辑是硬编码的，无法在测试环境中替换为 Mock 对象，这使得难以对依赖单例的组件进行 Mock 测试。
④ 生命周期管理 (Lifecycle Management)：单例实例的生命周期通常与应用程序的生命周期相同。在单元测试中，可能需要在每个测试用例执行前后重置单例实例的状态，以保证测试的隔离性。但传统的单例模式通常缺乏灵活的生命周期管理机制。
folly::Singleton.h 在单元测试中的优势：
folly::Singleton.h 相对于传统的单例模式，在单元测试方面具有一定的优势：
① reset() 方法：folly::Singleton.h 提供了 reset() 方法，可以手动销毁单例实例并重置状态。这使得在单元测试中可以在每个测试用例执行前后调用 reset() 方法，重置单例状态，保证测试的隔离性。
② 可定制的初始化函数 (Customizable Initialization Function)：folly::Singleton.h 允许用户自定义初始化函数。在单元测试中，可以使用自定义初始化函数来创建 Mock 对象或配置测试环境所需的单例状态。
③ isInstanceCreated() 方法：folly::Singleton.h 提供了 isInstanceCreated() 方法，可以检查单例实例是否已经创建。这在单元测试中可以用于断言单例实例的创建状态。
Mocking Singleton 的方法：
为了解决单例在单元测试中带来的挑战，可以采用以下 Mocking 方法：
① 使用 reset() 方法重置单例状态：在每个测试用例执行前后，调用 folly::Singleton<T>::reset() 方法重置单例实例的状态。这可以保证测试用例之间的隔离性。
1
#include <folly/Singleton.h>
2
#include <gtest/gtest.h>
3
4
class MySingleton {
5
public:
6
MySingleton() : value_(0) {}
7
int getValue() const { return value_; }
8
void setValue(int value) { value_ = value; }
9
private:
10
int value_;
11
};
12
using TestSingleton = folly::Singleton<MySingleton>;
13
14
TEST(SingletonTest, Test1) {
15
TestSingleton::reset(); // 重置单例状态
16
TestSingleton::getInstance().setValue(10);
17
ASSERT_EQ(TestSingleton::getInstance().getValue(), 10);
18
}
19
20
TEST(SingletonTest, Test2) {
21
TestSingleton::reset(); // 重置单例状态
22
TestSingleton::getInstance().setValue(20);
23
ASSERT_EQ(TestSingleton::getInstance().getValue(), 20);
24
}
② 使用自定义初始化函数注入 Mock 对象：在单元测试中，可以使用自定义初始化函数来创建 Mock 对象，并将其注入到 folly::Singleton 中。这样可以替换真实的单例实现，方便进行 Mock 测试。
1
#include <folly/Singleton.h>
2
#include <gmock/gmock.h>
3
#include <gtest/gtest.h>
4
5
// 接口
6
class Logger {
7
public:
8
virtual ~Logger() = default;
9
virtual void log(const std::string& message) = 0;
10
};
11
12
// 真实 Logger 实现
13
class RealLogger : public Logger {
14
public:
15
void log(const std::string& message) override {
16
std::cout << "[RealLogger] " << message << std::endl;
17
}
18
};
19
using LoggerSingleton = folly::Singleton<Logger, RealLogger>; // 默认使用 RealLogger
20
21
// Mock Logger
22
class MockLogger : public Logger {
23
public:
24
MOCK_METHOD(void, log, (const std::string& message), override);
25
};
26
27
// 依赖 Logger 的组件
28
class MyComponent {
29
public:
30
MyComponent(Logger* logger) : logger_(logger) {}
31
void doSomething() {
32
logger_->log("Doing something...");
33
}
34
private:
35
Logger* logger_;
36
};
37
38
TEST(SingletonTest, MockLoggerTest) {
39
MockLogger mockLogger;
40
EXPECT_CALL(mockLogger, log(testing::_)).Times(1); // 期望 log 方法被调用一次
41
42
// 使用自定义初始化函数注入 MockLogger
43
folly::Singleton<Logger, RealLogger>::reset([]() { return &mockLogger; });
44
45
MyComponent component(&LoggerSingleton::getInstance());
46
component.doSomething();
47
48
folly::Singleton<Logger, RealLogger>::reset(); // 测试结束后重置为默认初始化
49
}
③ 使用依赖注入容器进行 Mocking：如果应用程序使用了依赖注入容器，可以将单例组件注册到容器中，并在单元测试中使用 Mock 对象替换容器中的单例注册。这样可以更方便地进行 Mock 测试和依赖管理。
④ 避免过度使用 Singleton：最根本的解决方案是避免过度使用单例模式。在设计组件时，尽量减少对全局单例的依赖，优先考虑使用依赖注入等模式来管理组件之间的依赖关系。这样可以提高代码的可测试性和可维护性。
最佳实践：
① 为 Singleton 类提供接口：为 Singleton 类定义接口，并让组件依赖于接口而不是具体的 Singleton 实现。这样可以方便在单元测试中使用 Mock 对象替换真实的 Singleton 实现。
② 使用 reset() 方法重置状态：在单元测试中，充分利用 folly::Singleton<T>::reset() 方法重置单例状态，保证测试的隔离性。
③ 考虑使用 LeakySingleton 进行测试：对于某些全局资源，例如日志服务，在单元测试中可以使用 LeakySingleton 来管理，避免在测试结束后手动销毁单例实例。
④ 结合 Mocking 框架使用：结合 Google Mock 等 Mocking 框架，可以更方便地创建和管理 Mock 对象，进行复杂的 Mock 测试。
⑤ 优先考虑可测试性设计：在设计应用程序时，优先考虑可测试性。尽量减少全局状态和紧耦合，采用依赖注入等模式来提高代码的可测试性。
总结：
单例模式给单元测试带来了一定的挑战，但通过合理地运用 folly::Singleton.h 提供的特性，以及采用合适的 Mocking 方法，可以有效地解决这些问题。在单元测试中，可以使用 reset() 方法重置单例状态，使用自定义初始化函数注入 Mock 对象，或者结合依赖注入容器进行 Mocking。最重要的是，在设计应用程序时，应优先考虑可测试性，避免过度使用单例模式，采用更灵活的设计模式来提高代码的质量和可维护性。
END_OF_CHAPTER
5. chapter 5： folly::Singleton.h API 全面解析 (Comprehensive API Analysis of folly::Singleton.h)
5.1 folly::Singleton<T> 类的详细 API 文档 (Detailed API Documentation of folly::Singleton<T> Class)
folly::Singleton<T> 是 folly 库提供的用于实现单例模式的核心类。它旨在提供一种安全、高效且易于使用的方式来管理单例对象的生命周期，尤其是在多线程环境中。本节将深入探讨 folly::Singleton<T> 类的结构、模板参数、以及其提供的核心功能。
folly::Singleton<T> 本身是一个模板类，这意味着它可以用于创建任何类型的单例对象，只要该类型 T 满足一定的条件（通常是可构造和可析构）。其核心设计目标是简化单例模式的实现，并避免传统单例模式实现中常见的线程安全问题和生命周期管理难题。
folly::Singleton<T> 的声明 (Declaration)
1
template <typename T>
2
class Singleton {
3
public:
4
// ... 公有成员函数 ...
5
6
private:
7
// ... 私有成员变量和函数 ...
8
};
模板参数 (Template Parameter)
⚝ T: 这是 folly::Singleton 接受的唯一模板参数，代表你希望单例化的类型。T 可以是任何类、结构体，甚至是内置类型，只要它能够被默认构造（或者你提供了自定义的初始化函数）。通常情况下，T 是你自定义的类，代表需要在整个应用程序中只有一个实例的组件，例如配置管理器、日志服务、线程池管理器等。
核心功能与设计要点 (Core Features and Design Highlights)
⚝ 线程安全初始化 (Thread-safe Initialization)：folly::Singleton 保证了在多线程环境下，单例实例只会被初始化一次，避免了竞态条件和数据损坏。这是通过内部的线程同步机制实现的，通常是基于原子操作或互斥锁，具体实现细节在源码剖析章节会深入分析。
⚝ 延迟初始化 (Lazy Initialization)：默认情况下，folly::Singleton 采用延迟初始化策略。这意味着单例实例只有在第一次通过 getInstance() 方法被请求时才会被创建。这种方式可以避免程序启动时就创建所有单例，从而提高启动速度，并节省资源，特别是对于那些可能在程序运行期间不一定会被用到的单例。
⚝ 可定制的初始化 (Customizable Initialization)：folly::Singleton 允许用户提供自定义的初始化函数。这对于需要在单例对象创建时执行特定初始化逻辑的场景非常有用。你可以通过 getInstance() 方法的重载形式来传递初始化参数，或者使用 folly::Singleton 提供的特定机制来设置初始化函数。
⚝ 生命周期管理 (Lifecycle Management)：folly::Singleton 负责管理单例对象的生命周期。在程序结束时，它会确保单例对象被正确地销毁，释放资源。然而，需要注意的是，folly::Singleton 默认采用“泄漏型单例 (Leaky Singleton)” 的策略，即在程序退出时，单例对象可能不会被显式 delete 调用析构函数。这种设计是为了避免在全局对象析构顺序不确定时可能出现的问题。如果需要确保析构函数的调用，可以使用 reset() 方法或者考虑非泄漏型单例的实现方式。
⚝ 易于使用 (Ease of Use)：folly::Singleton 提供了简洁的 API，主要就是 getInstance() 方法，使得获取单例实例非常简单直观。用户无需编写复杂的线程同步代码，即可轻松创建和使用线程安全的单例。
主要公有成员函数 (Main Public Member Functions)
⚝ static T& getInstance();：这是最核心的方法，用于获取单例实例的引用。如果实例尚未创建，它会负责创建实例并返回引用。后续的调用将直接返回已创建实例的引用。这是延迟初始化的关键入口。
⚝ static void reset();：用于重置单例实例。调用此方法会销毁现有的单例实例（如果存在），并在下次调用 getInstance() 时重新创建。需要谨慎使用 reset()，因为它可能会影响到正在使用单例实例的代码。
⚝ static bool isInstanceCreated();：用于检查单例实例是否已经被创建。返回 true 如果实例已创建，否则返回 false。这个方法在某些需要判断单例是否初始化完成的场景下很有用。
总结 (Summary)
folly::Singleton<T> 类是 folly 库中单例模式的基石。它通过模板化的设计，提供了类型安全且易于使用的单例管理方案。其核心优势在于线程安全、延迟初始化、可定制的初始化过程以及简洁的 API。理解 folly::Singleton<T> 类的结构和功能是深入学习和应用 folly::Singleton.h 的关键。在接下来的章节中，我们将详细解析每个 API 方法的使用方式和高级技巧。
5.2 getInstance() 方法的各种重载形式 (Various Overload Forms of getInstance() Method)
getInstance() 方法是 folly::Singleton<T> 类中最核心、最常用的方法。它的作用是获取单例对象 T 的实例。folly::Singleton.h 提供了多种 getInstance() 的重载形式，以满足不同的初始化需求和使用场景。本节将详细解析 getInstance() 方法的各种重载形式及其用法。
基本形式：static T& getInstance();
这是最常用的 getInstance() 方法形式，也是最简洁的形式。它不接受任何参数，直接返回单例对象 T 的引用 T&。
1
// 获取 MySingletonClass 的单例实例
2
MySingletonClass& instance = folly::Singleton<MySingletonClass>::getInstance();
3
4
// 使用单例实例
5
instance.doSomething();
特点 (Features):
⚝ 延迟初始化 (Lazy Initialization)：如果单例实例尚未创建，则在第一次调用 getInstance() 时创建。
⚝ 默认构造 (Default Construction)：单例对象 T 通过默认构造函数创建。这意味着类型 T 必须是可默认构造的。
⚝ 线程安全 (Thread-safe)：保证在多线程环境下，单例实例只会被初始化一次。
适用场景 (Scenarios):
⚝ 类型 T 具有默认构造函数，并且不需要在创建时传递任何参数。
⚝ 希望延迟初始化单例对象，以优化启动性能或资源利用率。
⚝ 大多数简单的单例场景都适用这种形式。
带初始化函数的形式：template <typename... Args, typename F> static T& getInstance(F init, Args&&... args);
这种重载形式允许用户提供一个自定义的初始化函数 init 和初始化参数 args...。这为单例对象的创建提供了更大的灵活性，可以处理需要在创建时进行复杂初始化或者需要传递参数的场景。
1
class ConfigManager {
2
public:
3
ConfigManager(const std::string& configFilePath) : filePath_(configFilePath) {
4
loadConfigFromFile(filePath_);
5
}
6
// ... 其他成员函数 ...
7
private:
8
std::string filePath_;
9
void loadConfigFromFile(const std::string& path);
10
};
11
12
// 初始化函数，接受配置文件路径作为参数
13
auto configInit = [](const std::string& path) {
14
return new ConfigManager(path);
15
};
16
17
// 获取 ConfigManager 的单例实例，并传递配置文件路径
18
ConfigManager& configInstance = folly::Singleton<ConfigManager>::getInstance(configInit, "/path/to/config.ini");
19
20
// 使用单例实例
21
configInstance.getConfigValue("LogLevel");
参数解析 (Parameter Analysis):
⚝ F init：这是一个可调用对象（函数指针、函数对象、Lambda 表达式等），用于创建和初始化单例对象 T。init 函数需要返回一个指向 T 对象的指针 T*。
⚝ Args&&... args：可变参数模板，用于传递给初始化函数 init 的参数。这些参数会被完美转发 (perfect forwarding) 给 init 函数。
特点 (Features):
⚝ 延迟初始化 (Lazy Initialization)：同样是延迟初始化，只在第一次调用时创建。
⚝ 自定义初始化 (Custom Initialization)：允许用户提供自定义的初始化函数和参数，进行更灵活的单例对象创建。
⚝ 线程安全 (Thread-safe)：初始化过程仍然是线程安全的。
适用场景 (Scenarios):
⚝ 类型 T 没有默认构造函数，或者默认构造函数不满足初始化需求。
⚝ 需要在创建单例对象时传递参数，例如配置文件路径、数据库连接信息等。
⚝ 需要执行复杂的初始化逻辑，例如从文件或数据库加载数据。
使用 Lambda 表达式作为初始化函数 (Using Lambda Expression as Initialization Function)
Lambda 表达式是 C++11 引入的特性，可以方便地创建匿名函数对象。在 folly::Singleton::getInstance() 中使用 Lambda 表达式作为初始化函数非常常见，因为它可以简洁地定义初始化逻辑，并捕获外部变量。
1
class Logger {
2
public:
3
void log(const std::string& message) {
4
std::cout << "[LOG]: " << message << std::endl;
5
}
6
};
7
8
std::string logFilePath = "/tmp/app.log"; // 外部变量
9
10
// 使用 Lambda 表达式作为初始化函数，捕获外部变量 logFilePath
11
Logger& loggerInstance = folly::Singleton<Logger>::getInstance([&logFilePath]() {
12
// 可以在 Lambda 表达式中访问和使用外部变量 logFilePath
13
// 例如，可以根据 logFilePath 初始化 Logger 对象
14
std::cout << "Logger instance initialized, log file path: " << logFilePath << std::endl;
15
return new Logger();
16
});
17
18
loggerInstance.log("Application started");
注意事项 (Precautions):
⚝ 初始化函数返回值 (Return Value of Initialization Function)：初始化函数 init 必须返回一个指向新创建的 T 对象的指针 T*。folly::Singleton 内部会负责管理这个指针，并确保单例对象的生命周期。
⚝ 异常处理 (Exception Handling)：如果在初始化函数 init 中抛出异常，folly::Singleton 会捕获这个异常，并确保单例实例不会被创建。后续的 getInstance() 调用仍然会尝试初始化，直到成功为止。需要根据实际情况考虑初始化函数中的异常处理逻辑。
⚝ 避免循环依赖 (Avoid Circular Dependencies)：在使用带初始化函数的 getInstance() 时，需要注意避免循环依赖问题。如果初始化函数依赖于其他的单例对象，可能会导致初始化顺序问题或死锁。
总结 (Summary)
getInstance() 方法的多种重载形式为 folly::Singleton 提供了强大的灵活性，可以适应各种不同的单例创建和初始化场景。理解和掌握这些重载形式，可以帮助开发者更加有效地使用 folly::Singleton.h，并构建健壮、可维护的单例管理系统。在实际应用中，应根据具体的初始化需求选择合适的 getInstance() 重载形式。
5.3 reset() 方法：Singleton 重置与销毁 ( reset() Method: Singleton Reset and Destruction)
reset() 方法是 folly::Singleton<T> 类提供的用于重置和销毁单例实例的静态方法。虽然在单例模式中，实例的生命周期通常与应用程序的生命周期一致，但在某些特殊情况下，可能需要手动重置单例实例，例如在单元测试、配置热加载或资源清理等场景。本节将详细介绍 reset() 方法的功能、使用方法以及注意事项。
reset() 方法的声明 (Declaration)
1
static void reset();
功能 (Functionality)
reset() 方法的主要功能是：
- 销毁现有实例 (Destroy Existing Instance)：如果
folly::Singleton<T>已经创建了单例实例，reset()方法会负责销毁这个实例。具体的销毁方式是调用单例对象T的析构函数，并释放其占用的内存。 - 重置内部状态 (Reset Internal State)：
reset()方法还会重置folly::Singleton<T>的内部状态，使其回到未初始化的状态。这意味着下次调用getInstance()方法时，会重新创建单例实例。
使用方法 (Usage)
reset() 方法是一个静态方法，可以直接通过 folly::Singleton<T>::reset() 的方式调用。
1
// 获取单例实例
2
MySingletonClass& instance1 = folly::Singleton<MySingletonClass>::getInstance();
3
instance1.doSomething();
4
5
// 重置单例实例
6
folly::Singleton<MySingletonClass>::reset();
7
8
// 再次获取单例实例，会创建一个新的实例
9
MySingletonClass& instance2 = folly::Singleton<MySingletonClass>::getInstance();
10
instance2.doSomethingElse();
11
12
// instance1 和 instance2 是不同的实例 (如果 MySingletonClass 的实现允许区分)
注意事项与使用场景 (Precautions and Scenarios)
⚝ 谨慎使用 (Use with Caution)：reset() 方法会销毁单例实例，这可能会影响到正在使用该单例实例的代码。因此，应该谨慎使用 reset()，确保在调用 reset() 之后，不会有代码继续访问已经被销毁的单例实例。
⚝ 线程安全 (Thread Safety)：reset() 方法本身是线程安全的。在多线程环境下调用 reset() 不会引发竞态条件。但是，需要注意的是，如果在调用 reset() 的同时，有其他线程正在访问单例实例，可能会导致未定义的行为。因此，在多线程环境中使用 reset() 需要进行适当的同步控制，确保在没有线程访问单例实例时才调用 reset()。
⚝ 单元测试 (Unit Testing)：reset() 方法在单元测试中非常有用。在每个测试用例执行之前或之后，可以调用 reset() 方法来重置单例实例，确保每个测试用例都在一个干净的环境中运行，避免测试用例之间的相互影响。
1
#include <gtest/gtest.h>
2
#include "folly/Singleton.h"
3
4
class TestSingleton {
5
public:
6
static int instanceCount;
7
TestSingleton() { instanceCount++; }
8
~TestSingleton() { instanceCount--; }
9
void doSomething() {}
10
};
11
int TestSingleton::instanceCount = 0;
12
13
TEST(SingletonTest, ResetTest) {
14
ASSERT_EQ(TestSingleton::instanceCount, 0);
15
{
16
TestSingleton& instance1 = folly::Singleton<TestSingleton>::getInstance();
17
ASSERT_EQ(TestSingleton::instanceCount, 1);
18
instance1.doSomething();
19
}
20
folly::Singleton<TestSingleton>::reset(); // 重置单例
21
ASSERT_EQ(TestSingleton::instanceCount, 0); // 实例已被销毁
22
{
23
TestSingleton& instance2 = folly::Singleton<TestSingleton>::getInstance(); // 重新创建实例
24
ASSERT_EQ(TestSingleton::instanceCount, 1);
25
instance2.doSomething();
26
}
27
folly::Singleton<TestSingleton>::reset();
28
ASSERT_EQ(TestSingleton::instanceCount, 0);
29
}
⚝ 配置热加载 (Configuration Hot Reload)：在某些需要支持配置热加载的系统中，可能需要在配置更新后重置配置管理器单例，以便重新加载新的配置。reset() 方法可以用于实现这种场景。但是，需要仔细考虑配置更新的原子性和一致性，避免在配置更新过程中出现数据不一致的问题。
⚝ 资源清理 (Resource Cleanup)：在某些特殊情况下，可能需要在程序运行过程中手动清理单例对象所占用的资源。例如，当单例对象持有大量的系统资源（如文件句柄、网络连接等）时，可能需要在不再需要这些资源时，通过 reset() 方法来释放资源。然而，更常见的做法是在程序退出时，由操作系统自动回收资源，或者依赖于 RAII (Resource Acquisition Is Initialization) 机制来管理资源。
⚝ 泄漏型单例的析构 (Destruction of Leaky Singleton)：默认情况下，folly::Singleton 实现的是泄漏型单例，即在程序退出时，单例对象可能不会被显式析构。如果需要确保单例对象在程序退出前被析构，可以考虑在 main() 函数结束前调用 folly::Singleton<T>::reset()。但这通常不是推荐的做法，因为泄漏型单例的设计初衷就是为了避免全局对象析构顺序不确定性带来的问题。
与 LeakySingleton 的关系 (Relationship with LeakySingleton)
folly::Singleton 默认是泄漏型单例。这意味着即使不调用 reset()，程序也不会因为单例对象的内存泄漏而崩溃。但是，如果单例对象持有其他资源（如文件句柄），则可能需要显式调用 reset() 来释放这些资源。LeakySingleton 是 folly::Singleton 的一个变体，它明确地声明了泄漏型单例的行为，并且不提供 reset() 方法。如果使用的是 LeakySingleton，则无法通过 reset() 方法来销毁实例。
总结 (Summary)
reset() 方法为 folly::Singleton<T> 提供了重置和销毁单例实例的能力。它在单元测试、配置热加载和资源清理等场景中非常有用。但是，由于 reset() 方法会影响单例实例的生命周期，因此需要谨慎使用，并确保在调用 reset() 前后，程序的行为符合预期。在多线程环境中使用 reset() 需要额外的同步控制。理解 reset() 方法的功能和限制，可以帮助开发者更好地管理单例对象的生命周期，并编写更健壮的应用程序。
5.4 isInstanceCreated() 方法：检查实例是否已创建 (isInstanceCreated() Method: Checking if Instance is Created)
isInstanceCreated() 方法是 folly::Singleton<T> 类提供的用于检查单例实例是否已经被创建的静态方法。在某些场景下，可能需要在不实际获取单例实例的情况下，判断实例是否已经初始化。isInstanceCreated() 方法就提供了这样的功能。本节将详细介绍 isInstanceCreated() 方法的功能、使用方法以及应用场景。
isInstanceCreated() 方法的声明 (Declaration)
1
static bool isInstanceCreated();
功能 (Functionality)
isInstanceCreated() 方法的功能非常简单直接：
⚝ 检查实例状态 (Check Instance Status)：它会检查 folly::Singleton<T> 是否已经创建了单例实例。
⚝ 返回布尔值 (Return Boolean Value)：如果单例实例已经被创建，isInstanceCreated() 方法返回 true；否则，返回 false。
使用方法 (Usage)
isInstanceCreated() 方法是一个静态方法，可以直接通过 folly::Singleton<T>::isInstanceCreated() 的方式调用。
1
// 初始状态，实例未创建
2
if (!folly::Singleton<MySingletonClass>::isInstanceCreated()) {
3
std::cout << "Singleton instance is not created yet." << std::endl;
4
}
5
6
// 获取单例实例，会触发实例创建 (如果尚未创建)
7
MySingletonClass& instance = folly::Singleton<MySingletonClass>::getInstance();
8
9
// 实例已创建
10
if (folly::Singleton<MySingletonClass>::isInstanceCreated()) {
11
std::cout << "Singleton instance is now created." << std::endl;
12
}
应用场景 (Application Scenarios)
⚝ 避免不必要的初始化 (Avoid Unnecessary Initialization)：在某些情况下，可能需要在满足特定条件时才初始化单例对象。可以使用 isInstanceCreated() 方法来检查单例是否已经初始化，如果尚未初始化，则根据条件决定是否调用 getInstance() 来创建实例。这可以避免在某些情况下不必要的单例初始化操作。
1
bool shouldInitializeSingleton() {
2
// ... 复杂的条件判断逻辑 ...
3
return true; // 假设条件满足
4
}
5
6
if (shouldInitializeSingleton() && !folly::Singleton<MyService>::isInstanceCreated()) {
7
MyService& serviceInstance = folly::Singleton<MyService>::getInstance();
8
// ... 使用 serviceInstance ...
9
} else {
10
std::cout << "Singleton initialization skipped or already initialized." << std::endl;
11
}
⚝ 延迟加载判断 (Lazy Loading Check)：在某些延迟加载的场景中，可能需要判断某个单例资源是否已经被加载。isInstanceCreated() 方法可以用于实现这种判断。例如，在启动阶段，可以检查某些可选的单例服务是否已经被初始化，并根据初始化状态执行不同的逻辑。
⚝ 状态检查与日志记录 (Status Check and Logging)：可以使用 isInstanceCreated() 方法来监控单例对象的初始化状态，并进行日志记录或状态报告。例如，可以定期检查关键单例服务是否已经启动，并将状态信息输出到日志或监控系统。
1
void monitorSingletonStatus() {
2
if (folly::Singleton<GlobalCache>::isInstanceCreated()) {
3
std::cout << "[Monitor]: GlobalCache Singleton is initialized." << std::endl;
4
} else {
5
std::cout << "[Monitor]: GlobalCache Singleton is NOT initialized." << std::endl;
6
}
7
}
8
9
// 定期调用 monitorSingletonStatus() 来监控单例状态
⚝ 条件性资源访问 (Conditional Resource Access)：在某些复杂的系统中，可能存在多个模块，其中一些模块可能依赖于某个单例资源，而另一些模块则不依赖。可以使用 isInstanceCreated() 方法来判断单例资源是否已经初始化，只有在初始化之后才进行资源访问，避免在单例未初始化时访问导致错误。
1
void moduleA() {
2
if (folly::Singleton<ResourceManager>::isInstanceCreated()) {
3
ResourceManager& resourceManager = folly::Singleton<ResourceManager>::getInstance();
4
resourceManager.accessResource();
5
} else {
6
std::cout << "[Module A]: ResourceManager Singleton is not initialized, skipping resource access." << std::endl;
7
}
8
}
9
10
void moduleB() {
11
// Module B 不依赖 ResourceManager，无需检查
12
// ...
13
}
⚝ 单元测试断言 (Unit Test Assertion)：在单元测试中，可以使用 isInstanceCreated() 方法来断言单例实例是否按照预期被创建或销毁。例如，可以验证在某个操作之后，单例实例是否已经被成功创建。
1
TEST(SingletonTest, InstanceCreationCheck) {
2
ASSERT_FALSE(folly::Singleton<MyObject>::isInstanceCreated()); // 初始状态，实例未创建
3
MyObject& instance = folly::Singleton<MyObject>::getInstance();
4
ASSERT_TRUE(folly::Singleton<MyObject>::isInstanceCreated()); // 获取实例后，实例已创建
5
folly::Singleton<MyObject>::reset();
6
ASSERT_FALSE(folly::Singleton<MyObject>::isInstanceCreated()); // reset 后，实例未创建
7
}
与 getInstance() 的关系 (Relationship with getInstance())
isInstanceCreated() 方法与 getInstance() 方法密切相关。getInstance() 方法是创建和获取单例实例的主要入口，而 isInstanceCreated() 方法则用于查询实例是否已经被 getInstance() 创建过。isInstanceCreated() 方法本身不会创建单例实例，它只是一个状态查询方法。
线程安全 (Thread Safety)
isInstanceCreated() 方法是线程安全的。在多线程环境下，可以安全地调用 isInstanceCreated() 方法来检查单例实例的状态，而不会引发竞态条件。
总结 (Summary)
isInstanceCreated() 方法是 folly::Singleton<T> 提供的一个简单但实用的辅助方法。它可以用于检查单例实例是否已经被创建，从而在各种场景下实现条件性初始化、延迟加载判断、状态监控和单元测试断言等功能。理解和合理使用 isInstanceCreated() 方法，可以提高代码的灵活性和可控性。
5.5 其他辅助 API 函数 (Other Auxiliary API Functions)
除了 getInstance(), reset(), 和 isInstanceCreated() 这三个核心 API 方法之外，folly::Singleton.h 还提供了一些辅助的 API 函数，虽然不如核心 API 常用，但在某些特定场景下也可能发挥作用。本节将介绍这些辅助 API 函数，并简要说明其用途。
folly::singleton() 函数 (The folly::singleton() Function)
实际上，folly::Singleton.h 主要提供的 API 就是通过 folly::Singleton<T> 类来实现的。并没有一个独立的名为 folly::singleton() 的全局函数直接暴露给用户使用。用户通常是通过 folly::Singleton<T>::getInstance() 来获取单例实例。
可能的辅助功能 (Possible Auxiliary Functions - Internal or Related)
虽然没有明确的 "其他辅助 API 函数" 在 folly::Singleton<T> 的公有接口中，但在 folly::Singleton.h 的内部实现或者相关的 folly 库模块中，可能存在一些辅助函数或机制，用于支持 folly::Singleton<T> 的核心功能。这些辅助功能可能包括：
⚝ 线程同步原语 (Thread Synchronization Primitives)：folly::Singleton 的线程安全初始化依赖于底层的线程同步机制。在 folly::Singleton.h 的实现中，可能会使用 folly 库提供的原子操作、互斥锁、条件变量等线程同步原语。这些原语本身可以被认为是辅助 folly::Singleton 实现线程安全性的工具。例如，folly::once_flag 和 folly::call_once 可能被用于实现延迟初始化和线程安全保证。
⚝ 内存管理工具 (Memory Management Tools)：folly::Singleton 需要管理单例对象的内存分配和释放。在内部实现中，可能会使用 folly 库提供的内存管理工具，例如 folly::make_unique, folly::make_shared (虽然 folly::Singleton 通常不使用 shared_ptr，但 folly 库本身提供了丰富的内存管理工具)。这些工具可以辅助 folly::Singleton 更有效地管理内存。
⚝ 类型 traits 和工具函数 (Type Traits and Utility Functions)：为了实现泛型和类型安全，folly::Singleton.h 的实现可能会使用 C++ 的类型 traits 和一些工具函数，例如 std::is_default_constructible, std::declval, std::forward 等。这些工具函数虽然不是 folly::Singleton 的公有 API，但它们是实现 folly::Singleton 功能的基础。
⚝ 初始化和销毁相关的内部函数 (Internal Initialization and Destruction Functions)：folly::Singleton 内部肯定有一些函数负责实际的单例对象创建、初始化和销毁过程。这些函数通常是私有的或受保护的，不对外公开。例如，可能存在一个内部的 createInstance() 函数和一个 destroyInstance() 函数，用于封装单例对象的创建和销毁逻辑。
API 文档查阅 (API Documentation Review)
为了获取 folly::Singleton.h 的最准确和全面的 API 信息，建议查阅 folly 库的官方文档或源代码。通常，folly 库会提供详细的 API 文档，描述每个类和函数的功能、参数、返回值和使用方法。通过查阅官方文档，可以了解 folly::Singleton.h 是否提供了其他公有的辅助 API 函数，以及这些函数的具体用途。
总结 (Summary)
总的来说，folly::Singleton.h 的核心 API 主要集中在 folly::Singleton<T> 类及其 getInstance(), reset(), isInstanceCreated() 方法上。虽然可能没有其他明确的 "辅助 API 函数" 直接暴露给用户，但在其内部实现和相关的 folly 库模块中，存在各种辅助工具和机制，用于支持 folly::Singleton 的核心功能。理解这些内部机制可以更深入地了解 folly::Singleton 的实现原理。对于用户而言，掌握 folly::Singleton<T> 类的核心 API 已经足够应对大多数单例模式的应用场景。如果需要更深入的了解，可以查阅 folly 库的官方文档和源代码。
本章总结 (Chapter Summary)
本章对 folly::Singleton.h 的 API 进行了全面的解析，重点介绍了 folly::Singleton<T> 类及其核心方法：
⚝ folly::Singleton<T> 类：作为单例模式的核心载体，提供了类型安全的单例管理机制。
⚝ getInstance() 方法：用于获取单例实例，具有多种重载形式，支持延迟初始化和自定义初始化。
⚝ reset() 方法：用于重置和销毁单例实例，在特定场景下用于生命周期管理。
⚝ isInstanceCreated() 方法：用于检查单例实例是否已创建，提供状态查询功能。
⚝ 其他辅助 API 函数：虽然公有接口中没有明显的其他辅助 API，但内部实现依赖于 folly 库提供的各种线程同步、内存管理和类型工具。
通过本章的学习，读者应该对 folly::Singleton.h 的 API 有了清晰的认识，并能够根据实际需求选择合适的 API 方法来使用 folly::Singleton，构建高效、可靠的单例管理系统。在接下来的章节中，我们将通过实战案例分析和源码剖析，进一步深入理解 folly::Singleton.h 的应用和实现原理。
END_OF_CHAPTER
6. chapter 6： 实战案例分析： folly::Singleton.h 的应用场景 (Practical Case Study Analysis: Application Scenarios of folly::Singleton.h)
6.1 日志系统 (Logging System) 的 Singleton 实现 (Singleton Implementation of Logging System)
日志系统 (Logging System) 在软件开发中扮演着至关重要的角色，它帮助开发者追踪程序运行状态、诊断错误和进行性能分析。在一个复杂的系统中，日志组件往往需要被全局访问和使用，以确保任何模块都能够方便地记录日志信息。单例模式 (Singleton Pattern) 非常适合用于实现日志系统，因为它能够保证系统中只有一个日志实例，从而实现日志的统一管理和输出。folly::Singleton.h 提供了一种高效且线程安全的单例实现方式，非常适合构建高性能的日志系统。
为什么使用 Singleton 实现日志系统？
① 全局访问点 (Global Access Point)：日志功能需要在程序的各个角落都能方便地调用。单例模式提供的全局访问点使得任何模块都可以轻松获取唯一的日志实例，无需显式地传递日志对象。
② 资源统一管理 (Unified Resource Management)：日志系统通常涉及文件操作、网络传输等资源。使用单例模式可以更好地管理这些资源，例如，控制日志文件的打开和关闭，避免资源泄露。
③ 配置集中管理 (Centralized Configuration Management)：日志系统的配置，如日志级别、输出格式、日志目的地等，通常是全局性的。单例模式可以方便地将配置信息集中管理在唯一的日志实例中，便于统一配置和修改。
日志系统 Singleton 实现的基本设计
一个基本的日志系统 Singleton 实现通常包含以下几个核心组件：
① 日志器类 (Logger Class)：这是日志系统的核心类，负责接收日志消息、格式化日志内容，并将日志输出到指定的目的地（如文件、控制台、网络等）。
② 日志级别 (Log Level)：定义日志消息的严重程度，例如 DEBUG、INFO、WARN、ERROR、FATAL 等。日志系统可以根据配置的日志级别过滤掉不重要的日志信息。
③ 日志格式化器 (Log Formatter)：负责将原始的日志消息格式化成易于阅读和分析的字符串。格式化器可以定义日志的时间戳、日志级别、线程 ID、日志消息内容等信息的输出格式。
④ 日志输出器 (Log Appender)：负责将格式化后的日志消息输出到不同的目的地。常见的输出器包括文件输出器、控制台输出器、网络输出器等。
使用 folly::Singleton.h 实现日志系统
下面是一个使用 folly::Singleton.h 实现简单日志系统的代码示例。为了简洁明了，这个示例只包含最基本的功能，例如日志级别和控制台输出。
1
#include <folly/Singleton.h>
2
#include <iostream>
3
#include <string>
4
#include <chrono>
5
#include <ctime>
6
#include <iomanip>
7
8
// 日志级别枚举
9
enum class LogLevel {
10
DEBUG,
11
INFO,
12
WARN,
13
ERROR,
14
FATAL
15
};
16
17
// 日志器类
18
class Logger {
19
public:
20
// 获取 Singleton 实例
21
static Logger& getInstance() {
22
return folly::Singleton<Logger>::getInstance();
23
}
24
25
// 设置日志级别
26
void setLevel(LogLevel level) {
27
logLevel_ = level;
28
}
29
30
// 记录 DEBUG 级别日志
31
void debug(const std::string& message) {
32
log(LogLevel::DEBUG, message);
33
}
34
35
// 记录 INFO 级别日志
36
void info(const std::string& message) {
37
log(LogLevel::INFO, message);
38
}
39
40
// 记录 WARN 级别日志
41
void warn(const std::string& message) {
42
log(LogLevel::WARN, message);
43
}
44
45
// 记录 ERROR 级别日志
46
void error(const std::string& message) {
47
log(LogLevel::ERROR, message);
48
}
49
50
// 记录 FATAL 级别日志
51
void fatal(const std::string& message) {
52
log(LogLevel::FATAL, message);
53
}
54
55
private:
56
Logger() : logLevel_(LogLevel::INFO) {} // 私有构造函数
57
Logger(const Logger&) = delete; // 禁用拷贝构造函数
58
Logger& operator=(const Logger&) = delete; // 禁用赋值运算符
59
60
// 实际的日志记录函数
61
void log(LogLevel level, const std::string& message) {
62
if (level < logLevel_) {
63
return; // 日志级别不够，不记录
64
}
65
66
std::cout << formatLog(level, message) << std::endl;
67
}
68
69
// 格式化日志消息
70
std::string formatLog(LogLevel level, const std::string& message) {
71
auto now = std::chrono::system_clock::now();
72
auto now_c = std::chrono::system_clock::to_time_t(now);
73
std::tm now_tm;
74
localtime_r(&now_c, &now_tm);
75
std::stringstream ss;
76
ss << std::put_time(&now_tm, "%Y-%m-%d %H:%M:%S");
77
std::string timestamp = ss.str();
78
79
std::string levelStr;
80
switch (level) {
81
case LogLevel::DEBUG: levelStr = "DEBUG"; break;
82
case LogLevel::INFO: levelStr = "INFO"; break;
83
case LogLevel::WARN: levelStr = "WARN"; break;
84
case LogLevel::ERROR: levelStr = "ERROR"; break;
85
case LogLevel::FATAL: levelStr = "FATAL"; break;
86
default: levelStr = "UNKNOWN"; break;
87
}
88
89
std::stringstream formattedLog;
90
formattedLog << "[" << timestamp << "] [" << levelStr << "] " << message;
91
return formattedLog.str();
92
}
93
94
private:
95
LogLevel logLevel_; // 当前日志级别
96
};
97
98
int main() {
99
// 获取日志器实例
100
Logger& logger = Logger::getInstance();
101
102
// 设置日志级别为 DEBUG
103
logger.setLevel(LogLevel::DEBUG);
104
105
// 记录不同级别的日志
106
logger.debug("This is a debug message.");
107
logger.info("This is an info message.");
108
logger.warn("This is a warning message.");
109
logger.error("This is an error message.");
110
logger.fatal("This is a fatal message.");
111
112
// 在其他模块中也可以直接使用 Logger::getInstance() 获取日志实例并记录日志
113
return 0;
114
}
代码解析
① Logger 类：定义了日志器类，包含 getInstance() 静态方法用于获取单例实例，以及 debug(), info(), warn(), error(), fatal() 等日志记录方法。
② folly::Singleton<Logger>::getInstance()：使用 folly::Singleton<Logger> 来管理 Logger 类的单例实例。getInstance() 方法负责创建和返回唯一的 Logger 实例。
③ 私有构造函数和禁用拷贝：Logger 类的构造函数被声明为私有 (private)，拷贝构造函数和赋值运算符被禁用 (deleted)，以防止从外部创建多个 Logger 实例，确保单例模式的实现。
④ 日志级别控制：setLevel() 方法用于设置日志级别，log() 方法会根据当前日志级别过滤掉不重要的日志消息。
⑤ 日志格式化：formatLog() 方法负责将日志消息格式化成包含时间戳和日志级别的字符串。
线程安全性
folly::Singleton.h 默认提供线程安全的单例创建和访问机制。在多线程环境下，多个线程同时调用 Logger::getInstance() 获取日志实例时，folly::Singleton.h 能够保证只有一个 Logger 实例被创建，并且所有线程获取到的是同一个实例。此外，示例代码中的日志记录操作（std::cout 输出）本身在多线程环境下可能存在线程安全问题，实际应用中，日志输出部分通常需要使用线程安全的机制，例如使用互斥锁 (mutex) 或线程安全的日志库。
总结
使用 folly::Singleton.h 可以方便快捷地实现线程安全的日志系统单例。通过单例模式，日志系统可以被全局访问和统一管理，为程序的调试、监控和维护提供了便利。在实际应用中，可以根据需求扩展日志系统的功能，例如添加更多的日志级别、更丰富的日志格式、支持多种日志输出目的地等。
6.2 配置管理中心 (Configuration Management Center) 的 Singleton 设计 (Singleton Design of Configuration Management Center)
配置管理中心 (Configuration Management Center) 负责管理应用程序的各种配置信息，例如数据库连接信息、服务器地址、功能开关等。配置信息通常需要在应用程序的多个模块中共享和访问。使用单例模式 (Singleton Pattern) 来设计配置管理中心可以确保配置信息的全局唯一性和一致性，避免配置信息分散和不一致的问题。folly::Singleton.h 同样非常适合用于实现配置管理中心的单例模式。
为什么使用 Singleton 实现配置管理中心？
① 全局配置访问 (Global Configuration Access)：应用程序的各个模块都需要访问配置信息。单例模式提供的全局访问点使得任何模块都可以方便地获取唯一的配置管理中心实例，从而获取所需的配置信息。
② 配置信息缓存 (Configuration Information Caching)：配置信息通常从配置文件、数据库或其他外部源加载。使用单例模式可以将配置信息加载到内存中并缓存起来，避免每次访问配置信息时都重新加载，提高性能。
③ 配置动态更新 (Dynamic Configuration Update)：配置管理中心可以提供配置动态更新的功能，当配置信息发生变化时，能够及时通知应用程序并更新配置，而单例模式可以方便地实现配置更新的广播和同步。
配置管理中心 Singleton 实现的基本设计
一个基本的配置管理中心 Singleton 实现通常包含以下几个核心组件：
① 配置管理器类 (ConfigManager Class)：这是配置管理中心的核心类，负责加载、存储和管理配置信息，并提供访问配置信息的接口。
② 配置加载器 (Config Loader)：负责从不同的配置源（如配置文件、数据库、远程配置中心等）加载配置信息。
③ 配置缓存 (Config Cache)：用于缓存已加载的配置信息，提高配置信息的访问速度。
④ 配置更新机制 (Config Update Mechanism)：用于监听配置信息的变化，并及时更新配置缓存和通知应用程序。
使用 folly::Singleton.h 实现配置管理中心
下面是一个使用 folly::Singleton.h 实现简单配置管理中心的示例，该示例从一个简单的配置文件 config.ini 中加载配置信息，并提供获取配置项的接口。
首先，创建配置文件 config.ini，内容如下：
1
[Database]
2
Host = localhost
3
Port = 3306
4
Username = user
5
Password = password
6
7
[Server]
8
Address = 127.0.0.1
9
Port = 8080
然后，编写 C++ 代码实现配置管理中心 Singleton：
1
#include <folly/Singleton.h>
2
#include <fstream>
3
#include <iostream>
4
#include <map>
5
#include <sstream>
6
#include <stdexcept>
7
8
// 配置管理器类
9
class ConfigManager {
10
public:
11
// 获取 Singleton 实例
12
static ConfigManager& getInstance() {
13
return folly::Singleton<ConfigManager>::getInstance();
14
}
15
16
// 加载配置文件
17
void loadConfig(const std::string& filePath) {
18
std::ifstream configFile(filePath);
19
if (!configFile.is_open()) {
20
throw std::runtime_error("Failed to open config file: " + filePath);
21
}
22
23
std::string line;
24
std::string currentSection;
25
while (std::getline(configFile, line)) {
26
line = trim(line); // 去除首尾空格
27
if (line.empty() || line[0] == ';') { // 忽略空行和注释行
28
continue;
29
}
30
31
if (line[0] == '[' && line.back() == ']') { // Section
32
currentSection = line.substr(1, line.length() - 2);
33
} else { // Key-Value pair
34
size_t equalPos = line.find('=');
35
if (equalPos != std::string::npos) {
36
std::string key = trim(line.substr(0, equalPos));
37
std::string value = trim(line.substr(equalPos + 1));
38
configMap_[currentSection][key] = value;
39
}
40
}
41
}
42
}
43
44
// 获取配置项的值
45
std::string getConfig(const std::string& section, const std::string& key) const {
46
auto sectionIt = configMap_.find(section);
47
if (sectionIt != configMap_.end()) {
48
auto keyIt = sectionIt->second.find(key);
49
if (keyIt != sectionIt->second.end()) {
50
return keyIt->second;
51
}
52
}
53
return ""; // 未找到配置项，返回空字符串
54
}
55
56
private:
57
ConfigManager() {} // 私有构造函数
58
ConfigManager(const ConfigManager&) = delete; // 禁用拷贝构造函数
59
ConfigManager& operator=(const ConfigManager&) = delete; // 禁用赋值运算符
60
61
// 去除字符串首尾空格
62
std::string trim(const std::string& str) {
63
size_t first = str.find_first_not_of(' ');
64
if (std::string::npos == first) {
65
return str;
66
}
67
size_t last = str.find_last_not_of(' ');
68
return str.substr(first, (last - first + 1));
69
}
70
71
private:
72
std::map<std::string, std::map<std::string, std::string>> configMap_; // 配置信息存储
73
};
74
75
int main() {
76
// 获取配置管理器实例
77
ConfigManager& configManager = ConfigManager::getInstance();
78
79
// 加载配置文件
80
configManager.loadConfig("config.ini");
81
82
// 获取配置项
83
std::string dbHost = configManager.getConfig("Database", "Host");
84
std::string dbPort = configManager.getConfig("Database", "Port");
85
std::string serverAddress = configManager.getConfig("Server", "Address");
86
std::string serverPort = configManager.getConfig("Server", "Port");
87
88
// 打印配置信息
89
std::cout << "Database Host: " << dbHost << std::endl;
90
std::cout << "Database Port: " << dbPort << std::endl;
91
std::cout << "Server Address: " << serverAddress << std::endl;
92
std::cout << "Server Port: " << serverPort << std::endl;
93
94
return 0;
95
}
代码解析
① ConfigManager 类：定义了配置管理器类，包含 getInstance() 静态方法用于获取单例实例，loadConfig() 方法用于加载配置文件，getConfig() 方法用于获取配置项的值。
② folly::Singleton<ConfigManager>::getInstance()：使用 folly::Singleton<ConfigManager> 来管理 ConfigManager 类的单例实例。
③ loadConfig() 方法：负责读取 config.ini 配置文件，解析配置项，并将配置信息存储到 configMap_ 成员变量中。配置文件采用 INI 格式，支持 Section 和 Key-Value 对。
④ getConfig() 方法：根据 Section 和 Key 获取配置项的值。
⑤ 配置信息存储：使用 std::map<std::string, std::map<std::string, std::string>> configMap_ 来存储配置信息，外层 map 的 key 是 Section 名称，内层 map 的 key 是配置项的 Key，value 是配置项的 Value。
配置动态更新
示例代码只实现了配置信息的加载和获取，实际的配置管理中心通常还需要支持配置动态更新。配置动态更新可以通过以下几种方式实现：
① 定时轮询 (Polling)：配置管理中心定时轮询配置源（如配置文件、数据库、远程配置中心），检查配置信息是否发生变化，如果发生变化，则重新加载配置并更新缓存。
② 事件通知 (Event Notification)：当配置源的配置信息发生变化时，配置源主动通知配置管理中心，配置管理中心接收到通知后，重新加载配置并更新缓存。
③ 配置中心推送 (Configuration Center Push)：使用专门的配置中心服务，配置中心服务能够主动推送配置更新到应用程序。
总结
使用 folly::Singleton.h 可以方便地实现配置管理中心的单例模式。通过单例模式，配置信息可以被全局访问和统一管理，避免配置信息分散和不一致的问题。在实际应用中，可以根据需求扩展配置管理中心的功能，例如支持多种配置格式、多种配置源、配置动态更新、配置版本管理等。
6.3 线程池 (Thread Pool) 的 Singleton 管理 (Singleton Management of Thread Pool)
线程池 (Thread Pool) 是一种常用的并发编程技术，它可以有效地管理和复用线程资源，提高程序的性能和响应速度。在某些场景下，例如服务器程序或需要处理大量并发任务的应用程序中，线程池通常只需要一个全局实例。使用单例模式 (Singleton Pattern) 来管理线程池可以确保系统中只有一个线程池实例，避免资源浪费和管理混乱。folly::Singleton.h 同样可以用于实现线程池的单例管理。
为什么使用 Singleton 管理线程池？
① 全局线程池访问 (Global Thread Pool Access)：应用程序的多个模块可能需要提交任务到线程池执行。单例模式提供的全局访问点使得任何模块都可以方便地获取唯一的线程池实例，并提交任务。
② 线程资源统一管理 (Unified Thread Resource Management)：线程池负责创建和管理线程资源。使用单例模式可以更好地控制线程池的生命周期和资源使用，例如，在应用程序启动时创建线程池，在应用程序退出时销毁线程池。
③ 避免线程池重复创建 (Avoid Thread Pool Duplication)：在某些情况下，如果多个模块各自创建线程池，可能会导致线程资源浪费和系统负载过高。使用单例模式可以确保系统中只有一个线程池实例，避免线程池的重复创建。
线程池 Singleton 实现的基本设计
一个基本的线程池 Singleton 实现通常包含以下几个核心组件：
① 线程池类 (ThreadPool Class)：这是线程池的核心类，负责创建和管理线程、维护任务队列、执行任务等。
② 任务队列 (Task Queue)：用于存储待执行的任务。任务队列通常使用线程安全的数据结构，例如 std::queue 或 folly::MPMCQueue。
③ 工作线程 (Worker Threads)：线程池中的工作线程负责从任务队列中取出任务并执行。
④ 线程池配置 (Thread Pool Configuration)：包括线程池的大小（线程数量）、任务队列的大小、线程的创建策略等。
使用 folly::Singleton.h 管理线程池
下面是一个使用 folly::Singleton.h 管理简单线程池的示例。为了简化示例，这里使用 std::thread 和 std::queue 实现一个基本的线程池，实际应用中可以使用更成熟的线程池库，例如 folly::Executor 或 boost::asio::thread_pool。
1
#include <folly/Singleton.h>
2
#include <iostream>
3
#include <queue>
4
#include <thread>
5
#include <vector>
6
#include <functional>
7
#include <mutex>
8
#include <condition_variable>
9
10
// 线程池类
11
class ThreadPool {
12
public:
13
// 获取 Singleton 实例
14
static ThreadPool& getInstance() {
15
return folly::Singleton<ThreadPool>::getInstance();
16
}
17
18
// 初始化线程池
19
void initialize(size_t threadCount) {
20
if (initialized_) {
21
return; // 已经初始化，直接返回
22
}
23
24
threadCount_ = threadCount;
25
stop_ = false;
26
for (size_t i = 0; i < threadCount_; ++i) {
27
workers_.emplace_back([this] { // 创建工作线程
28
while (true) {
29
std::function<void()> task;
30
{
31
std::unique_lock<std::mutex> lock(queueMutex_);
32
condition_.wait(lock, [this] { return stop_ || !taskQueue_.empty(); }); // 等待任务或停止信号
33
if (stop_ && taskQueue_.empty()) {
34
return; // 线程池停止，且任务队列为空，线程退出
35
}
36
task = std::move(taskQueue_.front()); // 从任务队列取出任务
37
taskQueue_.pop();
38
}
39
task(); // 执行任务
40
}
41
});
42
}
43
initialized_ = true;
44
}
45
46
// 提交任务
47
template<class F, class... Args>
48
auto enqueue(F&& f, Args&&... args) -> std::future<typename std::result_of<F(Args...)>::type> {
49
if (!initialized_) {
50
throw std::runtime_error("ThreadPool is not initialized.");
51
}
52
53
using return_type = typename std::result_of<F(Args...)>::type;
54
auto task = std::make_shared<std::packaged_task<return_type()>>(
55
std::bind(std::forward<F>(f), std::forward<Args>(args)...)
56
);
57
58
std::future<return_type> res = task->get_future();
59
{
60
std::unique_lock<std::mutex> lock(queueMutex_);
61
if (stop_) {
62
throw std::runtime_error("enqueue on stopped ThreadPool.");
63
}
64
taskQueue_.push([task]() { (*task)(); }); // 将任务添加到任务队列
65
}
66
condition_.notify_one(); // 通知一个工作线程
67
return res;
68
}
69
70
// 停止线程池
71
void stop() {
72
{
73
std::unique_lock<std::mutex> lock(queueMutex_);
74
stop_ = true;
75
}
76
condition_.notify_all(); // 通知所有工作线程
77
for (std::thread& worker : workers_) {
78
worker.join(); // 等待所有工作线程退出
79
}
80
workers_.clear();
81
initialized_ = false;
82
}
83
84
private:
85
ThreadPool() : initialized_(false), stop_(true), threadCount_(0) {} // 私有构造函数
86
ThreadPool(const ThreadPool&) = delete; // 禁用拷贝构造函数
87
ThreadPool& operator=(const ThreadPool&) = delete; // 禁用赋值运算符
88
~ThreadPool() {
89
if (initialized_) {
90
stop(); // 析构时停止线程池
91
}
92
}
93
94
private:
95
bool initialized_; // 是否已初始化
96
bool stop_; // 是否停止
97
size_t threadCount_; // 线程数量
98
std::vector<std::thread> workers_; // 工作线程
99
std::queue<std::function<void()>> taskQueue_; // 任务队列
100
std::mutex queueMutex_; // 任务队列互斥锁
101
std::condition_variable condition_; // 条件变量
102
};
103
104
int main() {
105
// 获取线程池实例
106
ThreadPool& threadPool = ThreadPool::getInstance();
107
108
// 初始化线程池，创建 4 个工作线程
109
threadPool.initialize(4);
110
111
// 提交任务到线程池
112
auto future1 = threadPool.enqueue([]{
113
std::cout << "Task 1 executed by thread: " << std::this_thread::get_id() << std::endl;
114
return 10;
115
});
116
117
auto future2 = threadPool.enqueue([]{
118
std::cout << "Task 2 executed by thread: " << std::this_thread::get_id() << std::endl;
119
return 20;
120
});
121
122
// 获取任务执行结果
123
int result1 = future1.get();
124
int result2 = future2.get();
125
126
std::cout << "Task 1 result: " << result1 << std::endl;
127
std::cout << "Task 2 result: " << result2 << std::endl;
128
129
// 停止线程池
130
threadPool.stop();
131
132
return 0;
133
}
代码解析
① ThreadPool 类：定义了线程池类，包含 getInstance() 静态方法用于获取单例实例，initialize() 方法用于初始化线程池，enqueue() 方法用于提交任务，stop() 方法用于停止线程池。
② folly::Singleton<ThreadPool>::getInstance()：使用 folly::Singleton<ThreadPool> 来管理 ThreadPool 类的单例实例。
③ initialize() 方法：创建指定数量的工作线程，并启动工作线程的循环，等待从任务队列中获取任务。
④ enqueue() 方法：将任务封装成 std::packaged_task，并添加到任务队列中，然后通过条件变量 condition_ 通知一个工作线程。
⑤ stop() 方法：设置停止标志 stop_，通知所有工作线程退出，并等待所有工作线程结束。
⑥ 线程同步：使用互斥锁 queueMutex_ 和条件变量 condition_ 来实现线程同步，保证任务队列的线程安全访问和工作线程的等待/唤醒机制。
线程池配置
示例代码中的线程池配置比较简单，只支持设置线程数量。实际应用中，线程池的配置通常更加复杂，例如：
① 线程池大小 (Thread Pool Size)：可以根据系统负载和任务类型动态调整线程池的大小。
② 任务队列大小 (Task Queue Size)：限制任务队列的最大长度，防止任务堆积过多导致内存溢出。
③ 拒绝策略 (Rejected Execution Handler)：当任务队列已满且无法提交新任务时，定义拒绝策略，例如抛出异常、丢弃任务或阻塞提交线程。
④ 线程工厂 (Thread Factory)：自定义线程的创建方式，例如设置线程名称、线程优先级等。
总结
使用 folly::Singleton.h 可以方便地实现线程池的单例管理。通过单例模式，线程池可以被全局访问和统一管理，有效地管理和复用线程资源。在实际应用中，可以使用更成熟的线程池库，并根据需求配置线程池的参数，以满足不同的并发处理需求。
6.4 缓存 (Cache) 系统的 Singleton 应用 (Singleton Application of Cache System)
缓存 (Cache) 系统是提高应用程序性能的关键组件，它通过将频繁访问的数据存储在高速存储介质（如内存）中，减少对低速存储介质（如磁盘、数据库）的访问，从而加快数据访问速度。在许多应用场景中，缓存系统只需要一个全局实例，例如，Web 服务器的页面缓存、数据库查询缓存等。使用单例模式 (Singleton Pattern) 来实现缓存系统可以确保系统中只有一个缓存实例，实现缓存数据的共享和统一管理。folly::Singleton.h 同样适用于实现缓存系统的单例模式。
为什么使用 Singleton 实现缓存系统？
① 全局缓存访问 (Global Cache Access)：应用程序的多个模块可能需要访问缓存数据。单例模式提供的全局访问点使得任何模块都可以方便地获取唯一的缓存实例，并进行缓存操作。
② 缓存数据共享 (Cache Data Sharing)：使用单例模式可以确保所有模块访问的是同一个缓存实例，从而实现缓存数据的共享，避免数据冗余和不一致。
③ 缓存策略统一管理 (Unified Cache Policy Management)：缓存系统的策略，例如缓存大小、缓存淘汰算法、缓存过期策略等，通常是全局性的。单例模式可以方便地将缓存策略集中管理在唯一的缓存实例中，便于统一配置和修改。
缓存系统 Singleton 实现的基本设计
一个基本的缓存系统 Singleton 实现通常包含以下几个核心组件：
① 缓存类 (Cache Class)：这是缓存系统的核心类，负责存储缓存数据、提供缓存操作接口（如 put, get, remove 等）、实现缓存淘汰算法等。
② 缓存存储 (Cache Storage)：用于存储缓存数据的容器。常用的缓存存储容器包括 std::map, std::unordered_map, folly::ConcurrentHashMap 等。
③ 缓存淘汰算法 (Cache Eviction Algorithm)：当缓存空间不足时，需要根据一定的算法淘汰部分缓存数据，以腾出空间存储新的数据。常见的缓存淘汰算法包括 LRU (Least Recently Used)、LFU (Least Frequently Used)、FIFO (First In First Out) 等。
④ 缓存过期策略 (Cache Expiration Policy)：缓存数据通常需要设置过期时间，过期后的数据会被自动或手动移除。
使用 folly::Singleton.h 实现缓存系统
下面是一个使用 folly::Singleton.h 实现简单 LRU 缓存的示例。为了简化示例，这里使用 std::unordered_map 作为缓存存储，并实现一个简单的 LRU 淘汰算法。实际应用中可以使用更成熟的缓存库，例如 folly::Cache 或 memcached, redis 等。
1
#include <folly/Singleton.h>
2
#include <iostream>
3
#include <unordered_map>
4
#include <list>
5
#include <mutex>
6
7
// LRU 缓存类
8
template <typename Key, typename Value>
9
class LRUCache {
10
public:
11
// 获取 Singleton 实例
12
static LRUCache<Key, Value>& getInstance(size_t capacity) {
13
static LRUCache<Key, Value> instance(capacity); // 静态局部变量，线程安全初始化
14
return instance;
15
// 注意：这里没有使用 folly::Singleton<LRUCache<Key, Value>>，
16
// 因为容量 capacity 需要在创建实例时指定，而 folly::Singleton 默认无参构造。
17
// 可以考虑使用 folly::SingletonVoid 或自定义初始化函数来解决这个问题，
18
// 但为了示例简洁，这里使用静态局部变量的方式。
19
}
20
21
// 放入缓存
22
void put(const Key& key, const Value& value) {
23
std::lock_guard<std::mutex> lock(mutex_);
24
auto it = cacheMap_.find(key);
25
if (it != cacheMap_.end()) {
26
// Key 已存在，更新 value，并将节点移动到链表头部
27
cacheList_.erase(it->second.listIt);
28
cacheList_.push_front(key);
29
it->second.listIt = cacheList_.begin();
30
it->second.value = value;
31
} else {
32
// Key 不存在，插入新的 Key-Value 对
33
if (cacheMap_.size() >= capacity_) {
34
// 缓存已满，淘汰 LRU 数据
35
Key lruKey = cacheList_.back();
36
cacheList_.pop_back();
37
cacheMap_.erase(lruKey);
38
}
39
cacheList_.push_front(key);
40
cacheMap_[key] = {cacheList_.begin(), value};
41
}
42
}
43
44
// 获取缓存
45
bool get(const Key& key, Value& value) {
46
std::lock_guard<std::mutex> lock(mutex_);
47
auto it = cacheMap_.find(key);
48
if (it != cacheMap_.end()) {
49
// Key 存在，将节点移动到链表头部
50
cacheList_.erase(it->second.listIt);
51
cacheList_.push_front(key);
52
it->second.listIt = cacheList_.begin();
53
value = it->second.value;
54
return true;
55
} else {
56
// Key 不存在
57
return false;
58
}
59
}
60
61
// 移除缓存
62
void remove(const Key& key) {
63
std::lock_guard<std::mutex> lock(mutex_);
64
auto it = cacheMap_.find(key);
65
if (it != cacheMap_.end()) {
66
cacheList_.erase(it->second.listIt);
67
cacheMap_.erase(key);
68
}
69
}
70
71
private:
72
LRUCache(size_t capacity) : capacity_(capacity) {} // 私有构造函数
73
LRUCache(const LRUCache&) = delete; // 禁用拷贝构造函数
74
LRUCache& operator=(const LRUCache&) = delete; // 禁用赋值运算符
75
76
private:
77
size_t capacity_; // 缓存容量
78
std::unordered_map<Key, struct CacheNode> cacheMap_; // 缓存数据存储
79
std::list<Key> cacheList_; // LRU 链表，存储 Key 的访问顺序
80
std::mutex mutex_; // 互斥锁，保护缓存数据线程安全
81
struct CacheNode {
82
typename std::list<Key>::iterator listIt; // LRU 链表迭代器
83
Value value; // 缓存值
84
};
85
};
86
87
int main() {
88
// 获取 LRU 缓存实例，容量为 3
89
LRUCache<std::string, std::string>& cache = LRUCache<std::string, std::string>::getInstance(3);
90
91
// 放入缓存
92
cache.put("key1", "value1");
93
cache.put("key2", "value2");
94
cache.put("key3", "value3");
95
96
// 获取缓存
97
std::string value;
98
if (cache.get("key2", value)) {
99
std::cout << "Get key2 from cache: " << value << std::endl; // Output: Get key2 from cache: value2
100
}
101
102
cache.put("key4", "value4"); // 触发 LRU 淘汰，key1 被淘汰
103
104
if (!cache.get("key1", value)) {
105
std::cout << "key1 not found in cache." << std::endl; // Output: key1 not found in cache.
106
}
107
108
if (cache.get("key2", value)) {
109
std::cout << "Get key2 from cache: " << value << std::endl; // Output: Get key2 from cache: value2
110
}
111
112
if (cache.get("key3", value)) {
113
std::cout << "Get key3 from cache: " << value << std::endl; // Output: Get key3 from cache: value3
114
}
115
116
if (cache.get("key4", value)) {
117
std::cout << "Get key4 from cache: " << value << std::endl; // Output: Get key4 from cache: value4
118
}
119
120
return 0;
121
}
代码解析
① LRUCache 类：定义了 LRU 缓存类，使用模板参数 Key 和 Value 支持不同类型的 Key 和 Value。包含 getInstance() 静态方法用于获取单例实例，put() 方法用于放入缓存，get() 方法用于获取缓存，remove() 方法用于移除缓存。
② getInstance(size_t capacity) 静态方法：使用静态局部变量 instance 来实现单例模式。由于 folly::Singleton 默认使用无参构造函数，而 LRUCache 需要在创建时指定容量 capacity，因此这里没有直接使用 folly::Singleton。静态局部变量的方式也能保证线程安全的单例初始化。
③ 缓存存储：使用 std::unordered_map<Key, struct CacheNode> cacheMap_ 存储缓存数据，Key 为缓存键，Value 为 CacheNode 结构体。CacheNode 结构体包含 LRU 链表迭代器 listIt 和缓存值 value。
④ LRU 淘汰算法：使用 std::list<Key> cacheList_ 维护 LRU 链表，链表头部表示最近访问的数据，链表尾部表示最久未访问的数据。当缓存满时，淘汰链表尾部的数据。
⑤ 线程安全：使用互斥锁 mutex_ 保护缓存数据的线程安全访问。
缓存策略
示例代码只实现了简单的 LRU 缓存，实际的缓存系统通常需要支持更丰富的缓存策略，例如：
① 缓存淘汰算法 (Cache Eviction Algorithm)：除了 LRU，还可以支持 LFU、FIFO、Random 等多种淘汰算法。
② 缓存过期策略 (Cache Expiration Policy)：支持基于时间的过期策略，例如设置缓存数据的 TTL (Time To Live)。
③ 缓存穿透、击穿、雪崩 (Cache Penetration, Cache Breakdown, Cache Avalanche) 保护：采取措施防止缓存穿透、击穿、雪崩等问题，提高缓存系统的稳定性和可靠性。
④ 多级缓存 (Multi-level Cache)：使用多级缓存架构，例如 L1 缓存、L2 缓存等，进一步提高缓存性能。
总结
使用 folly::Singleton.h (或静态局部变量方式) 可以方便地实现缓存系统的单例模式。通过单例模式，缓存系统可以被全局访问和统一管理，实现缓存数据的共享和统一策略管理。在实际应用中，可以使用更成熟的缓存库，并根据需求选择合适的缓存策略，以满足不同的性能和功能需求。
6.5 游戏服务器中的全局管理器 (Global Manager in Game Server) 的 Singleton 模式 (Singleton Pattern of Global Manager in Game Server)
在游戏服务器开发中，经常需要使用全局管理器 (Global Manager) 来管理游戏世界的各种资源、状态和逻辑。例如，世界管理器 (World Manager) 负责管理游戏世界地图、场景、物体等；玩家管理器 (Player Manager) 负责管理在线玩家的信息；资源管理器 (Resource Manager) 负责加载和管理游戏资源等。这些全局管理器通常只需要一个全局实例，以便在游戏服务器的各个模块中方便地访问和使用。单例模式 (Singleton Pattern) 非常适合用于实现游戏服务器中的全局管理器，folly::Singleton.h 同样可以应用于此场景。
为什么使用 Singleton 实现游戏服务器全局管理器？
① 全局访问 (Global Access)：游戏服务器的各个模块（如场景逻辑、战斗逻辑、网络通信等）都需要访问全局管理器提供的功能和数据。单例模式提供的全局访问点使得任何模块都可以方便地获取全局管理器实例。
② 状态统一管理 (Unified State Management)：全局管理器通常负责维护游戏世界的全局状态，例如当前在线玩家列表、游戏世界时间、全局配置信息等。使用单例模式可以确保全局状态的统一性和一致性。
③ 模块解耦 (Module Decoupling)：使用全局管理器可以降低模块之间的耦合度。模块之间不需要直接依赖和交互，而是通过全局管理器进行间接通信和数据共享。
游戏服务器全局管理器 Singleton 实现的基本设计
一个典型的游戏服务器全局管理器 Singleton 实现通常包含以下几个核心组件：
① 管理器类 (Manager Class)：这是全局管理器的核心类，负责管理特定的游戏资源、状态或逻辑，并提供访问接口。
② 管理器初始化 (Manager Initialization)：在游戏服务器启动时，需要初始化全局管理器，加载必要的资源和配置。
③ 管理器功能接口 (Manager Function Interface)：全局管理器需要提供一系列接口，供其他模块访问和使用其功能。
④ 管理器生命周期管理 (Manager Lifecycle Management)：全局管理器的生命周期通常与游戏服务器的生命周期一致，在服务器启动时创建，在服务器关闭时销毁。
使用 folly::Singleton.h 实现游戏世界管理器
下面是一个使用 folly::Singleton.h 实现简单游戏世界管理器 (WorldManager) 的示例。该示例只包含世界管理器的基本框架，实际的游戏世界管理器通常会更加复杂，包含更多的功能和数据。
1
#include <folly/Singleton.h>
2
#include <iostream>
3
#include <vector>
4
#include <string>
5
6
// 游戏世界管理器类
7
class WorldManager {
8
public:
9
// 获取 Singleton 实例
10
static WorldManager& getInstance() {
11
return folly::Singleton<WorldManager>::getInstance();
12
}
13
14
// 初始化世界管理器
15
void initialize() {
16
if (initialized_) {
17
return; // 已经初始化，直接返回
18
}
19
std::cout << "WorldManager initializing..." << std::endl;
20
// 加载世界地图数据、初始化游戏场景等
21
gameWorlds_.push_back("World1");
22
gameWorlds_.push_back("World2");
23
initialized_ = true;
24
}
25
26
// 获取所有世界列表
27
const std::vector<std::string>& getWorlds() const {
28
return gameWorlds_;
29
}
30
31
// 获取世界信息 (示例方法，实际应用中可能更复杂)
32
std::string getWorldInfo(const std::string& worldName) const {
33
for (const auto& world : gameWorlds_) {
34
if (world == worldName) {
35
return "World: " + worldName + ", Status: Running";
36
}
37
}
38
return "World: " + worldName + ", Not Found";
39
}
40
41
private:
42
WorldManager() : initialized_(false) {} // 私有构造函数
43
WorldManager(const WorldManager&) = delete; // 禁用拷贝构造函数
44
WorldManager& operator=(const WorldManager&) = delete; // 禁用赋值运算符
45
46
private:
47
bool initialized_; // 是否已初始化
48
std::vector<std::string> gameWorlds_; // 游戏世界列表
49
};
50
51
int main() {
52
// 获取世界管理器实例
53
WorldManager& worldManager = WorldManager::getInstance();
54
55
// 初始化世界管理器
56
worldManager.initialize();
57
58
// 获取世界列表
59
const auto& worlds = worldManager.getWorlds();
60
std::cout << "Game Worlds: ";
61
for (const auto& world : worlds) {
62
std::cout << world << " ";
63
}
64
std::cout << std::endl;
65
66
// 获取世界信息
67
std::cout << worldManager.getWorldInfo("World1") << std::endl;
68
std::cout << worldManager.getWorldInfo("World3") << std::endl;
69
70
// 在游戏服务器的其他模块中，也可以直接使用 WorldManager::getInstance() 获取世界管理器实例
71
return 0;
72
}
代码解析
① WorldManager 类：定义了游戏世界管理器类，包含 getInstance() 静态方法用于获取单例实例，initialize() 方法用于初始化世界管理器，getWorlds() 方法用于获取世界列表，getWorldInfo() 方法用于获取世界信息（示例方法）。
② folly::Singleton<WorldManager>::getInstance()：使用 folly::Singleton<WorldManager> 来管理 WorldManager 类的单例实例。
③ initialize() 方法：负责世界管理器的初始化工作，例如加载世界地图数据、初始化游戏场景等。示例代码中只是简单地添加了两个世界名称到 gameWorlds_ 列表中。
④ getWorlds() 和 getWorldInfo() 方法：提供访问世界列表和世界信息的接口。
常见的游戏服务器全局管理器
除了世界管理器，游戏服务器中常见的全局管理器还包括：
① 玩家管理器 (Player Manager)：管理在线玩家的信息，例如玩家 ID、角色数据、在线状态等。
② 资源管理器 (Resource Manager)：加载和管理游戏资源，例如模型、贴图、音效、动画等。
③ 配置管理器 (Config Manager)：管理游戏服务器的配置信息，例如服务器参数、游戏规则配置等（可以与 6.2 节的配置管理中心 Singleton 结合）。
④ 日志管理器 (Log Manager)：负责游戏服务器的日志记录（可以与 6.1 节的日志系统 Singleton 结合）。
⑤ 网络管理器 (Network Manager)：处理网络通信，例如客户端连接管理、消息路由、数据传输等。
总结
使用 folly::Singleton.h 可以方便地实现游戏服务器中全局管理器的单例模式。通过单例模式，全局管理器可以被全局访问和统一管理，实现游戏资源的统一管理、游戏状态的集中维护和模块之间的解耦。在实际游戏服务器开发中，可以根据游戏的需求设计和实现各种全局管理器，并使用 folly::Singleton.h 来管理它们的单例实例。
END_OF_CHAPTER
7. chapter 7： Singleton 模式的替代方案与最佳实践 (Alternatives and Best Practices of Singleton Pattern)
7.1 Singleton 模式的反模式 (Anti-patterns of Singleton Pattern)
Singleton 模式作为一种创建型设计模式，在特定场景下能够有效地控制全局资源的访问和管理。然而，不恰当的使用 Singleton 模式可能会导致代码质量下降，增加维护难度，甚至引入潜在的 bug。本节将深入探讨 Singleton 模式常见的反模式，帮助读者识别和避免这些陷阱。
① 全局状态的蔓延 (Global State Sprawl)：
Singleton 最常见的反模式就是它鼓励了全局状态的使用。由于 Singleton 实例在整个应用程序生命周期内都是唯一的，并且可以从任何地方访问，这很容易导致开发者将越来越多的状态放入 Singleton 中，使其成为一个无所不包的全局容器。
⚝ 问题：全局状态使得代码难以理解和维护。各个模块之间通过全局 Singleton 紧密耦合，修改 Singleton 的状态可能会对程序的其他部分产生意想不到的影响，增加了调试和测试的难度。此外，全局状态也降低了代码的可重用性和可测试性。
⚝ 示例：假设一个配置管理 Singleton，最初只负责加载和提供配置信息。但随着项目发展，开发者可能会逐渐将日志记录、缓存管理甚至业务逻辑也塞入这个 Singleton 中，最终导致它变得臃肿且难以维护。
② 隐藏的依赖关系 (Hidden Dependencies)：
Singleton 模式将依赖关系隐藏在代码中。当一个类依赖于 Singleton 提供的服务时，这种依赖关系并没有显式地声明在类的接口中，而是隐含在类的实现细节中。
⚝ 问题：隐藏的依赖关系使得代码的依赖结构变得模糊不清。开发者很难一眼看出一个类依赖了哪些外部组件，这增加了代码的理解难度，也使得依赖关系的变更变得更加复杂和容易出错。在单元测试中，隐藏的依赖关系也会使得 Mocking 和隔离被测单元变得困难。
⚝ 示例：一个 UserService 类直接通过 LoggerSingleton::getInstance() 获取日志记录器实例，并在其方法中使用。这种依赖关系在 UserService 类的接口中是不可见的，只有查看其代码才能发现。
③ 难以测试 (Difficult to Test)：
Singleton 模式使得单元测试变得更加困难，主要原因在于其全局性和静态性。
⚝ 问题：
▮▮▮▮ⓐ 状态持久性：Singleton 实例的状态在测试之间是持久存在的，这可能会导致测试用例之间相互影响，出现测试结果不稳定或难以重现的情况。为了保证测试的独立性，可能需要在每个测试用例执行前后手动重置 Singleton 的状态，但这增加了测试的复杂性。
▮▮▮▮ⓑ Mocking 困难：由于 getInstance() 方法通常是静态的，传统的 Mocking 框架难以直接 Mock Singleton 的行为。为了测试依赖于 Singleton 的类，可能需要采用更复杂的 Mocking 技术，例如使用友元类、模板注入或者修改代码结构以支持依赖注入。
⚝ 示例：要测试 UserService 类，需要 Mock LoggerSingleton 的行为，例如验证日志是否被正确记录。但由于 LoggerSingleton 是一个静态 Singleton，直接 Mock LoggerSingleton::getInstance() 方法比较困难。
④ 违反单一职责原则 (Violation of Single Responsibility Principle)：
有时候，Singleton 类承担了过多的职责，不仅仅是作为单例实例的提供者，还包含了大量的业务逻辑或全局管理功能，违反了单一职责原则。
⚝ 问题：当 Singleton 类承担过多职责时，会导致类变得臃肿、复杂且难以维护。修改 Singleton 类的任何一部分都可能影响到其他不相关的功能，增加了代码的风险。
⚝ 示例：一个 SystemManagerSingleton 不仅负责作为单例管理系统资源，还包含了复杂的系统初始化、配置加载、事件处理等逻辑，使得这个类变得难以理解和维护。
⑤ 多线程环境下的性能瓶颈 (Performance Bottleneck in Multi-threaded Environments)：
虽然 folly::Singleton.h 提供了线程安全的 Singleton 实现，但在高并发的多线程环境下，如果 Singleton 的 getInstance() 方法或其提供的服务成为热点，可能会导致性能瓶颈。
⚝ 问题：为了保证线程安全，getInstance() 方法可能需要使用锁机制，在高并发场景下，锁竞争会降低程序的性能。此外，如果 Singleton 实例的操作本身是耗时的，例如访问数据库或进行复杂的计算，也会成为性能瓶颈。
⚝ 示例：一个全局计数器 Singleton，在高并发请求下，每次请求都需要获取锁来增加计数器，这可能会成为性能瓶颈。
总结：
Singleton 模式虽然在某些场景下很有用，但需要谨慎使用，避免落入上述反模式的陷阱。在设计系统时，应该仔细权衡 Singleton 的优缺点，并考虑是否有更合适的替代方案。在后续章节中，我们将介绍 Singleton 模式的替代方案和最佳实践，帮助读者更好地选择和使用设计模式。
7.2 依赖注入 (Dependency Injection) 与控制反转 (Inversion of Control) 原则 (Principles of Dependency Injection and Inversion of Control)
依赖注入 (Dependency Injection, DI) 和控制反转 (Inversion of Control, IoC) 是面向对象设计中重要的原则和模式，它们旨在降低组件之间的耦合度，提高代码的可维护性、可测试性和可扩展性。理解 DI 和 IoC 原则对于理解 Singleton 模式的替代方案至关重要。
① 控制反转 (Inversion of Control, IoC)：
控制反转是一种设计原则，它描述了程序控制流的转移。传统的程序设计中，程序的控制权在应用程序本身，由应用程序决定何时创建对象以及如何调用对象的方法。而 IoC 则将部分控制权转移给外部容器或框架。
⚝ 核心思想：Don't call us, we'll call you. 即，不要由组件自身去控制依赖项的创建和管理，而是将这些控制权反转给外部容器。
⚝ IoC 的类型：
▮▮▮▮ⓐ 依赖注入 (Dependency Injection, DI)：DI 是 IoC 的一种具体实现方式。它关注于如何将组件的依赖项注入到组件中。
▮▮▮▮ⓑ 服务定位器 (Service Locator)：服务定位器是另一种 IoC 的实现方式，它提供一个全局注册表，组件可以从中查找和获取依赖项。
▮▮▮▮ⓒ 模板方法 (Template Method) 和 策略模式 (Strategy Pattern) 等设计模式也体现了 IoC 的思想，通过将部分控制权交给子类或客户端代码。
② 依赖注入 (Dependency Injection, DI)：
依赖注入是一种实现 IoC 的具体模式，它旨在解决对象之间的依赖关系管理问题。DI 的核心思想是将对象的依赖项通过构造函数、方法参数或属性注入的方式传递给对象，而不是由对象自身创建或查找依赖项。
⚝ DI 的类型：
▮▮▮▮ⓐ 构造函数注入 (Constructor Injection)：依赖项通过构造函数的参数传递给对象。这是最常用和推荐的 DI 方式，因为它能够清晰地表达对象的必要依赖。
1
class UserService {
2
public:
3
UserService(Logger* logger) : logger_(logger) {} // 构造函数注入 Logger 依赖
4
void doSomething() {
5
logger_->log("User service doing something.");
6
// ...
7
}
8
private:
9
Logger* logger_;
10
};
▮▮▮▮ⓑ Setter 注入 (Setter Injection)：依赖项通过 Setter 方法传递给对象。Setter 注入适用于可选依赖或在对象创建后才可用的依赖。
1
class UserService {
2
public:
3
void setLogger(Logger* logger) { // Setter 注入 Logger 依赖
4
logger_ = logger;
5
}
6
void doSomething() {
7
if (logger_) {
8
logger_->log("User service doing something.");
9
}
10
// ...
11
}
12
private:
13
Logger* logger_;
14
};
▮▮▮▮ⓒ 接口注入 (Interface Injection)：定义一个接口，包含注入依赖项的方法，然后让组件实现该接口，并通过接口方法注入依赖项。接口注入相对较少使用，通常用于框架级别的设计。
⚝ DI 容器 (DI Container)：
为了更好地管理和维护对象之间的依赖关系，通常会使用 DI 容器（也称为 IoC 容器）。DI 容器负责对象的创建、配置和生命周期管理，并自动将依赖项注入到对象中。常见的 C++ DI 容器包括：
▮▮▮▮ⓐ Poco::Manifest (Poco 库的一部分)
▮▮▮▮ⓑ Boost.DI (Boost 库的一部分)
▮▮▮▮ⓒ fruit (Google 开源)
▮▮▮▮ⓓ TinyDI (轻量级 DI 容器)
⚝ DI 的优点：
▮▮▮▮ⓐ 降低耦合度：组件不再直接依赖于具体的依赖项实现，而是依赖于抽象接口。这降低了组件之间的耦合度，提高了代码的灵活性和可维护性。
▮▮▮▮ⓑ 提高可测试性：通过 DI，可以很容易地替换组件的依赖项，例如在单元测试中使用 Mock 对象替代真实的依赖项，从而隔离被测单元，提高测试的效率和准确性。
▮▮▮▮ⓒ 提高代码可重用性：组件不再负责创建和管理依赖项，使得组件可以更容易地在不同的环境和场景下重用。
▮▮▮▮ⓓ 提高代码可扩展性：通过 DI 容器，可以方便地配置和管理组件的依赖关系，使得系统更容易扩展和演化。
③ DI 与 Singleton 的关系：
Singleton 模式本身与 DI 原则存在一定的冲突。Singleton 模式通过静态方法 getInstance() 提供全局唯一的实例，这使得组件直接依赖于 Singleton 的具体实现，违反了 DI 的依赖倒置原则。
⚝ Singleton 作为一种服务：
在某些情况下，可以将 Singleton 视为一种服务，通过 DI 容器进行管理和注入。例如，可以将 LoggerSingleton 注册到 DI 容器中，然后通过 DI 容器将 Logger 接口的实现注入到需要日志记录的组件中。这样既可以保证 Logger 实例的唯一性，又可以利用 DI 的优点，降低耦合度，提高可测试性。
⚝ 避免过度使用 Singleton：
DI 原则提倡组件之间的松耦合，而 Singleton 模式容易导致全局状态和隐藏的依赖关系，因此在设计系统时，应该尽量避免过度使用 Singleton。对于那些真正需要全局唯一实例的场景，可以考虑使用 DI 容器来管理 Singleton 实例，并将其作为一种服务注入到需要的组件中。
总结：
依赖注入和控制反转是重要的设计原则，它们有助于构建松耦合、可维护、可测试和可扩展的系统。理解 DI 和 IoC 原则可以帮助我们更好地选择和使用设计模式，并在某些情况下，使用 DI 来替代或改进 Singleton 模式的应用。
7.3 服务定位器 (Service Locator) 模式 (Service Locator Pattern)
服务定位器 (Service Locator) 模式是另一种用于解耦组件依赖关系的模式，它提供一个全局注册表，组件可以通过该注册表查找和获取所需的依赖项。服务定位器模式是控制反转 (IoC) 的一种实现方式，与依赖注入 (DI) 模式类似，但实现方式和优缺点有所不同。
① 服务定位器模式的结构：
服务定位器模式主要包含以下几个角色：
⚝ Service Locator (服务定位器)：服务定位器是一个全局注册表，负责注册和管理各种服务（依赖项）。它提供一个 locateService(ServiceName) 方法，用于根据服务名称查找并返回相应的服务实例。
⚝ Service (服务)：服务是组件需要依赖的抽象接口或具体类。服务通常注册到服务定位器中，并由服务定位器管理其生命周期。
⚝ Client (客户端)：客户端是需要使用服务的组件。客户端通过服务定位器的 locateService() 方法查找并获取所需的服务实例。
② 服务定位器模式的实现：
一个简单的服务定位器模式实现可以使用一个静态的 std::map 来存储服务名称和服务实例的映射关系。
1
#include <iostream>
2
#include <map>
3
#include <memory>
4
#include <string>
5
6
// 服务接口
7
class Logger {
8
public:
9
virtual void log(const std::string& message) = 0;
10
virtual ~Logger() = default;
11
};
12
13
// 具体服务实现
14
class ConsoleLogger : public Logger {
15
public:
16
void log(const std::string& message) override {
17
std::cout << "[ConsoleLogger] " << message << std::endl;
18
}
19
};
20
21
// 服务定位器
22
class ServiceLocator {
23
public:
24
// 注册服务
25
template <typename ServiceType, typename ImplementationType>
26
static void registerService() {
27
services_[typeid(ServiceType)] = std::make_shared<ImplementationType>();
28
}
29
30
// 定位服务
31
template <typename ServiceType>
32
static std::shared_ptr<ServiceType> locateService() {
33
auto it = services_.find(typeid(ServiceType));
34
if (it != services_.end()) {
35
return std::static_pointer_cast<ServiceType>(it->second);
36
}
37
return nullptr; // 服务未找到
38
}
39
40
private:
41
static std::map<std::type_index, std::shared_ptr<void>> services_;
42
};
43
44
std::map<std::type_index, std::shared_ptr<void>> ServiceLocator::services_;
45
46
int main() {
47
// 注册服务
48
ServiceLocator::registerService<Logger, ConsoleLogger>();
49
50
// 客户端代码
51
std::shared_ptr<Logger> logger = ServiceLocator::locateService<Logger>();
52
if (logger) {
53
logger->log("Hello from Service Locator!");
54
}
55
56
return 0;
57
}
③ 服务定位器模式与依赖注入模式的比较：
服务定位器模式和依赖注入模式都是用于解耦组件依赖关系的 IoC 实现方式，但它们在实现方式和优缺点上有所不同。
| 特性 | 依赖注入 (DI) | 服务定位器 (Service Locator) |
|---|---|---|
| 依赖获取方式 | 外部容器注入依赖项到组件中 | 组件主动从服务定位器查找依赖项 |
| 依赖关系显式性 | 依赖关系在组件的接口（构造函数、Setter）中显式声明 | 依赖关系隐藏在组件的实现中，需要查看代码才能发现 |
| 可测试性 | 更容易 Mock 依赖项，测试隔离性更好 | 依赖于全局服务定位器，Mocking 相对复杂，测试隔离性稍差 |
| 代码可读性 | 依赖关系清晰，代码可读性更高 | 依赖关系隐含，代码可读性稍差 |
| 运行时错误 | 依赖关系在编译时或容器配置时检查，更早发现错误 | 依赖关系在运行时查找，错误可能延迟到运行时才暴露 |
| 灵活性 | 更灵活，支持多种注入方式，易于扩展和配置 | 相对简单，但灵活性和扩展性稍差 |
④ 服务定位器模式的优缺点：
⚝ 优点：
▮▮▮▮ⓐ 解耦依赖关系：服务定位器模式可以有效地解耦组件之间的依赖关系，使得组件不再直接依赖于具体的依赖项实现。
▮▮▮▮ⓑ 集中管理服务：服务定位器提供一个全局注册表，可以集中管理和配置各种服务，方便服务的注册、查找和替换。
▮▮▮▮ⓒ 延迟查找依赖：服务定位器允许组件在需要时才查找依赖项，可以实现延迟加载和按需创建服务实例。
⚝ 缺点：
▮▮▮▮ⓐ 隐藏的依赖关系：与 Singleton 模式类似，服务定位器模式也将依赖关系隐藏在代码中，使得代码的依赖结构变得模糊不清，降低了代码的可读性和可维护性。
▮▮▮▮ⓑ 可测试性挑战：虽然比 Singleton 模式有所改善，但服务定位器模式仍然依赖于全局的服务定位器实例，Mocking 和测试隔离性不如依赖注入模式。
▮▮▮▮ⓒ 运行时错误：服务查找发生在运行时，如果服务未注册或配置错误，错误可能会延迟到运行时才暴露，不如依赖注入模式在编译时或配置时就能发现错误。
⑤ 何时使用服务定位器模式：
服务定位器模式适用于以下场景：
▮▮▮▮ⓐ 简单的依赖管理：对于小型项目或简单的依赖关系管理，服务定位器模式可能比依赖注入模式更简单易用。
▮▮▮▮ⓑ 延迟查找依赖：当需要延迟加载或按需创建服务实例时，服务定位器模式可以提供更灵活的控制。
▮▮▮▮ⓒ 遗留系统改造：在改造遗留系统时，服务定位器模式可能更容易引入，逐步解耦系统中的依赖关系。
总结：
服务定位器模式是 Singleton 模式的一种替代方案，它可以解耦组件之间的依赖关系，并提供一种集中管理服务的方式。然而，服务定位器模式也存在隐藏依赖关系、可测试性挑战等缺点。在选择使用服务定位器模式还是依赖注入模式时，需要根据具体的项目需求和场景进行权衡。通常来说，对于大型、复杂的项目，依赖注入模式往往是更优的选择，因为它能够提供更好的代码可读性、可维护性和可测试性。
7.4 何时应该避免使用 Singleton (When to Avoid Using Singleton)
Singleton 模式虽然在某些特定场景下有其存在的价值，但过度或不恰当的使用 Singleton 模式会带来诸多问题，如全局状态蔓延、隐藏依赖关系、难以测试等反模式。因此，了解何时应该避免使用 Singleton 模式至关重要。
① 存在多个实例的可能：
如果逻辑上或未来需求上可能需要存在多个实例，那么就不应该使用 Singleton 模式。Singleton 模式的核心约束就是保证只有一个实例，如果这个约束不成立，那么 Singleton 模式就不适用。
⚝ 示例：
▮▮▮▮ⓐ 数据库连接池：虽然在某些简单场景下可以使用 Singleton 管理数据库连接池，但在高并发、分布式系统中，通常需要多个数据库连接池实例，例如每个数据库实例一个连接池，或者根据业务模块划分连接池。此时，Singleton 就不再适用。
▮▮▮▮ⓑ 缓存管理器：对于分布式缓存系统，通常需要多个缓存管理器实例，例如本地缓存、分布式缓存等，或者根据缓存策略或数据类型划分缓存管理器。Singleton 无法满足这种多实例的需求.
② 需要可配置或可替换的实现：
如果组件的实现需要根据不同的环境、配置或策略进行替换或配置，那么 Singleton 模式会降低灵活性。Singleton 实例通常在编译时或程序启动时静态绑定，难以在运行时动态替换或配置。
⚝ 示例：
▮▮▮▮ⓐ 日志记录器：在开发环境、测试环境和生产环境，可能需要使用不同的日志记录器实现，例如控制台日志、文件日志、远程日志等。如果使用 Singleton 管理日志记录器，则需要在编译时或程序启动时确定日志记录器的实现，难以在运行时动态切换。
▮▮▮▮ⓑ 支付服务：系统可能需要对接多种支付渠道，例如支付宝、微信支付、银行卡支付等。每种支付渠道的实现方式和配置参数都可能不同。如果使用 Singleton 管理支付服务，则难以灵活地配置和切换不同的支付渠道实现。
③ 组件具有状态且状态需要隔离：
如果组件具有状态，并且在不同的上下文或场景下需要隔离状态，那么 Singleton 模式可能会导致状态冲突或数据污染。Singleton 实例是全局共享的，所有客户端都访问同一个实例，共享同一份状态。
⚝ 示例：
▮▮▮▮ⓐ 用户会话管理器：Web 应用中的用户会话管理器需要为每个用户维护独立的用户会话状态。如果使用 Singleton 管理用户会话管理器，则无法为每个用户隔离会话状态，会导致会话数据混淆或安全问题。
▮▮▮▮ⓑ 事务管理器：在事务处理系统中，每个事务需要独立的事务上下文和状态。如果使用 Singleton 管理事务管理器，则无法为每个事务隔离事务状态，会导致事务冲突或数据一致性问题。
④ 过度使用全局状态：
如果使用 Singleton 模式仅仅是为了方便地访问全局状态，那么应该反思是否过度使用了全局状态。全局状态会增加代码的耦合度，降低可维护性和可测试性。应该尽量减少全局状态的使用，将状态封装在组件内部，并通过接口进行访问。
⚝ 替代方案：
▮▮▮▮ⓐ 参数传递：将状态作为参数传递给需要使用状态的组件。
▮▮▮▮ⓑ 聚合根 (Aggregate Root)：将相关状态封装在聚合根对象中，并通过聚合根对象管理状态的访问。
▮▮▮▮ⓒ 上下文对象 (Context Object)：创建一个上下文对象，封装需要在多个组件之间共享的状态，并将上下文对象传递给需要的组件。
⑤ 为了“方便”而使用 Singleton：
有时候，开发者仅仅为了“方便”地访问某个对象或服务而使用 Singleton 模式，例如避免通过参数传递对象，或者简化对象的创建过程。这种情况下，应该重新评估 Singleton 模式的必要性，并考虑是否有更合适的设计方案。
⚝ 示例：
▮▮▮▮ⓐ 配置参数访问：为了方便地在代码的任何地方访问配置参数，将配置参数管理类设计成 Singleton。但更好的做法是将配置参数加载到配置对象中，并将配置对象通过依赖注入或参数传递的方式传递给需要的组件。
▮▮▮▮ⓑ 工具类访问：为了方便地访问工具类的方法，将工具类设计成 Singleton。但工具类通常是无状态的，可以将工具类的方法设计成静态方法，或者使用命名空间来组织工具类。
总结：
Singleton 模式并非万能的，在很多情况下，过度或不恰当的使用 Singleton 模式会带来负面影响。在决定使用 Singleton 模式之前，应该仔细评估其适用性，并考虑是否有更合适的替代方案。如果存在多个实例的可能性、需要可配置或可替换的实现、组件具有状态且状态需要隔离、或者仅仅为了“方便”而使用 Singleton，那么就应该避免使用 Singleton 模式，并考虑使用依赖注入、服务定位器或其他更合适的设计模式。
7.5 folly::Singleton.h 的最佳实践总结 (Summary of Best Practices for folly::Singleton.h)
folly::Singleton.h 提供了高效、线程安全的 Singleton 模式实现，但在使用 folly::Singleton.h 时，仍然需要遵循一些最佳实践，以确保代码的质量和可维护性。
① 明确 Singleton 的必要性：
在使用 folly::Singleton.h 之前，首先要明确 Singleton 模式是否是解决问题的最佳方案。回顾上一节 "何时应该避免使用 Singleton"，仔细评估当前场景是否真的需要使用 Singleton 模式，避免为了使用而使用。
② 谨慎管理全局状态：
folly::Singleton.h 容易导致全局状态的蔓延。在使用 Singleton 管理状态时，要谨慎控制 Singleton 实例的状态范围和生命周期，避免将不必要的状态放入 Singleton 中，并尽量减少全局状态的使用。
③ 使用延迟初始化 (Lazy Initialization)：
folly::Singleton.h 默认使用延迟初始化，即在第一次调用 getInstance() 方法时才创建 Singleton 实例。延迟初始化可以避免不必要的资源消耗，提高程序启动速度。除非有特殊需求，否则建议使用默认的延迟初始化方式。
④ 考虑使用 LeakySingleton：
对于程序生命周期内始终存在的 Singleton 实例，可以考虑使用 LeakySingleton。LeakySingleton 不会在程序退出时销毁 Singleton 实例，避免了静态析构顺序问题，并可能略微提高性能。但需要权衡内存泄漏的风险，确保在程序退出后，Singleton 实例占用的资源能够被操作系统回收。
⑤ 自定义初始化函数 (Custom Initialization Function)：
folly::Singleton.h 允许自定义初始化函数，可以在 Singleton 实例创建后执行一些初始化操作。可以使用自定义初始化函数来加载配置、初始化资源或执行其他必要的准备工作。
1
class MySingleton {
2
public:
3
static MySingleton* getInstance() {
4
return folly::Singleton<MySingleton>::getInstance([]() {
5
auto instance = new MySingleton();
6
instance->initialize(); // 自定义初始化函数
7
return instance;
8
});
9
}
10
11
private:
12
MySingleton() = default;
13
void initialize() {
14
// 初始化操作
15
std::cout << "MySingleton initialized." << std::endl;
16
}
17
friend class folly::Singleton<MySingleton>;
18
};
⑥ 避免在 Singleton 中进行耗时操作：
Singleton 实例的 getInstance() 方法可能会被频繁调用，特别是在多线程环境下。应避免在 getInstance() 方法或 Singleton 实例的初始化过程中进行耗时操作，例如文件 I/O、网络请求或复杂的计算。如果必须进行耗时操作，可以考虑使用异步初始化或线程池来提高性能。
⑦ 充分利用 API 函数：
folly::Singleton.h 提供了丰富的 API 函数，例如 reset()、isInstanceCreated() 等。充分利用这些 API 函数可以更好地管理 Singleton 实例的生命周期和状态。例如，可以使用 reset() 方法在单元测试中重置 Singleton 实例的状态，或者使用 isInstanceCreated() 方法检查 Singleton 实例是否已经创建。
⑧ 单元测试与 Mocking：
虽然 folly::Singleton.h 使得单元测试比传统的 Singleton 实现更容易，但仍然需要注意 Mocking 的问题。可以使用友元类、模板注入或修改代码结构等方式来支持 Mocking。在单元测试中，可以使用 reset() 方法重置 Singleton 实例的状态，保证测试用例的独立性。
⑨ 代码审查与团队协作：
Singleton 模式的使用容易引入全局状态和隐藏的依赖关系，因此在团队协作开发中，需要进行充分的代码审查，确保 Singleton 模式的使用是合理和必要的，并遵循最佳实践。
总结：
folly::Singleton.h 是一个强大而高效的 Singleton 模式实现，但正确使用它仍然需要谨慎和经验。遵循上述最佳实践，可以帮助开发者更好地利用 folly::Singleton.h，构建高质量、可维护的 C++ 代码。在实际项目中，需要根据具体的场景和需求，权衡 Singleton 模式的优缺点，并选择最合适的设计方案。
END_OF_CHAPTER
8. chapter 8： folly::Singleton.h 源码剖析与实现原理 (Source Code Analysis and Implementation Principles of folly::Singleton.h)
8.1 folly::Singleton 的内部结构 (Internal Structure of folly::Singleton)
要深入理解 folly::Singleton.h 的强大之处和高效性，我们首先需要剖析其内部结构。folly::Singleton<T> 并非一个简单的宏或语法糖，而是一个精心设计的模板类，它在保证线程安全和易用性的同时，还考虑了性能和灵活性。
从概念上讲，folly::Singleton<T> 的核心目标是管理类型 T 的单例实例。为了实现这一目标，其内部结构主要围绕以下几个关键要素展开：
① 静态成员变量 (Static Member Variable)：这是存储单例实例的场所。folly::Singleton 内部会维护一个静态的、类型为 T* 的指针，用于指向单例对象的内存地址。这个指针是延迟初始化的核心，只有在首次调用 getInstance() 时，才会进行实际的内存分配和对象构造。
② 互斥锁 (Mutex)：为了确保在多线程环境下的线程安全性，folly::Singleton 内部通常会包含一个互斥锁（std::mutex 或 folly 提供的更轻量级的锁）。这个互斥锁用于保护单例实例的创建过程，防止多个线程同时尝试创建单例，从而保证单例的唯一性。
③ 初始化标志 (Initialization Flag)：为了优化性能，避免每次调用 getInstance() 都进行加锁操作，folly::Singleton 内部会使用一个原子布尔标志（std::atomic<bool>）来记录单例实例是否已经被初始化。这个标志允许在实例创建后，后续的 getInstance() 调用可以绕过锁竞争，直接返回已创建的实例。
④ 类型擦除 (Type Erasure) 与 detail 命名空间：folly::Singleton 的实现细节，例如互斥锁和初始化标志，通常会被封装在 detail 命名空间下。这是一种常见的 C++ 库设计模式，用于隐藏内部实现细节，对外只暴露简洁的接口。同时，为了支持更灵活的初始化方式，folly::Singleton 内部可能会使用类型擦除技术，例如通过函数指针或 std::function 来处理自定义的初始化函数。
为了更具体地展示 folly::Singleton 的内部结构，我们可以 conceptualize 一个简化的、高度抽象的 C++ 代码片段，请注意，这并非 folly::Singleton 的真实源码，而是为了帮助理解其内部原理的示意性代码：
1
namespace folly {
2
namespace detail {
3
4
template <typename T>
5
struct SingletonStorage {
6
static T* instance; // 静态实例指针
7
static std::mutex mutex; // 互斥锁
8
static std::atomic<bool> initialized; // 初始化标志
9
};
10
11
template <typename T> T* SingletonStorage<T>::instance = nullptr;
12
template <typename T> std::mutex SingletonStorage<T>::mutex;
13
template <typename T> std::atomic<bool> SingletonStorage<T>::initialized{false};
14
15
} // namespace detail
16
17
template <typename T>
18
class Singleton {
19
public:
20
static T* getInstance() {
21
if (!detail::SingletonStorage<T>::initialized.load(std::memory_order_relaxed)) { // 快速检查，无锁
22
std::lock_guard<std::mutex> lock(detail::SingletonStorage<T>::mutex); // 加锁
23
if (!detail::SingletonStorage<T>::initialized.load(std::memory_order_relaxed)) { // 双重检查
24
detail::SingletonStorage<T>::instance = new T(); // 创建实例
25
detail::SingletonStorage<T>::initialized.store(true, std::memory_order_release); // 设置初始化标志
26
}
27
}
28
return detail::SingletonStorage<T>::instance; // 返回实例
29
}
30
31
// ... 其他方法，例如 reset(), isInstanceCreated() 等 ...
32
33
private:
34
Singleton() = default; // 禁用外部构造
35
Singleton(const Singleton&) = delete;
36
Singleton& operator=(const Singleton&) = delete;
37
};
38
39
} // namespace folly
代码解释：
⚝ detail::SingletonStorage<T> 结构体：
▮▮▮▮⚝ instance：静态成员变量，类型为 T*，用于存储单例实例的指针。初始值为 nullptr，表示尚未创建实例。
▮▮▮▮⚝ mutex：静态成员变量，类型为 std::mutex，用于线程同步，保护实例的创建过程。
▮▮▮▮⚝ initialized：静态成员变量，类型为 std::atomic<bool>，原子布尔标志，用于记录实例是否已初始化。初始值为 false。
⚝ folly::Singleton<T> 类：
▮▮▮▮⚝ getInstance() 方法：
▮▮▮▮▮▮▮▮⚝ 快速路径（无锁）：首先使用 std::memory_order_relaxed 原子加载 initialized 标志。如果已初始化，则直接返回 instance，无需加锁，性能高效。
▮▮▮▮▮▮▮▮⚝ 慢速路径（加锁）：如果 initialized 为 false，则获取互斥锁 mutex。
▮▮▮▮▮▮▮▮⚝ 双重检查锁定 (Double-Checked Locking)：在获取锁之后，再次检查 initialized 标志，这是为了防止在等待锁的过程中，其他线程已经完成了初始化。
▮▮▮▮▮▮▮▮⚝ 实例创建：如果 initialized 仍然为 false，则使用 new T() 创建 T 类型的实例，并将指针赋值给 instance。
▮▮▮▮▮▮▮▮⚝ 设置初始化标志：使用 std::memory_order_release 原子存储 true 到 initialized 标志，通知其他线程实例已创建。
▮▮▮▮▮▮▮▮⚝ 返回实例：返回指向单例实例的指针 instance。
▮▮▮▮⚝ 私有构造函数、拷贝构造函数和赋值运算符：这些被禁用，以防止从外部直接创建 folly::Singleton<T> 的实例，强制用户必须通过 getInstance() 方法获取单例实例。
总结：
folly::Singleton<T> 的内部结构围绕着静态存储、线程安全和延迟初始化这三个核心要素展开。通过静态成员变量存储实例，互斥锁保证线程安全，原子标志和双重检查锁定优化性能，folly::Singleton 提供了一个高效、可靠且易于使用的单例模式实现。在实际的 folly 库源码中，实现会更加复杂和精细，例如会考虑自定义初始化函数、LeakySingleton 的特殊情况等，但其核心思想与上述简化模型是一致的。理解了 folly::Singleton 的内部结构，有助于我们更好地使用和理解其 API，并在必要时进行定制和扩展。
8.2 线程安全机制的实现细节 (Implementation Details of Thread Safety Mechanism)
线程安全性是 folly::Singleton.h 设计中至关重要的考量。在多线程并发环境中，如果单例实例的创建和访问没有得到妥善的保护，就可能出现以下问题：
⚝ 竞态条件 (Race Condition)：多个线程同时尝试创建单例实例，导致创建多次，破坏单例模式的唯一性。
⚝ 数据竞争 (Data Race)：多个线程同时访问和修改单例实例的内部状态，导致数据不一致或程序崩溃。
folly::Singleton.h 通过一系列精巧的机制来确保线程安全，主要包括以下几个方面：
① 互斥锁 (Mutex) 的使用：如前所述，folly::Singleton 内部使用互斥锁来保护单例实例的创建过程。当多个线程同时调用 getInstance() 方法时，只有一个线程能够成功获取锁，进入临界区 (Critical Section) 执行实例创建代码。其他线程会被阻塞，直到锁被释放。这保证了在同一时刻，只有一个线程能够创建单例实例，从而避免了竞态条件。
② 双重检查锁定 (Double-Checked Locking)：为了在保证线程安全的同时，尽可能提高性能，folly::Singleton 采用了双重检查锁定模式。这种模式的核心思想是在加锁之前和之后都进行实例是否已创建的检查。
▮▮▮▮⚝ 第一次检查（无锁）：在进入 getInstance() 方法后，首先会进行一次无锁的检查，通过原子加载 initialized 标志来判断实例是否已经创建。如果已创建，则直接返回实例，无需加锁，这是快速路径，性能很高。
▮▮▮▮⚝ 第二次检查（加锁后）：如果第一次检查发现实例尚未创建，则获取互斥锁。在获取锁之后，必须再次检查 initialized 标志。这是因为在等待锁的过程中，可能已经有其他线程先一步完成了实例创建。如果再次检查发现实例已创建，则直接返回已存在的实例，避免重复创建。
1
双重检查锁定模式有效地减少了锁的竞争范围，只有在首次创建实例时才需要加锁，后续的 `getInstance()` 调用都可以走快速路径，从而提高了并发性能。
③ 原子操作 (Atomic Operations)：folly::Singleton 使用原子操作来管理初始化标志 initialized。原子操作具有不可分割性，能够保证在多线程环境下对共享变量的读写操作是原子性的，不会被其他线程中断。
▮▮▮▮⚝ std::atomic<bool> initialized：将 initialized 声明为原子布尔类型，确保对 initialized 的读取和写入操作都是原子性的。
▮▮▮▮⚝ initialized.load(std::memory_order_relaxed)：在快速路径和双重检查中，使用 std::memory_order_relaxed 原子加载 initialized 的值。std::memory_order_relaxed 是一种宽松的内存顺序，只保证原子性，不保证顺序性，适用于对顺序性要求不高的场景，可以进一步提高性能。
▮▮▮▮⚝ initialized.store(true, std::memory_order_release)：在实例创建完成后，使用 std::memory_order_release 原子存储 true 到 initialized。std::memory_order_release 是一种释放语义，保证在该操作之前的所有写操作都对其他线程可见。
④ 内存屏障 (Memory Barrier) 的隐式应用：虽然代码中没有显式地使用内存屏障指令，但 std::mutex 的加锁和解锁操作，以及 std::atomic 的原子操作，都隐含地包含了内存屏障的作用。内存屏障可以强制 CPU 按照一定的顺序执行指令，防止指令重排序，确保在多线程环境下，内存操作的顺序符合预期，从而保证线程安全。
代码示例 (线程安全的关键部分)：
1
namespace folly {
2
namespace detail {
3
// ... SingletonStorage 定义 ...
4
} // namespace detail
5
6
template <typename T>
7
class Singleton {
8
public:
9
static T* getInstance() {
10
if (!detail::SingletonStorage<T>::initialized.load(std::memory_order_relaxed)) { // 第一次检查 (无锁)
11
std::lock_guard<std::mutex> lock(detail::SingletonStorage<T>::mutex); // 获取互斥锁
12
if (!detail::SingletonStorage<T>::initialized.load(std::memory_order_relaxed)) { // 第二次检查 (加锁后)
13
detail::SingletonStorage<T>::instance = new T(); // 创建实例
14
detail::SingletonStorage<T>::initialized.store(true, std::memory_order_release); // 设置初始化标志 (原子操作)
15
}
16
}
17
return detail::SingletonStorage<T>::instance;
18
}
19
// ...
20
};
21
} // namespace folly
总结：
folly::Singleton.h 的线程安全机制是多方面协同作用的结果。互斥锁保证了实例创建的互斥性，双重检查锁定优化了性能，原子操作保证了初始化标志的原子性访问，内存屏障（隐式）保证了内存操作的顺序性。这些机制共同确保了 folly::Singleton 在多线程环境下能够安全可靠地工作，为开发者提供了线程安全的单例模式实现。值得注意的是，双重检查锁定模式在早期的 C++ 标准中存在一些潜在的内存模型问题，但在 C++11 及以后的标准中，结合原子操作和内存顺序，已经可以安全地使用。folly::Singleton.h 的实现是基于现代 C++ 标准的，充分考虑了线程安全和性能的平衡。
8.3 初始化与销毁流程分析 (Analysis of Initialization and Destruction Process)
folly::Singleton.h 的初始化和销毁流程是单例模式生命周期管理的关键环节。理解这些流程有助于我们更好地掌握 folly::Singleton 的使用，并避免潜在的资源泄漏或程序错误。
初始化流程：
folly::Singleton 采用延迟初始化 (Lazy Initialization) 策略。这意味着单例实例不会在程序启动时立即创建，而是在第一次通过 getInstance() 方法访问时才进行初始化。其初始化流程主要包括以下步骤：
① 首次调用 getInstance()：当程序首次调用 folly::Singleton<T>::getInstance() 方法时，会进入初始化流程。
② 检查初始化标志：getInstance() 方法首先会检查内部的原子初始化标志 initialized。如果 initialized 为 false，表示实例尚未创建，需要进行初始化。
③ 获取互斥锁：为了保证线程安全，getInstance() 方法会尝试获取互斥锁。如果当前有其他线程正在进行初始化，则当前线程会被阻塞，直到获取到锁。
④ 再次检查初始化标志 (双重检查)：在获取锁之后，getInstance() 方法会再次检查 initialized 标志。这是双重检查锁定的一部分，防止在等待锁的过程中，其他线程已经完成了初始化。
⑤ 创建单例实例：如果再次检查 initialized 仍然为 false，则使用 new T() 在堆上动态分配内存，并构造 T 类型的实例。实例的指针会被存储在静态成员变量 instance 中。
⑥ 设置初始化标志：实例创建完成后，getInstance() 方法会将 initialized 原子标志设置为 true，表示实例已成功初始化。
⑦ 释放互斥锁：初始化完成后，getInstance() 方法会释放互斥锁，允许其他等待的线程继续执行。
⑧ 返回单例实例：getInstance() 方法返回指向已创建单例实例的指针。
后续调用 getInstance()：在单例实例被成功初始化之后，后续对 getInstance() 的调用将直接走快速路径：
① 调用 getInstance()：程序再次调用 folly::Singleton<T>::getInstance() 方法。
② 检查初始化标志：getInstance() 方法检查 initialized 原子标志。由于实例已经初始化，initialized 为 true。
③ 直接返回单例实例：getInstance() 方法直接返回存储在 instance 中的单例实例指针，无需加锁和创建实例，性能高效。
销毁流程：
folly::Singleton 的销毁流程相对简单，但也需要注意一些细节。默认情况下，folly::Singleton 管理的单例实例会在程序退出时被自动销毁。其销毁流程主要包括：
① 程序退出：当程序正常退出时，静态对象的析构函数会被调用。
② folly::Singleton 析构 (隐式)：folly::Singleton<T> 本身通常没有显式的析构函数需要执行，因为其主要职责是管理单例实例的生命周期，而不是自身持有资源。
③ 单例实例析构：存储在 instance 中的单例实例指针所指向的对象（类型为 T 的实例）的析构函数会被调用。这是单例对象资源释放的关键步骤。
④ 释放内存：单例实例所占用的堆内存会被释放。
reset() 方法：显式销毁与重置
folly::Singleton.h 提供了 reset() 方法，允许用户显式地销毁单例实例并重置 folly::Singleton 的状态。reset() 方法的流程如下：
① 调用 reset()：程序调用 folly::Singleton<T>::reset() 方法。
② 获取互斥锁：reset() 方法会获取互斥锁，确保在重置过程中没有其他线程同时访问单例实例。
③ 检查实例是否已创建：reset() 方法会检查 isInstanceCreated() 方法的返回值，判断实例是否已经被创建。
④ 销毁单例实例：如果实例已创建，reset() 方法会执行以下操作：
▮▮▮▮⚝ 调用单例实例的析构函数 (delete detail::SingletonStorage<T>::instance;)。
▮▮▮▮⚝ 将 detail::SingletonStorage<T>::instance 指针设置为 nullptr。
▮▮▮▮⚝ 将 detail::SingletonStorage<T>::initialized 原子标志设置为 false，表示实例已被销毁，需要重新初始化。
⑤ 释放互斥锁：reset() 方法释放互斥锁。
⑥ 重置完成：folly::Singleton 的状态被重置，下次调用 getInstance() 将会重新创建单例实例。
isInstanceCreated() 方法：检查实例状态
folly::Singleton.h 还提供了 isInstanceCreated() 方法，用于检查单例实例是否已经被创建。这个方法非常简单，它只是原子地读取 initialized 标志的值并返回。isInstanceCreated() 方法是线程安全的，可以用于在多线程环境下安全地判断单例实例的状态。
总结：
folly::Singleton.h 的初始化流程采用延迟初始化，在首次访问时创建实例，并通过互斥锁、双重检查锁定和原子操作保证线程安全。销毁流程默认在程序退出时自动进行，也可以通过 reset() 方法显式地销毁和重置。isInstanceCreated() 方法提供了检查实例状态的手段。理解这些流程有助于我们正确地使用 folly::Singleton，并根据实际需求进行生命周期管理。需要注意的是，对于某些资源管理型的单例，例如文件句柄、网络连接等，可能需要在程序退出前显式地调用 reset() 方法来释放资源，避免资源泄漏。
8.4 LeakySingleton 的特殊实现 (Special Implementation of LeakySingleton)
folly::Singleton.h 除了提供标准的 Singleton<T> 之外，还提供了一个变体 LeakySingleton<T>。LeakySingleton 的“泄漏 (Leaky)” 之名源于其特殊的生命周期管理方式：它创建的单例实例永远不会被销毁，即所谓的“内存泄漏 (Memory Leak)”。 然而，这里的“泄漏”是有意为之的设计，并非真正的程序错误。
LeakySingleton 的特性：
① 永不销毁 (Never Destroyed)：LeakySingleton 创建的单例实例在程序运行期间始终存在，不会被自动销毁，也不会响应 reset() 方法的调用。这意味着单例实例的析构函数永远不会被执行，实例所占用的内存也不会被释放，直到程序进程结束。
② 更快的初始化速度：由于 LeakySingleton 不需要考虑销毁和资源释放的问题，其初始化过程可以更加简化，通常会比 Singleton<T> 更快。在某些对性能要求极高的场景下，这种微小的性能提升也可能具有意义。
③ 适用于特定场景：LeakySingleton 并非适用于所有单例场景。它主要适用于以下几种情况：
▮▮▮▮⚝ 程序生命周期内始终存在的全局对象：例如，全局配置管理器、日志系统等，这些对象在整个程序运行期间都需要存在，并且在程序退出时销毁与否对程序行为没有实质性影响。
▮▮▮▮⚝ 避免静态析构顺序问题：C++ 静态对象的析构顺序是未定义的，可能会导致一些难以调试的问题。LeakySingleton 由于不执行析构，可以避免这类问题。
▮▮▮▮⚝ 性能敏感型场景：在某些极端性能敏感的场景下，为了极致的性能优化，可以牺牲单例对象的销毁，使用 LeakySingleton 来减少初始化开销。
LeakySingleton 的实现原理：
LeakySingleton 的实现原理与 Singleton<T> 类似，但简化了销毁相关的逻辑。其核心区别在于：
⚝ 没有析构和 reset() 方法：LeakySingleton 不提供 reset() 方法，并且其内部实现也不会在程序退出时尝试销毁单例实例。
⚝ 更简单的初始化流程：由于不需要考虑销毁，LeakySingleton 的初始化流程可以更加精简，例如可能省略某些同步机制，或者采用更轻量级的同步方式。
代码示例 (Conceptual LeakySingleton):
以下是一个高度简化的、概念性的 LeakySingleton 代码示例，同样，这并非 folly 库的真实源码，仅用于说明原理：
1
namespace folly {
2
namespace detail {
3
4
template <typename T>
5
struct LeakySingletonStorage {
6
static T* instance;
7
static std::once_flag onceFlag; // 使用 std::call_once 保证只初始化一次
8
};
9
10
template <typename T> T* LeakySingletonStorage<T>::instance = nullptr;
11
template <typename T> std::once_flag LeakySingletonStorage<T>::onceFlag;
12
13
} // namespace detail
14
15
template <typename T>
16
class LeakySingleton {
17
public:
18
static T* getInstance() {
19
std::call_once(detail::LeakySingletonStorage<T>::onceFlag, []{ // 保证只初始化一次
20
detail::LeakySingletonStorage<T>::instance = new T();
21
});
22
return detail::LeakySingletonStorage<T>::instance;
23
}
24
25
private:
26
LeakySingleton() = default;
27
LeakySingleton(const LeakySingleton&) = delete;
28
LeakySingleton& operator=(const LeakySingleton&) = delete;
29
};
30
31
} // namespace folly
代码解释：
⚝ detail::LeakySingletonStorage<T> 结构体：
▮▮▮▮⚝ instance：静态实例指针，与 Singleton 相同。
▮▮▮▮⚝ onceFlag：std::once_flag 对象，用于 std::call_once，保证初始化代码只执行一次，线程安全。
⚝ folly::LeakySingleton<T> 类：
▮▮▮▮⚝ getInstance() 方法：
▮▮▮▮▮▮▮▮⚝ 使用 std::call_once 和 lambda 表达式，确保初始化代码 detail::LeakySingletonStorage<T>::instance = new T(); 只会被执行一次，即使在多线程环境下。
▮▮▮▮▮▮▮▮⚝ std::call_once 内部会进行线程同步，保证线程安全。
▮▮▮▮▮▮▮▮⚝ 直接返回 instance，无需额外的检查和锁操作。
与 Singleton 的对比：
| 特性 | Singleton<T> | LeakySingleton<T> |
|---|---|---|
| 销毁 | 程序退出时自动销毁，可显式 reset() 销毁 | 永不销毁 |
| 内存泄漏 | 无 | 有意为之的“泄漏”，程序退出时操作系统回收内存 |
| 初始化速度 | 相对较慢 (需要考虑销毁和同步) | 相对较快 (简化初始化流程) |
| 适用场景 | 通用单例场景，需要生命周期管理 | 全局对象、避免静态析构顺序问题、性能敏感场景 |
| 线程安全 | 线程安全 | 线程安全 |
reset() 方法 | 提供 | 不提供 |
总结：
LeakySingleton 是 folly::Singleton.h 提供的一个特殊变体，它以“内存泄漏”为代价，换取更快的初始化速度和更简单的生命周期管理。LeakySingleton 适用于特定的单例场景，例如程序生命周期内始终存在的全局对象，或者对性能有极致要求的场景。开发者需要根据实际需求权衡利弊，选择合适的单例类型。在大多数情况下，标准的 Singleton<T> 仍然是更安全和更通用的选择，而 LeakySingleton 则作为一种特殊的优化手段，在特定场景下发挥作用。
8.5 与其他 Singleton 实现方式的对比 (Comparison with Other Singleton Implementation Methods)
folly::Singleton.h 并非 C++ 中唯一的单例模式实现方式。在标准 C++ 和其他库中，也存在多种单例模式的实现方法。本节将 folly::Singleton.h 与几种常见的单例实现方式进行对比，分析其优缺点，帮助读者更好地理解 folly::Singleton.h 的特点和适用场景。
① 经典 Singleton (Meyers Singleton)
Meyers Singleton 是 C++ 中最经典的单例模式实现方式之一，它利用 C++11 引入的静态局部变量的线程安全初始化特性来实现单例。
1
class ClassicSingleton {
2
public:
3
static ClassicSingleton& getInstance() {
4
static ClassicSingleton instance; // 静态局部变量，C++11 保证线程安全初始化
5
return instance;
6
}
7
8
private:
9
ClassicSingleton() = default;
10
ClassicSingleton(const ClassicSingleton&) = delete;
11
ClassicSingleton& operator=(const ClassicSingleton&) = delete;
12
};
优点：
⚝ 简洁易懂：代码非常简洁，易于理解和实现。
⚝ 线程安全：C++11 标准保证静态局部变量的初始化是线程安全的，无需显式加锁。
⚝ 延迟初始化：实例在首次调用 getInstance() 时才会被创建。
缺点：
⚝ 无法显式销毁：Meyers Singleton 创建的实例在程序退出时才会被销毁，无法显式地控制销毁时机，不方便资源管理。
⚝ 灵活性较差：初始化方式固定，无法自定义初始化函数。
⚝ 测试性较差：难以进行单元测试，因为无法方便地 Mock 或替换单例实例。
与 folly::Singleton 的对比：
⚝ folly::Singleton 提供了更灵活的生命周期管理，可以通过 reset() 方法显式销毁和重置，更方便资源管理和单元测试。
⚝ folly::Singleton 支持自定义初始化函数，可以更灵活地配置单例实例。
⚝ Meyers Singleton 代码更简洁，但在灵活性和可控性方面不如 folly::Singleton。
② 静态成员变量 Singleton
静态成员变量 Singleton 是另一种常见的实现方式，它将单例实例作为类的静态成员变量来存储。
1
class StaticMemberSingleton {
2
public:
3
static StaticMemberSingleton& getInstance() {
4
return instance_;
5
}
6
7
private:
8
StaticMemberSingleton() = default;
9
StaticMemberSingleton(const StaticMemberSingleton&) = delete;
10
StaticMemberSingleton& operator=(const StaticMemberSingleton&) = delete;
11
12
static StaticMemberSingleton instance_; // 静态成员变量
13
};
14
15
StaticMemberSingleton StaticMemberSingleton::instance_; // 静态成员变量定义
优点：
⚝ 简单直接：实现方式非常直接，易于理解。
缺点：
⚝ 非延迟初始化：实例在程序启动时就会被创建，即使可能永远不会被使用，造成资源浪费。
⚝ 线程安全问题：在多线程环境下，静态成员变量的初始化可能存在线程安全问题，需要手动添加互斥锁来保证线程安全。
⚝ 与 Meyers Singleton 类似的缺点：无法显式销毁，灵活性较差，测试性较差。
与 folly::Singleton 的对比：
⚝ folly::Singleton 采用延迟初始化，避免了静态成员变量 Singleton 的非延迟初始化问题，更节省资源。
⚝ folly::Singleton 内置线程安全机制，无需手动添加锁，使用更方便。
⚝ folly::Singleton 在生命周期管理、灵活性和测试性方面都优于静态成员变量 Singleton。
③ 基于 std::call_once 的 Singleton
基于 std::call_once 的 Singleton 利用 C++11 提供的 std::call_once 和 std::once_flag 来保证初始化代码只执行一次，实现线程安全的延迟初始化。
1
#include <mutex>
2
3
class CallOnceSingleton {
4
public:
5
static CallOnceSingleton& getInstance() {
6
static CallOnceSingleton* instance = nullptr;
7
std::call_once(onceFlag_, []() { // 使用 std::call_once 保证只初始化一次
8
instance = new CallOnceSingleton();
9
});
10
return *instance;
11
}
12
13
private:
14
CallOnceSingleton() = default;
15
CallOnceSingleton(const CallOnceSingleton&) = delete;
16
CallOnceSingleton& operator=(const CallOnceSingleton&) = delete;
17
18
static std::once_flag onceFlag_;
19
};
20
21
std::once_flag CallOnceSingleton::onceFlag_;
优点：
⚝ 线程安全：std::call_once 保证初始化代码只执行一次，线程安全。
⚝ 延迟初始化：实例在首次调用 getInstance() 时才会被创建。
缺点：
⚝ 需要手动管理内存：需要使用 new 和 delete 手动管理单例实例的内存，容易出错。
⚝ 与 Meyers Singleton 类似的缺点：无法显式销毁，灵活性较差，测试性较差。
与 folly::Singleton 的对比：
⚝ folly::Singleton 内部也可能使用类似的机制（例如 std::call_once 或更高效的 folly 自研同步原语）来实现线程安全的延迟初始化，但封装得更好，用户无需手动管理内存。
⚝ folly::Singleton 提供了 reset() 方法，支持显式销毁和重置，生命周期管理更灵活。
⚝ folly::Singleton 在易用性和功能性方面都优于基于 std::call_once 的 Singleton。
④ 其他库的 Singleton 实现
除了 folly::Singleton.h，其他一些 C++ 库也提供了单例模式的实现，例如 Boost.Singleton。这些实现通常也具有线程安全、延迟初始化等特性，并可能提供一些额外的功能，例如不同的生命周期管理策略、更丰富的配置选项等。
folly::Singleton 的优势总结：
⚝ 线程安全且高效：采用互斥锁、双重检查锁定、原子操作等机制，保证线程安全的同时，尽可能提高性能。
⚝ 延迟初始化：实例在首次使用时才创建，节省资源。
⚝ 灵活的生命周期管理：提供 reset() 方法，支持显式销毁和重置，方便资源管理和单元测试。
⚝ 支持自定义初始化：允许用户自定义初始化函数，更灵活地配置单例实例。
⚝ LeakySingleton 变体：提供 LeakySingleton 变体，适用于特定场景，例如全局对象、性能敏感型场景。
⚝ 现代 C++ 实现：基于现代 C++ 标准，代码简洁、高效、易于维护。
适用场景选择：
⚝ 通用单例场景：folly::Singleton<T> 是一个非常好的通用选择，它兼顾了线程安全、性能、灵活性和易用性。
⚝ 需要显式生命周期管理：如果需要显式地控制单例实例的销毁和重置，folly::Singleton<T> 的 reset() 方法非常有用。
⚝ 需要自定义初始化：如果需要自定义单例实例的初始化逻辑，folly::Singleton<T> 支持自定义初始化函数。
⚝ 全局对象、性能敏感场景：folly::LeakySingleton<T> 可以作为一种优化选择，但需要权衡内存泄漏的潜在影响。
⚝ 简单场景、代码简洁优先：Meyers Singleton 在代码简洁性方面有优势，但功能和灵活性较弱。
总结：
folly::Singleton.h 在众多 Singleton 实现方式中脱颖而出，它不仅提供了线程安全、延迟初始化等基本特性，还在生命周期管理、灵活性和性能优化方面做了很多工作。与其他实现方式相比，folly::Singleton.h 更加成熟、完善、易用，是现代 C++ 项目中单例模式实现的优秀选择。开发者可以根据具体的应用场景和需求，选择最合适的 Singleton 实现方式，而 folly::Singleton.h 通常是一个值得优先考虑的方案。
END_OF_CHAPTER
9. chapter 9： 总结与展望 (Summary and Outlook)
9.1 folly::Singleton.h 的优势与局限性总结 (Summary of Advantages and Limitations of folly::Singleton.h)
在本书的旅程即将结束之际，我们对 folly::Singleton.h 进行了全面的探索，从基础入门到高级应用，再到源码剖析，相信读者已经对 folly::Singleton.h 有了深入的理解。本节将对 folly::Singleton.h 的优势与局限性进行总结，以便读者在实际应用中能够扬长避短，更好地利用这一强大的工具。
优势 (Advantages):
① 线程安全 (Thread Safety)：folly::Singleton.h 的最大优势之一是其内置的线程安全性。它通过内部的 std::call_once 或类似的机制，确保在多线程环境下 Singleton 实例只被初始化一次，避免了传统 Singleton 实现中常见的竞态条件和初始化顺序问题。这极大地简化了多线程 Singleton 的实现，提高了程序的健壮性。
② 易用性 (Ease of Use)：folly::Singleton.h 提供了简洁明了的 API，通过 folly::Singleton<T>::getInstance() 即可轻松获取 Singleton 实例。其模板化的设计使得它可以应用于任何类型的 Singleton 类，无需编写大量的样板代码。
③ 灵活性 (Flexibility)：folly::Singleton.h 提供了多种初始化方式，包括默认初始化、自定义初始化函数、延迟初始化和提前初始化等，满足了不同场景下的需求。LeakySingleton 和 SingletonVoid 的引入进一步扩展了其应用范围，使其能够处理更特殊的情况。
④ 高效性 (Efficiency)：folly::Singleton.h 在保证线程安全的同时，也注重性能。其内部实现经过优化，getInstance() 的调用开销很小，不会成为性能瓶颈。
⑤ 与 folly 库的集成 (Integration with Folly Library)：作为 folly 库的一部分，folly::Singleton.h 可以与其他 folly 组件无缝集成，例如 folly::futures、folly::Executor 等，构建更加强大和高效的系统。
局限性 (Limitations):
① 全局状态 (Global State)：Singleton 模式本身固有的局限性在于引入了全局状态。过度使用 Singleton 可能导致程序各个模块之间耦合度过高，降低代码的可测试性和可维护性。folly::Singleton.h 并没有消除 Singleton 模式的这一根本局限性，因此在使用时仍需谨慎，避免滥用。
② 生命周期管理 (Lifecycle Management)：虽然 folly::Singleton.h 提供了 reset() 方法来重置 Singleton 实例，但在复杂的应用场景中，Singleton 的生命周期管理仍然可能是一个挑战。特别是对于需要精细控制资源释放的场景，可能需要仔细考虑 Singleton 的销毁时机。
③ 依赖 folly 库 (Dependency on Folly Library)：使用 folly::Singleton.h 需要引入 folly 库。对于一些小型项目或者对库依赖有严格要求的项目，引入整个 folly 库可能会显得过于重量级。虽然 folly 库本身非常优秀，但在选择使用 folly::Singleton.h 时，需要权衡引入依赖的成本。
④ Mocking 困难 (Mocking Difficulty)：Singleton 模式通常被认为不利于单元测试，因为 Singleton 实例的全局唯一性使得 Mocking 和替换变得困难。虽然本书介绍了在单元测试中 Mocking Singleton 的一些技巧，但这仍然比 Mocking 普通类要复杂一些。
总结 (Summary):
folly::Singleton.h 是一个强大而实用的 Singleton 模式实现，它在线程安全、易用性、灵活性和效率等方面都表现出色。然而，它也无法完全克服 Singleton 模式固有的局限性。在实际应用中，我们需要根据具体场景权衡其优缺点，合理使用 folly::Singleton.h，避免滥用，并结合其他设计模式和技术，构建更加健壮、可维护和可测试的系统。
9.2 C++ 新标准与 Singleton 模式的未来发展 (Future Development of C++ New Standards and Singleton Pattern)
随着 C++ 标准的不断演进，新的语言特性和库的引入，对包括 Singleton 模式在内的设计模式都产生了深远的影响。本节将探讨 C++ 新标准对 Singleton 模式的未来发展可能带来的影响。
① C++11 及更高版本的语言特性 (Language Features in C++11 and Later)：
⚝ std::call_once 和 std::once_flag: C++11 引入的 std::call_once 和 std::once_flag 为线程安全的延迟初始化提供了标准化的解决方案，这也是 folly::Singleton.h 线程安全性的基石。未来，随着 C++ 标准的普及，开发者可以更加方便地利用这些语言特性来实现线程安全的 Singleton，而无需依赖第三方库。
⚝ 静态局部变量的线程安全初始化 (Thread-safe Initialization of Static Local Variables)：C++11 保证了静态局部变量的初始化是线程安全的。这使得 Meyers Singleton 这种简洁的实现方式在多线程环境下也能正确工作，降低了 Singleton 实现的复杂性。
⚝ constexpr 和 consteval: C++11 引入的 constexpr 和 C++20 引入的 consteval 允许在编译时进行更多的计算。在 Singleton 模式中，如果 Singleton 实例的初始化可以在编译时完成，那么可以进一步提高程序的性能和效率。
② 模块化 (Modules)：
C++20 引入的模块化 (Modules) 特性旨在解决头文件包含和编译效率等问题。模块化可能会影响 Singleton 的实现和使用方式。例如，通过模块可以更好地控制 Singleton 的可见性和作用域，减少全局命名空间污染。
③ 反射 (Reflection)：
C++ 的反射机制虽然仍在发展中，但一旦成熟，可能会对 Singleton 模式产生重大影响。反射可以使得 Singleton 的创建和管理更加自动化和灵活。例如，可以通过反射来动态地注册和获取 Singleton 实例，实现更加解耦和可扩展的系统。
④ 并发编程库 (Concurrency Libraries)：
C++ 标准库不断完善并发编程相关的库，例如 std::thread、std::mutex、std::atomic、std::future 等。这些库为构建高性能、高并发的系统提供了强大的工具。folly::Singleton.h 本身也受益于这些标准库的特性。未来，随着并发编程库的进一步发展，可能会涌现出更加高效、灵活和易用的 Singleton 实现方式。
⑤ 设计模式的演进 (Evolution of Design Patterns)：
随着软件开发理念和技术的不断发展，设计模式也在不断演进。Singleton 模式作为经典的设计模式之一，其应用场景和最佳实践也在不断被重新审视和调整。例如，依赖注入、服务定位器等模式的兴起，为解决 Singleton 模式的一些局限性提供了新的思路。未来，Singleton 模式可能会与其他设计模式更好地结合，或者被更现代的设计模式所替代。
总结 (Summary):
C++ 新标准为 Singleton 模式的实现和应用带来了新的机遇和挑战。新的语言特性和库的引入，使得开发者可以更加方便、高效地实现线程安全的 Singleton，并解决 Singleton 模式的一些传统问题。同时，我们也需要关注设计模式的演进趋势，不断学习和探索更加现代、更加优秀的软件设计方法。
9.3 结语：成为 folly::Singleton.h 专家之路 (Conclusion: The Road to Becoming an Expert in folly::Singleton.h)
恭喜您完成了本书的学习！相信通过本书的系统学习，您已经对 folly::Singleton.h 有了全面而深入的理解，从 Singleton 模式的基本概念，到 folly::Singleton.h 的高级应用和源码剖析，再到 Singleton 模式的替代方案和最佳实践，我们都进行了详细的讲解和探讨。
成为 folly::Singleton.h 专家之路并非一蹴而就，需要不断地学习、实践和积累经验。以下是一些建议，希望能帮助您更进一步：
① 深入理解 Singleton 模式的本质 (Understand the Essence of Singleton Pattern)：
不仅仅停留在 folly::Singleton.h 的 API 使用上，更要深入理解 Singleton 模式的设计思想、应用场景、优缺点以及替代方案。只有真正理解了 Singleton 模式的本质，才能在实际应用中做出明智的选择。
② 多实践，多应用 (Practice and Apply Frequently)：
理论学习固然重要，但实践才是检验真理的唯一标准。尝试在实际项目中应用 folly::Singleton.h，解决实际问题，积累实践经验。可以通过编写示例代码、参与开源项目、或者在工作中尝试使用 folly::Singleton.h。
③ 阅读 folly 库源码 (Read Folly Library Source Code)：
folly::Singleton.h 的源码是学习其实现原理的最佳资料。通过阅读源码，可以深入了解其内部结构、线程安全机制、初始化和销毁流程等细节，从而更好地理解和使用 folly::Singleton.h。同时，阅读 folly 库的其他组件源码，也可以学习到更多优秀的 C++ 编程技巧和设计思想。
④ 关注 C++ 标准和 folly 库的更新 (Follow C++ Standards and Folly Library Updates)：
C++ 标准和 folly 库都在不断发展和更新。关注最新的 C++ 标准，了解新的语言特性和库，可以帮助您更好地理解 Singleton 模式的未来发展趋势。同时，关注 folly 库的更新，可以及时了解 folly::Singleton.h 的新功能、改进和最佳实践。
⑤ 参与社区交流 (Participate in Community Discussions)：
积极参与 C++ 和 folly 相关的技术社区，与其他开发者交流学习心得、分享实践经验、讨论技术问题。通过社区交流，可以拓宽视野，获取更多的学习资源和帮助。
寄语 (Words of Encouragement):
学习 folly::Singleton.h 的过程，也是提升 C++ 编程技能和软件设计能力的过程。希望本书能够成为您学习 folly::Singleton.h 的良好起点。相信通过不断地学习和实践，您一定能够成为 folly::Singleton.h 的专家，并在未来的软件开发工作中取得更大的成就！
祝您学习愉快，编程进步！
附录 A： folly 库的安装与配置 (Installation and Configuration of Folly Library)
folly (Facebook Open Source Library) 是一个由 Facebook 开源的高性能 C++ 库，folly::Singleton.h 是 folly 库中的一个组件。本附录将指导您如何在常见的开发环境中安装和配置 folly 库。
环境准备 (Environment Preparation):
在开始安装 folly 之前，请确保您的系统满足以下基本要求：
⚝ 操作系统 (Operating System)：Linux (推荐，如 Ubuntu, CentOS, Debian)、macOS。 Windows 系统支持有限，建议使用 Linux 或 macOS 环境进行开发。
⚝ C++ 编译器 (C++ Compiler)：GCC (>= 5.0), Clang (>= 3.8)。 推荐使用较新版本的编译器以获得更好的 C++14/C++17 支持。
⚝ CMake (>= 3.0)：用于构建 folly 库。
⚝ Python (>= 2.7 or >= 3.5)：CMake 构建过程需要 Python。
⚝ 其他依赖库 (Dependencies)：folly 依赖于一些其他的开源库，例如 Boost, OpenSSL, zlib, glog, gflags, libevent, double-conversion, fmt 等。 folly 的构建脚本会自动处理大部分依赖库的安装。
安装步骤 (Installation Steps):
以下是在 Ubuntu 系统上安装 folly 库的步骤示例。其他 Linux 发行版和 macOS 系统的安装步骤类似，可能需要根据具体情况进行调整。
Step 1: 克隆 folly 仓库 (Clone Folly Repository)
使用 Git 克隆 folly 的 GitHub 仓库：
1
git clone https://github.com/facebook/folly.git
2
cd folly
Step 2: 安装依赖 (Install Dependencies)
folly 提供了一个脚本 build/bootstrap.py 来帮助安装大部分依赖库。运行该脚本：
1
./build/bootstrap.py
该脚本会自动检测您的系统环境，并尝试安装所需的依赖库。如果遇到依赖安装问题，可能需要手动安装缺失的库。例如，在 Ubuntu 系统上，可以使用 apt-get 命令安装常见的依赖库：
1
sudo apt-get update
2
sudo apt-get install libboost-dev libevent-dev libssl-dev zlib1g-dev libgflags-dev libgoogle-glog-dev libdouble-conversion-dev libfmt-dev libiberty-dev liblz4-dev libsodium-dev
Step 3: 使用 CMake 构建 (Build with CMake)
在 folly 仓库根目录下创建 build 目录，并进入该目录：
1
mkdir build
2
cd build
使用 CMake 配置构建：
1
cmake ..
如果需要指定安装路径，可以使用 -DCMAKE_INSTALL_PREFIX 选项：
1
cmake -DCMAKE_INSTALL_PREFIX=/usr/local ..
开始编译 folly 库：
1
make -j$(nproc) # 使用多核加速编译
安装 folly 库到指定目录 (如果使用了 -DCMAKE_INSTALL_PREFIX 选项，则安装到指定目录，否则安装到系统默认目录，如 /usr/local):
1
sudo make install
Step 4: 验证安装 (Verify Installation)
编译完成后，可以编写一个简单的程序来验证 folly 库是否安装成功。创建一个名为 test_folly.cpp 的文件，内容如下：
1
#include <folly/Singleton.h>
2
#include <iostream>
3
4
class MySingleton {
5
public:
6
static MySingleton* getInstance() {
7
return folly::Singleton<MySingleton>::getInstance();
8
}
9
10
void hello() {
11
std::cout << "Hello from MySingleton!" << std::endl;
12
}
13
14
private:
15
MySingleton() = default;
16
~MySingleton() = default;
17
MySingleton(const MySingleton&) = delete;
18
MySingleton& operator=(const MySingleton&) = delete;
19
};
20
21
int main() {
22
MySingleton::getInstance()->hello();
23
return 0;
24
}
使用 g++ 编译该程序，并链接 folly 库：
1
g++ test_folly.cpp -o test_folly -lfolly -lfolly_json -lfolly_test -lboost_system -lboost_filesystem -lssl -lcrypto -lz -lglog -lgflags -levent -ldouble-conversion -lfmt -pthread
运行编译生成的可执行文件：
1
./test_folly
如果程序成功输出 "Hello from MySingleton!"，则说明 folly 库安装配置成功。
注意事项 (Precautions):
⚝ 编译选项 (Compilation Options)：编译链接 folly 库时，需要根据实际情况添加正确的编译选项和链接库。CMake 生成的 CMakeFiles/folly.dir/flags.make 文件中包含了编译 folly 库所需的编译选项，可以参考该文件。
⚝ 依赖冲突 (Dependency Conflicts)：folly 依赖的某些库可能与系统中已安装的库版本冲突。如果遇到依赖冲突问题，可能需要手动解决，例如升级或降级某些库的版本，或者使用虚拟环境隔离不同版本的库。
⚝ Windows 系统 (Windows System)：在 Windows 系统上安装 folly 库相对复杂，可能需要使用 vcpkg 或其他包管理器来安装依赖库，并使用 Visual Studio 进行编译。建议参考 folly 仓库的官方文档或社区资源，获取 Windows 系统上的安装指导。
附录 B： 常用 Singleton 实现代码示例 (Code Examples of Common Singleton Implementations)
本附录将提供几种常见的 Singleton 模式实现的代码示例，以便读者对比学习，更好地理解 folly::Singleton.h 的优势和特点。
1. 饿汉式 Singleton (Eager Initialization Singleton)
饿汉式 Singleton 在类加载时就完成了 Singleton 实例的初始化，因此是线程安全的。
1
class EagerSingleton {
2
public:
3
static EagerSingleton* getInstance() {
4
return instance;
5
}
6
7
void hello() {
8
std::cout << "Hello from EagerSingleton!" << std::endl;
9
}
10
11
private:
12
EagerSingleton() {
13
std::cout << "EagerSingleton constructor called." << std::endl;
14
}
15
~EagerSingleton() = default;
16
EagerSingleton(const EagerSingleton&) = delete;
17
EagerSingleton& operator=(const EagerSingleton&) = delete;
18
19
static EagerSingleton* instance; // 静态成员变量
20
};
21
22
EagerSingleton* EagerSingleton::instance = new EagerSingleton(); // 在类外初始化静态成员变量
优点 (Advantages):
⚝ 线程安全：在类加载时完成初始化，天然线程安全。
⚝ 实现简单：代码简洁明了。
缺点 (Disadvantages):
⚝ 提前初始化：无论是否使用 Singleton 实例，都会在类加载时创建实例，可能造成资源浪费。
⚝ 无法延迟初始化：如果 Singleton 实例的初始化依赖于某些运行时参数，则饿汉式无法满足需求。
2. 懒汉式 Singleton (Lazy Initialization Singleton) - 线程不安全 (Thread-unsafe)
1
class LazySingletonUnsafe {
2
public:
3
static LazySingletonUnsafe* getInstance() {
4
if (instance == nullptr) { // 线程不安全
5
instance = new LazySingletonUnsafe();
6
}
7
return instance;
8
}
9
10
void hello() {
11
std::cout << "Hello from LazySingletonUnsafe!" << std::endl;
12
}
13
14
private:
15
LazySingletonUnsafe() {
16
std::cout << "LazySingletonUnsafe constructor called." << std::endl;
17
}
18
~LazySingletonUnsafe() = default;
19
LazySingletonUnsafe(const LazySingletonUnsafe&) = delete;
20
LazySingletonUnsafe& operator=(const LazySingletonUnsafe&) = delete;
21
22
static LazySingletonUnsafe* instance;
23
};
24
25
LazySingletonUnsafe* LazySingletonUnsafe::instance = nullptr; // 类外初始化静态成员变量
缺点 (Disadvantages):
⚝ 线程不安全：在多线程环境下，可能存在多个线程同时进入 if (instance == nullptr) 代码块，导致创建多个 Singleton 实例。
3. 懒汉式 Singleton - 加锁 (Lazy Initialization Singleton - with Lock)
通过互斥锁 (mutex) 保证线程安全。
1
#include <mutex>
2
3
class LazySingletonLock {
4
public:
5
static LazySingletonLock* getInstance() {
6
std::lock_guard<std::mutex> lock(mutex_); // 加锁
7
if (instance == nullptr) {
8
instance = new LazySingletonLock();
9
}
10
return instance;
11
}
12
13
void hello() {
14
std::cout << "Hello from LazySingletonLock!" << std::endl;
15
}
16
17
private:
18
LazySingletonLock() {
19
std::cout << "LazySingletonLock constructor called." << std::endl;
20
}
21
~LazySingletonLock() = default;
22
LazySingletonLock(const LazySingletonLock&) = delete;
23
LazySingletonLock& operator=(const LazySingletonLock&) = delete;
24
25
static LazySingletonLock* instance;
26
static std::mutex mutex_; // 互斥锁
27
};
28
29
LazySingletonLock* LazySingletonLock::instance = nullptr;
30
std::mutex LazySingletonLock::mutex_;
优点 (Advantages):
⚝ 线程安全：通过互斥锁保证线程安全。
⚝ 延迟初始化：在第一次调用 getInstance() 时才创建实例。
缺点 (Disadvantages):
⚝ 性能开销：每次调用 getInstance() 都会进行加锁和解锁操作，在高并发场景下可能存在性能瓶颈。
4. 双重检查锁定 (Double-Checked Locking) - C++11 之后不推荐
在 C++11 之前，双重检查锁定存在一些问题，例如指令重排可能导致线程不安全。C++11 之后，由于内存模型的改进，双重检查锁定在理论上是可行的，但实现较为复杂，且性能提升不明显，因此不推荐使用。
1
#include <mutex>
2
#include <atomic>
3
4
class DoubleCheckedLockingSingleton {
5
public:
6
static DoubleCheckedLockingSingleton* getInstance() {
7
if (instance_.load(std::memory_order_relaxed) == nullptr) { // 第一次检查，无锁
8
std::lock_guard<std::mutex> lock(mutex_); // 加锁
9
if (instance_.load(std::memory_order_relaxed) == nullptr) { // 第二次检查，防止多线程重复创建
10
instance_.store(new DoubleCheckedLockingSingleton(), std::memory_order_release);
11
}
12
}
13
return instance_.load(std::memory_order_acquire);
14
}
15
16
void hello() {
17
std::cout << "Hello from DoubleCheckedLockingSingleton!" << std::endl;
18
}
19
20
private:
21
DoubleCheckedLockingSingleton() {
22
std::cout << "DoubleCheckedLockingSingleton constructor called." << std::endl;
23
}
24
~DoubleCheckedLockingSingleton() = default;
25
DoubleCheckedLockingSingleton(const DoubleCheckedLockingSingleton&) = delete;
26
DoubleCheckedLockingSingleton& operator=(const DoubleCheckedLockingSingleton&) = delete;
27
28
static std::atomic<DoubleCheckedLockingSingleton*> instance_;
29
static std::mutex mutex_;
30
};
31
32
std::atomic<DoubleCheckedLockingSingleton*> DoubleCheckedLockingSingleton::instance_(nullptr);
33
std::mutex DoubleCheckedLockingSingleton::mutex_;
缺点 (Disadvantages):
⚝ 实现复杂：需要使用 std::atomic 和内存序 (memory order) 来保证线程安全，代码可读性较差。
⚝ 性能提升不明显：相对于加锁的懒汉式 Singleton，性能提升有限，但代码复杂度增加。
5. Meyers Singleton (Meyers Singleton)
利用 C++11 静态局部变量的线程安全初始化特性，实现简洁高效的 Singleton。
1
class MeyersSingleton {
2
public:
3
static MeyersSingleton& getInstance() {
4
static MeyersSingleton instance; // 静态局部变量，C++11 保证线程安全初始化
5
return instance;
6
}
7
8
void hello() {
9
std::cout << "Hello from MeyersSingleton!" << std::endl;
10
}
11
12
private:
13
MeyersSingleton() {
14
std::cout << "MeyersSingleton constructor called." << std::endl;
15
}
16
~MeyersSingleton() = default;
17
MeyersSingleton(const MeyersSingleton&) = delete;
18
MeyersSingleton& operator=(const MeyersSingleton&) = delete;
19
};
优点 (Advantages):
⚝ 线程安全：C++11 保证静态局部变量的线程安全初始化。
⚝ 简洁高效：代码简洁，性能高效，无需显式加锁。
⚝ 延迟初始化：在第一次调用 getInstance() 时才创建实例。
缺点 (Disadvantages):
⚝ 无法控制初始化顺序：静态局部变量的初始化顺序在多编译单元 (translation unit) 的情况下是未定义的。
总结 (Summary):
folly::Singleton.h 借鉴了 Meyers Singleton 的思想，并在此基础上进行了扩展和优化，提供了更加强大和灵活的 Singleton 实现。对比以上几种常见的 Singleton 实现方式，folly::Singleton.h 在线程安全、易用性、灵活性和性能等方面都具有明显的优势，是现代 C++ 开发中 Singleton 模式的推荐选择。
附录 C： 术语表 (Glossary)
本附录提供本书中涉及的一些重要术语的解释，帮助读者更好地理解相关概念。
⚝ API (Application Programming Interface) (应用程序编程接口)：一组定义、协议和工具，用于构建应用程序软件。API 规定了软件组件之间如何交互。在本书中，API 指的是 folly::Singleton.h 提供的接口函数和类。
⚝ 编译时 (Compile Time)：程序源代码被编译器转换成机器代码的阶段。编译时错误是指在编译阶段检测到的错误。
⚝ 并发 (Concurrency)：指程序中多个独立的执行单元 (例如线程、进程) 在一段时间内同时执行。并发并不一定意味着并行，并发可以通过时间片轮转等方式在单核处理器上模拟并行执行。
⚝ 控制反转 (Inversion of Control, IoC)：一种设计原则，用于解耦软件组件之间的依赖关系。控制反转的核心思想是将对象的控制权 (例如对象的创建、依赖注入) 从对象自身转移到外部容器或框架。
⚝ 数据竞争 (Data Race)：在多线程程序中，当多个线程同时访问同一块内存，并且至少有一个线程执行写操作，同时没有使用同步机制来保护数据访问时，就会发生数据竞争。数据竞争会导致程序行为不可预测。
⚝ 依赖注入 (Dependency Injection, DI)：一种实现控制反转的技术。依赖注入通过外部容器或框架将对象所依赖的其他对象 (依赖项) 注入到对象中，从而解耦对象之间的依赖关系。
⚝ 设计模式 (Design Pattern)：在软件设计中，针对特定问题的可重用的解决方案。设计模式是对在特定上下文中反复出现的常用解决方案的总结和抽象。Singleton 模式是设计模式中的一种创建型模式。
⚝ 延迟初始化 (Lazy Initialization)：也称为惰性初始化，指将对象的初始化操作延迟到真正需要使用该对象时才执行。延迟初始化可以提高程序的启动速度和资源利用率。
⚝ 多线程 (Multi-threading)：指在一个进程中创建多个线程，并发执行不同的任务。多线程可以提高程序的并发性和响应速度。
⚝ Mocking (模拟)：在单元测试中，使用 Mock 对象来替代真实的对象，以便隔离被测试代码的依赖，并验证被测试代码的行为。Mocking 常用于测试 Singleton 模式的类。
⚝ 命名空间污染 (Namespace Pollution)：当全局命名空间中定义了过多的名字 (例如变量、函数、类) 时，容易导致命名冲突，降低代码的可读性和可维护性。Singleton 模式有时会引入全局访问点，可能导致命名空间污染。
⚝ 并行 (Parallelism)：指程序中多个独立的执行单元在同一时刻同时执行。并行需要多核处理器或分布式系统等硬件支持。
⚝ 竞态条件 (Race Condition)：在多线程程序中，当程序的行为取决于多个线程执行的相对顺序时，就可能发生竞态条件。竞态条件会导致程序行为不可预测。
⚝ 运行时 (Runtime)：程序执行的阶段。运行时错误是指在程序运行过程中发生的错误，例如空指针访问、除零错误等。
⚝ 服务定位器 (Service Locator)：一种设计模式，用于集中管理和访问服务 (对象)。服务定位器模式类似于全局注册表，客户端可以通过服务定位器查找和获取所需的服务。服务定位器模式是 Singleton 模式的一种替代方案。
⚝ Singleton 模式 (Singleton Pattern) (单例模式)：一种创建型设计模式，确保一个类只有一个实例，并提供一个全局访问点来访问该实例。Singleton 模式常用于管理全局资源、配置信息等。
⚝ 线程安全 (Thread Safety)：指在多线程环境下，程序能够正确地处理共享数据，避免数据竞争和竞态条件，保证程序的行为符合预期。folly::Singleton.h 提供了线程安全的 Singleton 实现。
⚝ 单元测试 (Unit Testing)：一种软件测试方法，用于测试程序中的最小可测试单元 (例如函数、方法、类)。单元测试旨在验证代码的正确性和可靠性。
⚝ 值类型 (Value Type)：指其值直接存储在内存中的数据类型，例如基本数据类型 (int, float, bool) 和结构体 (struct)。值类型的赋值和拷贝操作会复制其值。
END_OF_CHAPTER