单例模式：看似简单的设计陷阱

在软件开发的世界里，单例模式（Singleton Pattern） 往往是开发者接触到的第一个设计模式。它的初衷异常简单：确保一个类只有一个实例，并提供一个全局访问点。然而，这种“简单”背后隐藏着诸多关于线程安全、性能损耗以及可测试性的深度博弈。

一、为什么需要单例？

有些对象的存在，天然就应该是唯一的。

资源共享：如数据库连接池、线程池。如果创建多个实例，会造成严重的资源浪费甚至冲突。
状态同步：如全局配置管理器、日志系统。我们需要确保所有模块读取到的都是同一份数据。

二、单例的演进：从“饿汉”到“双重检查”

实现单例并不难，难的是在高并发环境下，既能保证唯一性，又能兼顾性能。

1. 饿汉式 (Eager Initialization)

在类加载时就完成初始化。

优点：线程安全，实现简单。
缺点：无论是否使用都会占用内存，缺乏延迟加载（Lazy Loading）的灵活性。

2. 懒汉式 (Lazy Initialization)

仅在第一次调用时才创建实例。

风险：在多线程环境下，若不加锁，可能会创建出多个实例。

3. 双重检查锁定 (Double-Checked Locking)

为了兼顾性能与安全，我们引入了双重检查机制。

/**
 * Java 版本的双重检查锁定单例
 */
public class Singleton {
    // volatile 关键字至关重要，防止指令重排序
    private static volatile Singleton instance;

    private Singleton() {} // 私有构造函数

    public static Singleton getInstance() {
        if (instance == null) { // 第一次检查，避免不必要的加锁
            synchronized (Singleton.class) {
                if (instance == null) { // 第二次检查，确保唯一
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

小明深度解析：为什么需要 volatile？因为 new Singleton() 并不是一个原子操作，它涉及分配空间、初始化对象、引用赋值三个步骤。在没有 volatile 的情况下，指令重排序可能导致一个未初始化的引用被暴露给其他线程，引发灾难。

三、单例模式的弊端：它真的还是英雄吗？

在现代工程实践中，单例模式常被视为一种“反模式（Anti-Pattern）”。

违背单一职责原则：单例类既负责业务逻辑，又负责自身的生命周期管理。
隐藏依赖关系：全局变量使得模块间的依赖变得隐晦，增加了代码的耦合度。
单元测试的噩梦：单例的状态在测试用例之间持久存在，导致测试结果互相干扰，难以实现完全的隔离。

单例模式：看似简单的设计陷阱

单例模式：看似简单的设计陷阱

一、为什么需要单例？

二、单例的演进：从“饿汉”到“双重检查”

1. 饿汉式 (Eager Initialization)

2. 懒汉式 (Lazy Initialization)

3. 双重检查锁定 (Double-Checked Locking)

三、单例模式的弊端：它真的还是英雄吗？

四、现代替代方案：依赖注入 (DI)

结语：克制的力量

下期预告

相关标签