单例模式（巨通俗易懂）普通单例，懒汉单例的实现和区别，依赖注入......

单例模式：保证在整个程序中，某个类只有一个实例，并且可以全局可访问。

换句话说：

整个类只想要一个对象

全局都可以使用这个对象

不允许创建第二个对象

再比如：
程序的配置管理器（只需要一个）

日志系统（写日志的对象只有一个）

数据库连接池（共享同一个）

想用全局变量（虽然用单例模式也不太好）

懒汉单例（c++11后）

#include <iostream>
#include <mutex>class Singleton {
public:// 获取唯一实例的全局访问点static Singleton& getInstance() {static Singleton instance; // C++11保证线程安全return instance;}void doSomething() {std::cout << "我是唯一的实例，正在工作..." << std::endl;}private:// 构造函数私有，禁止外部 newSingleton() {std::cout << "单例对象创建成功！" << std::endl;}// 禁止拷贝和赋值Singleton(const Singleton&) = delete;Singleton& operator=(const Singleton&) = delete;
};int main() {// 获取唯一实例Singleton& s1 = Singleton::getInstance();Singleton& s2 = Singleton::getInstance();s1.doSomething();// 检查是否是同一个对象if (&s1 == &s2) {std::cout << "s1 和 s2 是同一个实例" << std::endl;}return 0;
}

结果：

单例对象创建成功！
我是唯一的实例，正在工作...
s1 和 s2 是同一个实例

懒汉单例 vs 饿汉单例

在 C++ 中，常见的单例实现分为两种：

懒汉单例的实现：

class LazySingleton {
public:static LazySingleton& getInstance() {static LazySingleton instance; // 第一次调用时创建return instance;}
private:LazySingleton() {}LazySingleton(const LazySingleton&) = delete;LazySingleton& operator=(const LazySingleton&) = delete;
};

只有第一次调用getInstance()才会创造对象

如果程序没有用到这个对象，就不会浪费资源

适合“可能用，也可能不用”的场景

饿汉单例的实现：

class EagerSingleton {
public:static EagerSingleton& getInstance() {return instance;}
private:EagerSingleton() {}static EagerSingleton instance;  // 程序启动时就创建
};EagerSingleton EagerSingleton::instance;  // 定义并初始化

程序一启动就会创造对象

初始化顺序再程序启动阶段完成

适合“肯定会用”的场景，比如日志系统，配置管理器

static EagerSingleton instance;  写在类外，会在程序启动时就创建

tips：

能用单例不用全局变量，能不用单例就不用单例

单例模式不仅仅是“全局变量”，它还带来更好的封装性、控制力和安全性。

那为什么能不用单例就不用单例

单例缺点：

1.单例的本质就是全局变量，说单例不好就是说全局变量不好。

全局状态会带来问题：

• 难以追踪谁修改了它

• 如果多人同时修改，可能出现不可预期的行为

• 线程安全变复杂

2.难以进行单元测试

举个例子，有一个 Database 单例：

Database& db = Database::getInstance();
db.connect("mysql://...");

问题来了：

• 如果我要写一个测试用例，让 Database 不连接真实的 MySQL，而是用一个假数据库（Mock Database），怎么办？

• 单例让“依赖注入”变得困难，因为你无法轻易替换内部对象。

如果是普通类，我们可以这样：

class MyService {
public:MyService(Database* db) : db_(db) {}   // 构造函数，传入数据库对象指针void work() { db_->query("SELECT 1"); } // 调用数据库执行查询
private:Database* db_;                         // 保存数据库对象指针
};

测试时：

MockDatabase mockDb;
MyService service(&mockDb);  // 传入假的db

如果用单例，就很难做到这一点 → 这就是很多书批评单例的原因。

3.生命周期难管理

单例通常使用静态变量，比如：

static Logger& getInstance() {static Logger instance;return instance;
}

这个对象会在程序退出时自动销毁，但如果在其他全局对象的析构函数中访问 Logger，可能会出现“对象已被销毁”的错误。

静态对象的销毁顺序

在 C++ 中，静态对象（static 对象）的生命周期是：

1. 程序运行到第一次使用它时创建（懒汉）或程序启动就创建（饿汉）

2. 程序退出时会自动销毁（调用析构函数）

例如：

class Logger {
public:Logger() { std::cout << "Logger创建\n"; }~Logger() { std::cout << "Logger销毁\n"; }void log(const std::string& msg) { std::cout << msg << std::endl; }
};int main() {static Logger logger;logger.log("Hello");return 0;
}

• logger 对象会在 main() 结束后自动销毁

• 析构函数 ~Logger() 会被调用

问题出现的场景

假设你还有另一个全局对象：

class GlobalObject {
public:~GlobalObject() {Logger::getInstance().log("GlobalObject析构");}
};GlobalObject g_obj;  // 全局对象

程序运行顺序：

1. main() 结束，静态对象开始销毁

2. 全局对象 g_obj 的析构函数先执行

3. 析构函数里调用 Logger::getInstance().log()

问题来了：

• 如果 Logger 是静态对象（比如懒汉单例的 static Logger instance;）

• 它的析构函数可能已经被调用（对象已销毁）

• 这时再调用 log() → 访问已销毁的对象 → 未定义行为 → 程序可能崩溃

在大型C++项目中，这个问题被称为 Static Initialization Order Fiasco（静态初始化顺序灾难）。
如果用普通类+依赖注入，可以更好地控制对象的生命周期。

4.隐式耦合，降低可维护性

单例是一种全局可见的状态，导致“想改一处，动全局”：

• 你在某个地方修改了单例的状态

• 另一个模块突然行为异常

• 你完全不知道问题出在哪

如果改用依赖注入（把需要的对象通过构造函数传递），模块之间的依赖会更明确。

不适合用单例

1. 数据缓存

   如果缓存只是某个功能模块使用，用类成员更好

2. 临时状态管理

   比如某个页面的UI状态，不需要全局唯一

3. 可扩展性要求高

   如果未来有一天可能需要多个实例，提前用单例会很难改

替代方案

如果能不用单例，常见的替代方案有：

(1) 依赖注入（Dependency Injection）

不要在类内部自己创建或固定依赖，把依赖从外部传进来。

拿刚刚的数据库举例子来说，"mysql://..." 写在代码里就是 硬编码，你要测试改数据库就必须改那段源码。

class Logger {
public:void log(const std::string& msg); //用来打印或记录日志
};class Service {
public:Service(Logger* logger) : logger_(logger) {} // 把传进来的 logger 参数 赋值给类成员变量 logger_void run() { logger_->log("running"); }  // 成员函数
private:Logger* logger_;   //成员变量
};int main() {Logger logger; //创建一个Logger对象Service service(&logger);  // 明确注入依赖，把logger的地址传进去，service就可以使用这个loggerservice.run(); // Service调用Logger的log()方法
}

Service 类解析

1. 成员变量 Logger* logger_

   • 指向一个 Logger 对象的指针

   • 用来在 Service 内部调用 Logger 的功能

2. 构造函数 Service(Logger* logger)

   • 接收一个 Logger 对象指针作为参数

   • 初始化成员变量 logger_

   • 核心思想：Service 不负责创建 Logger，而是使用外部提供的 Logger → 这就是“依赖注入”

3. : logger_(logger) → 初始化列表

   把传进来的 logger 参数 赋值给类成员变量 logger_

• Service 类 依赖 一个 Logger 对象来记录日志

• Service 自己不创建 Logger，而是通过构造函数 外部传入 一个 Logger 对象

• main() 函数创建 Logger 对象，再传给 Service 使用

好处：

• 测试更容易（可以传入Mock对象（用于测试的假对象））

• 生命周期由你控制

• 模块之间的依赖明确

(2) 把对象放到 main() 里

有些时候，其实你只需要在 main() 里创建一个对象，然后把它传递给需要的地方，完全不需要全局变量或单例。