单例模式的 100 种写法：到底哪一种才是真正‘线程安全’且‘不装逼’的？

为什么我们还在讨论单例模式？

各位技术同仁，下午好！

今天，我们来聊一个在软件工程领域经久不衰的话题——单例模式（Singleton Pattern）。它简单到几乎是每个初级程序员接触设计模式的起点，却又复杂到在各种面试、架构讨论中反复被提及，甚至引发激烈的争论。有人说它是“反模式”，应该被抛弃；有人说它是解决特定问题的“银弹”。而我今天要和大家探讨的，不仅仅是如何实现一个单例，更是要深挖其背后的原理、陷阱，并最终找出那个真正“线程安全”且“不装逼”的实现方式。

单例模式的核心目的很简单：确保一个类在任何时刻都只有一个实例存在，并提供一个全局的访问点。这听起来非常直观，比如配置管理器、日志记录器、线程池等，它们往往只需要一个全局唯一的实例来协调系统行为。然而，一旦我们将其引入多线程环境，或者需要考虑更复杂的系统场景时，事情就开始变得棘手起来。

在众多的单例实现中，我们常常看到各种奇技淫巧，有些是为了追求极致的性能，有些是为了应对反射、序列化等“攻击”，有些则仅仅是为了炫技。那么，到底哪一种才是我们在实际项目中可以放心使用，既能保证健壮性，又不会引入不必要的复杂度的方案呢？

让我们一起深入这场探索之旅。

第一章：单例模式的本质与挑战

在深入各种实现之前，我们先来明确单例模式的本质和它所面临的核心挑战。

1.1 单例模式的核心原则

一个标准的单例模式通常遵循以下三个原则：

1. 私有构造函数（Private Constructor）：阻止外部通过 new 关键字直接创建类的实例。这是确保单例的基础。
2. 静态私有实例（Static Private Instance）：类内部维护一个自身的静态实例。这个实例要么在类加载时创建，要么在首次使用时按需创建。
3. 公共静态获取方法（Public Static Access Method）：提供一个全局的访问点，允许外部获取这个唯一的实例。

1.2 为什么线程安全是关键？

在单线程环境下，实现单例模式是轻而易举的。但现代应用程序几乎都是多线程的。当多个线程同时尝试获取单例实例时，如果没有正确的同步机制，就可能发生竞态条件（Race Condition），导致创建出多个实例，从而违背了单例模式的初衷。

考虑以下场景：

• 线程 A 判断实例为空，准备创建。
• 线程 B 也判断实例为空，也准备创建。
• 线程 A 创建实例并赋值。
• 线程 B 此时也创建实例并赋值，覆盖了线程 A 创建的实例，或者导致两个实例同时存在。

这显然是我们不希望看到的。因此，线程安全是衡量一个单例实现是否合格的首要标准。

1.3 评估标准：除了线程安全，我们还看什么？

除了线程安全，一个优秀的单例实现还应该考虑以下几个方面：

• 性能（Performance）：获取实例的开销应该尽可能小。频繁的同步操作可能会成为性能瓶颈。
• 延迟加载（Lazy Loading）：实例只在第一次被使用时才创建，而不是在类加载时就创建。这可以节省资源，尤其当单例的创建成本较高或不确定是否会被使用时。
• 简洁性/可读性（Simplicity/Readability）：代码应该清晰易懂，易于维护。过度复杂的实现方式会增加理解成本和出错的概率。
• 防反射攻击（Reflection Safety）：能否抵御通过 Java 反射机制绕过私有构造函数创建新实例的尝试。
• 防序列化攻击（Serialization Safety）：能否在对象序列化和反序列化过程中保持单例特性，防止反序列化创建新的实例。
• JVM优化友好（JVM Optimization Friendly）：实现方式是否能够与 JVM 的即时编译器（JIT）良好协作，获得更好的运行时性能。

带着这些标准，我们开始逐一分析各种单例实现。

第二章：从“不安全”到“初级安全”的演进

2.1 最简单的单例 (非线程安全)

这是最直观的实现，但在多线程环境下是灾难性的。

public class SingletonNotSafe {
    private static SingletonNotSafe instance;

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

    public static SingletonNotSafe getInstance() {
        if (instance == null) { // 线程A执行到这里
            instance = new SingletonNotSafe(); // 线程B可能也执行到这里，导致创建多个实例
        }
        return instance;
    }

    public void showMessage() {
        System.out.println("Hello from SingletonNotSafe!");
    }
}

问题分析：
如前所述，当 if (instance == null) 判断为真时，多个线程可能同时进入 if 块，从而创建出多个 SingletonNotSafe 实例。这完全违背了单例模式的初衷。

2.2 饿汉式 (Eager Initialization – "Hungry" Singleton)

“饿汉式”单例在类加载时就完成了实例的创建，因此天生就是线程安全的。

public class SingletonEager {
    // 在类加载时就创建实例
    private static SingletonEager instance = new SingletonEager();

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

    public static SingletonEager getInstance() {
        return instance;
    }

    public void showMessage() {
        System.out.println("Hello from SingletonEager!");
    }
}

优点：

• 线程安全：由于实例在类加载阶段就被创建，并且 Java 虚拟机（JVM）会保证类的加载是线程安全的，所以不存在多线程创建多个实例的问题。
• 简单：实现代码非常简洁，易于理解。
• 性能好：获取实例时没有同步开销，直接返回已创建的实例。

缺点：

• 非延迟加载：无论是否需要，实例都会在类加载时被创建。如果单例的创建过程非常耗时，或者单例在整个应用程序生命周期中不一定会被使用，这就会造成资源浪费。

适用场景：单例对象创建成本低，且在应用程序启动时就需要或者确定会被频繁使用。

2.3 懒汉式 (线程安全，同步方法)

为了实现延迟加载，我们尝试在 getInstance 方法上加锁。

public class SingletonLazySynchronizedMethod {
    private static SingletonLazySynchronizedMethod instance;

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

    // 对获取实例的方法进行同步
    public static synchronized SingletonLazySynchronizedMethod getInstance() {
        if (instance == null) {
            instance = new SingletonLazySynchronizedMethod();
        }
        return instance;
    }

    public void showMessage() {
        System.out.println("Hello from SingletonLazySynchronizedMethod!");
    }
}

优点：

• 延迟加载：实例只在第一次调用 getInstance() 时才会被创建。
• 线程安全：synchronized 关键字确保在任何时刻只有一个线程能进入 getInstance() 方法，从而保证了实例的唯一性。

缺点：

• 性能开销：synchronized 关键字会锁定整个方法。这意味着每次调用 getInstance() 方法时，即使实例已经创建，也需要进行同步，这会带来不必要的性能开销。在高并发场景下，这可能成为一个严重的性能瓶颈。

适用场景：对性能要求不高，或者单例实例获取频率很低的场景。但在大多数生产环境中，这种方式因其性能问题而不被推荐。

2.4 懒汉式 (线程安全，同步代码块 – 错误示范)

有人可能会尝试将 synchronized 作用范围缩小到创建实例的代码块，以期提高性能。

public class SingletonLazySynchronizedBlockIncorrect {
    private static SingletonLazySynchronizedBlockIncorrect instance;

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

    public static SingletonLazySynchronizedBlockIncorrect getInstance() {
        if (instance == null) { // 线程A和线程B可能同时通过这个检查
            synchronized (SingletonLazySynchronizedBlockIncorrect.class) { // 只有获得锁的线程才能进入
                instance = new SingletonLazySynchronizedBlockIncorrect(); // 线程A创建实例
            } // 线程A释放锁
        } // 此时线程B可能再次进入if块，因为它之前已经通过了if检查
        return instance;
    }

    public void showMessage() {
        System.out.println("Hello from SingletonLazySynchronizedBlockIncorrect!");
    }
}

问题分析：
这种方式依然不是线程安全的！

考虑以下场景：

1. 线程 A 和线程 B 同时调用 getInstance()。
2. 它们都发现 instance == null 为真。
3. 线程 A 获得 SingletonLazySynchronizedBlockIncorrect.class 的锁，进入同步块，创建 instance。
4. 线程 A 释放锁，返回 instance。
5. 此时，线程 B 获得锁，进入同步块。由于线程 B 之前已经通过了 if (instance == null) 的检查，它会再次创建 instance，导致创建了第二个实例。

要解决这个问题，我们需要引入“双重检查锁定”（Double-Checked Locking，DCL），并且需要 volatile 关键字的帮助。

第三章：深入探索：DCL 与其陷阱

3.1 双重检查锁定 (DCL – Double-Checked Locking)

DCL 是在懒汉式基础上进行优化的一种尝试，旨在兼顾性能和线程安全，并实现延迟加载。它通过两次检查 instance == null 来减少同步的开销。

public class SingletonDCL {
    // 关键点：使用 volatile 关键字
    private static volatile SingletonDCL instance;

    private SingletonDCL() {
        // 私有构造函数
        // 防止反射攻击的额外防御
        if (instance != null) {
            throw new IllegalStateException("Already initialized.");
        }
    }

    public static SingletonDCL getInstance() {
        if (instance == null) { // 第一次检查：如果实例已经存在，无需同步，直接返回
            synchronized (SingletonDCL.class) { // 只有当实例不存在时，才进入同步块
                if (instance == null) { // 第二次检查：在同步块内部再次检查，确保只有一个线程创建实例
                    instance = new SingletonDCL(); // 创建实例
                }
            }
        }
        return instance;
    }

    public void showMessage() {
        System.out.println("Hello from SingletonDCL!");
    }
}

优点：

• 延迟加载：实例只在第一次调用 getInstance() 时才会被创建。
• 线程安全：通过双重检查和 volatile 关键字的配合，保证了实例的唯一性。
• 高性能：一旦实例被创建，后续的 getInstance() 调用将无需进入同步块，直接返回已存在的实例，大大减少了同步开销。

缺点：

• 相对复杂：需要理解 volatile 关键字的作用和内存模型，实现起来比饿汉式和同步方法式要复杂。
• volatile 关键字的必要性：这是 DCL 最容易出错的地方。在 JDK 1.5 之前，DCL 即使加上 volatile 也可能存在问题，但从 JDK 1.5 及之后的版本，volatile 关键字的语义得到了增强，可以确保 DCL 的正确性。

关键点：为什么需要 volatile 关键字？

instance = new SingletonDCL(); 这一行代码看起来简单，但在 JVM 层面，它并非一个原子操作。它大致分为以下三个步骤：

1. 分配内存：为 SingletonDCL 实例分配内存空间。
2. 初始化对象：调用 SingletonDCL 的构造函数，初始化对象。
3. 设置引用：将 instance 变量指向刚分配的内存地址。

在没有 volatile 关键字的情况下，JVM 和 CPU 为了优化性能，可能会对指令进行重排序。例如，步骤 2 和步骤 3 可能会被重排序。如果发生重排序，执行顺序可能是 1 -> 3 -> 2：

1. 分配内存。
2. 将 instance 变量指向已分配的内存地址（此时 instance 不为 null，但对象尚未完全初始化）。
3. 初始化对象。

假设线程 A 执行到 1 -> 3，此时 instance 已经不为 null。如果线程 B 此时进入 getInstance() 方法，它会发现 instance 不为 null，直接返回 instance。但问题是，线程 B 获取到的 instance 实际上是一个尚未完全初始化的对象，这会导致不可预测的行为，即所谓的“半初始化对象”问题。

volatile 关键字的作用：

1. 保证可见性：当一个线程修改了 volatile 变量的值，新值对其他线程是立即可见的。
2. 禁止指令重排序：volatile 关键字会插入内存屏障，阻止处理器对 volatile 变量相关的读写操作进行重排序。它确保在 instance = new SingletonDCL(); 这一行代码中，步骤 1、2、3 的执行顺序不会被改变，即“初始化对象”总是在“设置引用”之前完成。

因此，volatile 对于 DCL 的正确性至关重要。没有它，DCL 在理论上仍然是线程不安全的。

第四章：更优雅、更健壮的解决方案

DCL 虽然解决了性能和线程安全的问题，但其实现相对复杂，容易出错。有没有更简单、更优雅的方案呢？答案是肯定的。

4.1 静态内部类 (Static Inner Class)

静态内部类（Static Nested Class）实现单例模式是一种非常推荐的方式，它巧妙地结合了懒汉式和饿汉式的优点。

public class SingletonStaticInnerClass {
    private SingletonStaticInnerClass() {
        // 私有构造函数
        // 防止反射攻击的额外防御
        if (SingletonHolder.INSTANCE != null) {
            throw new IllegalStateException("Already initialized.");
        }
    }

    // 静态内部类，用于持有单例实例
    private static class SingletonHolder {
        // 在内部类被加载时创建实例
        private static final SingletonStaticInnerClass INSTANCE = new SingletonStaticInnerClass();
    }

    public static SingletonStaticInnerClass getInstance() {
        // 只有在第一次调用此方法时，SingletonHolder 类才会被加载，并创建 INSTANCE
        return SingletonHolder.INSTANCE;
    }

    public void showMessage() {
        System.out.println("Hello from SingletonStaticInnerClass!");
    }
}

工作原理：

1. SingletonStaticInnerClass 类在加载时，并不会立即加载 SingletonHolder 内部类。
2. 只有当 getInstance() 方法被首次调用时，SingletonHolder 内部类才会被加载。
3. 在 SingletonHolder 类加载时，其静态成员 INSTANCE 会被初始化，此时 SingletonStaticInnerClass 的实例才被创建。
4. Java 虚拟机（JVM）会保证类的初始化过程是线程安全的。在类加载阶段，JVM 会获取一个锁，确保只有一个线程能够执行类的初始化。因此，INSTANCE 的创建是线程安全的。

优点：

• 延迟加载：完美实现了懒加载，只有在需要时才创建实例。
• 线程安全：JVM 保证了类加载过程的线程安全性，无需额外的同步机制。
• 高性能：获取实例时没有同步开销，直接返回 final 字段。
• 简洁优雅：代码结构清晰，比 DCL 更易理解和维护。
• 推荐指数：在不使用枚举单例的情况下，这是最被广泛推荐的实现方式之一。

缺点：

• 仍然可能受到反射攻击的威胁（需要通过构造函数内部检查来防御）。

4.2 枚举单例 (Enum Singleton)

由 Joshua Bloch 在《Effective Java》中极力推荐的枚举单例，被认为是实现单例模式的最佳方式之一。

public enum SingletonEnum {
    // 定义一个枚举实例，这本身就是唯一的实例
    INSTANCE;

    // 枚举的构造函数默认是私有的
    // 你可以添加一些初始化逻辑，但它会在类加载时执行
    // private SingletonEnum() {
    //     System.out.println("SingletonEnum instance created.");
    // }

    public void showMessage() {
        System.out.println("Hello from SingletonEnum!");
    }
}

工作原理：

1. 当你第一次访问 SingletonEnum.INSTANCE 时，JVM 会加载 SingletonEnum 类。
2. 在加载过程中，INSTANCE 枚举成员会被初始化。
3. Java 语言规范明确规定，枚举类型是线程安全的，并且每个枚举成员在 JVM 中都是唯一的。JVM 会负责其创建和管理的细节。

优点：

• 极致的简洁：代码量最少，实现最简单。
• 天生线程安全：JVM 保证了枚举实例的创建和访问是线程安全的。
• 自动防御反射攻击：枚举的构造函数是私有的，并且在 Java 规范中，反射 API 对枚举的构造函数有特殊处理，不允许通过反射创建枚举的新实例。
• 自动防御序列化攻击：枚举类型在序列化和反序列化时，JVM 会特殊处理，保证反序列化时返回的是同一个实例，不会创建新的实例。这是其比DCL和静态内部类更强大的地方。
• 推荐指数：如果你对它的“非传统”外观没有顾虑，且需要最强的防御性，那么它是终极选择。

缺点：

• 非真正延迟加载：枚举实例会在枚举类加载时就被创建。虽然类加载通常发生在第一次访问枚举成员时，但严格来说，它不是按需执行构造函数逻辑的。如果枚举构造函数中包含大量耗时操作，这可能会影响应用程序启动或首次访问的性能。
• 在某些场景下，可能感觉不像传统的面向对象设计。

特性 / 实现方式	非线程安全	饿汉式	同步方法懒汉式	DCL (带volatile)	静态内部类	枚举单例
线程安全	否	是	是	是	是	是
延迟加载	是	否	是	是	是	否 (类加载时)
性能	极高	极高	差 (高并发)	高 (首次后)	极高	极高
简洁性/可读性	极高	极高	中	中 (需理解volatile)	高	极高
防反射攻击	否	否	否	否 (需额外防御)	否 (需额外防御)	是
防序列化攻击	否	否	否	否 (需额外防御)	否 (需额外防御)	是
推荐程度	绝不使用	特定场景推荐	避免使用	较推荐	非常推荐	强烈推荐

第五章：防御性编程：单例模式的攻击与反击

即使是最健壮的单例实现，也可能面临外部攻击，尤其是在复杂的系统环境中。主要有反射攻击和序列化攻击两种。

5.1 反射攻击 (Reflection Attack)

Java 的反射机制允许我们在运行时检查类、字段、方法，甚至可以修改它们的访问权限。这意味着我们可以绕过私有构造函数，强行创建单例类的新实例。

攻击示例：

import java.lang.reflect.Constructor;

public class ReflectionAttackDemo {
    public static void main(String[] args) throws Exception {
        // 获取静态内部类实现的单例
        SingletonStaticInnerClass instance1 = SingletonStaticInnerClass.getInstance();

        // 通过反射获取私有构造函数
        Constructor<SingletonStaticInnerClass> constructor = SingletonStaticInnerClass.class.getDeclaredConstructor();
        // 允许访问私有构造函数
        constructor.setAccessible(true);
        // 通过反射创建新的实例
        SingletonStaticInnerClass instance2 = constructor.newInstance();

        System.out.println("Instance 1: " + instance1.hashCode());
        System.out.println("Instance 2: " + instance2.hashCode());
        System.out.println("Are they same? " + (instance1 == instance2)); // 输出 false，单例被破坏
    }
}

反击策略：
在单例类的构造函数中加入判断，如果 instance 已经不为空，就抛出运行时异常。

public class SingletonStaticInnerClassDefensive {
    private SingletonStaticInnerClassDefensive() {
        // 在构造函数内部检查实例是否已存在
        if (SingletonHolder.INSTANCE != null) { // 注意这里要引用内部类的实例
            // 更好的做法是直接检查外部类的instance是否已初始化
            // if (SingletonStaticInnerClassDefensive.getInstance() != null && SingletonHolder.INSTANCE != null) {
            //     throw new IllegalStateException("Singleton instance already created!");
            // }
            // 这里的判断略有复杂，因为SingletonHolder.INSTANCE本身就是通过构造函数创建的。
            // 简单起见，可以这样设计：
            if (instance != null) { // 检查外部类的静态实例
                throw new IllegalStateException("Singleton instance already created!");
            }
        }
    }

    // 静态外部类的实例，用于防御反射攻击
    private static SingletonStaticInnerClassDefensive instance;

    private static class SingletonHolder {
        private static final SingletonStaticInnerClassDefensive INSTANCE = new SingletonStaticInnerClassDefensive();
    }

    public static SingletonStaticInnerClassDefensive getInstance() {
        // 确保 instance 在第一次被创建时赋值
        if (instance == null) {
            instance = SingletonHolder.INSTANCE; // 第一次访问时赋值
        }
        return instance;
    }

    public void showMessage() {
        System.out.println("Hello from SingletonStaticInnerClassDefensive!");
    }
}

注意：对于静态内部类，直接在私有构造函数里判断 SingletonHolder.INSTANCE 会陷入死循环或者不准确，因为 SingletonHolder.INSTANCE 正在被创建。更准确的防御是在外部类中引入一个标记，或者在 getInstance() 首次调用后将实例赋值给外部类的静态成员变量，然后构造函数检查这个外部类的静态成员变量。

更通用、更简洁的防御方式 (适用于DCL和静态内部类)：

public class SingletonDefensive {
    private static volatile SingletonDefensive instance; // DCL 示例

    private SingletonDefensive() {
        // 在构造函数内部进行防御
        if (instance != null) { // 检查是否已有实例，如果有，则抛出异常
            throw new IllegalStateException("Cannot create another instance of SingletonDefensive.");
        }
    }

    public static SingletonDefensive getInstance() {
        if (instance == null) {
            synchronized (SingletonDefensive.class) {
                if (instance == null) {
                    instance = new SingletonDefensive();
                }
            }
        }
        return instance;
    }
}

例外：枚举单例天然免疫反射攻击，无需额外防御。

5.2 序列化攻击 (Serialization Attack)

当单例对象被序列化到文件，然后再从文件中反序列化回来时，readObject() 方法默认会创建一个新的对象。这也会破坏单例模式。

攻击示例：

import java.io.*;

public class SerializationAttackDemo {
    public static void main(String[] args) throws Exception {
        SingletonDCL instance1 = SingletonDCL.getInstance();

        // 序列化
        ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("singleton.ser"));
        oos.writeObject(instance1);
        oos.close();

        // 反序列化
        ObjectInputStream ois = new ObjectInputStream(new FileInputStream("singleton.ser"));
        SingletonDCL instance2 = (SingletonDCL) ois.readObject();
        ois.close();

        System.out.println("Instance 1: " + instance1.hashCode());
        System.out.println("Instance 2: " + instance2.hashCode());
        System.out.println("Are they same? " + (instance1 == instance2)); // 输出 false，单例被破坏
    }
}

注意：要使一个类可序列化，它需要实现 Serializable 接口。

反击策略：
在单例类中实现 readResolve() 方法。当 JVM 反序列化一个对象时，如果检测到这个方法，就会调用它，并用 readResolve() 方法的返回值替换掉新创建的对象。

import java.io.ObjectStreamException;
import java.io.Serializable;

public class SingletonDCLDefensive implements Serializable {
    private static final long serialVersionUID = 1L; // 推荐添加 serialVersionUID

    private static volatile SingletonDCLDefensive instance;

    private SingletonDCLDefensive() {
        // 防反射攻击
        if (instance != null) {
            throw new IllegalStateException("Cannot create another instance of SingletonDCLDefensive.");
        }
    }

    public static SingletonDCLDefensive getInstance() {
        if (instance == null) {
            synchronized (SingletonDCLDefensive.class) {
                if (instance == null) {
                    instance = new SingletonDCLDefensive();
                }
            }
        }
        return instance;
    }

    // 防序列化攻击：当对象从流中反序列化时，此方法会被调用
    protected Object readResolve() throws ObjectStreamException {
        return getInstance(); // 返回已存在的单例实例
    }

    public void showMessage() {
        System.out.println("Hello from SingletonDCLDefensive!");
    }
}

例外：枚举单例天然免疫序列化攻击，无需额外防御。

5.3 多类加载器攻击 (Multiple Classloaders Attack)

在一个 JVM 中，如果由不同的类加载器加载同一个单例类，那么它们会创建出各自的单例实例，因为每个类加载器都有自己的命名空间。这在 Web 服务器（如 Tomcat）或 OSGi 框架中可能会发生。

反击策略：
这种攻击通常不是在单例类内部可以轻易解决的。它需要更高级别的架构设计来处理类加载器的隔离和共享问题。例如，确保单例类总是由应用程序的根类加载器加载，或者通过特定的类加载器委托机制来管理。在大多数业务应用中，除非你正在开发一个复杂的框架或服务器，否则通常不需要过多关注此类问题。

第六章：现代视角与替代方案

单例模式虽然经典，但它并非没有争议。随着软件开发实践的发展，一些新的模式和框架提供了更好的替代方案。

6.1 单例模式的“反模式”争议

• 全局状态：单例本质上引入了全局状态，这使得程序的行为更难预测，增加了耦合度。
• 测试困难：由于单例是全局唯一的，且通常在内部管理自己的创建，这使得在单元测试中难以对它进行模拟（Mock）或替换（Stub），从而增加了测试的复杂性。
• 隐藏依赖：使用 Singleton.getInstance() 这种方式，类对单例的依赖是隐式的，而不是通过构造函数或方法参数显式声明的，这使得代码的依赖关系不透明。

6.2 依赖注入框架 (Dependency Injection Frameworks)

现代的应用程序，尤其是基于 Spring、Guice、Dagger 等框架构建的，通常会使用依赖注入（Dependency Injection, DI）来管理对象的生命周期和依赖关系。

在这些框架中，你通常不需要手动实现单例模式。框架本身就提供了“单例作用域（Singleton Scope）”的概念。你只需将一个类标记为单例，框架就会负责确保在整个应用程序中只创建该类的一个实例，并负责将其注入到需要它的地方。

Spring 框架示例：

// Spring Bean，默认就是单例作用域
@Service // 或者 @Component, @Repository, @Controller
public class MyService {
    public void doSomething() {
        System.out.println("MyService instance is a Spring singleton.");
    }
}

// 在其他地方使用
@Component
public class AnotherComponent {
    private final MyService myService;

    // Spring 会自动注入 MyService 的单例实例
    public AnotherComponent(MyService myService) {
        this.myService = myService;
    }

    public void execute() {
        myService.doSomething();
    }
}

通过依赖注入，单例的生命周期由框架管理，依赖关系清晰，测试也更容易（可以注入 mock 对象）。这通常是现代 Java 应用中处理“全局唯一实例”问题的首选方式。

6.3 什么时候我们仍然需要手动实现单例？

尽管 DI 框架提供了更优雅的方案，但在以下情况下，你可能仍然需要手动实现单例模式：

• 小型项目/不引入复杂框架：如果项目非常小，引入 Spring 等大型 DI 框架显得过于重量级，手动实现一个简洁的单例是合理的。
• 核心工具类：某些底层或核心的工具类，它们必须是单例，并且不依赖于任何框架。
• 遗留系统：维护或扩展没有使用 DI 框架的遗留系统。
• 框架集成：在某些框架内部，为了实现特定的功能，框架开发者可能会手动实现单例。
• 性能敏感的场景：某些极端性能敏感的场景，你可能需要对实例的创建和管理有更细粒度的控制（尽管 DI 框架通常也足够高效）。

第七章：最终思考与推荐

通过对单例模式各种实现方式的深入探讨，我们看到了从最初的简单但线程不安全，到饿汉式的直接安全，再到懒汉式结合同步和DCL的复杂演进，以及最终通过静态内部类和枚举实现的优雅与健壮。

回顾我们最初的评估标准：线程安全、性能、延迟加载、简洁性、防反射/序列化攻击。

特性 / 实现方式	饿汉式	同步方法懒汉式	DCL (带volatile)	静态内部类	枚举单例
线程安全	是	是	是	是	是
延迟加载	否	是	是	是	否 (类加载时)
性能	极高	差 (高并发)	高 (首次后)	极高	极高
简洁性/可读性	极高	中	中 (需理解volatile)	高	极高
防反射攻击	否 (需防御)	否 (需防御)	否 (需防御)	否 (需防御)	是
防序列化攻击	否 (需防御)	否 (需防御)	否 (需防御)	否 (需防御)	是

那么，到底哪一种才是真正“线程安全”且“不装逼”的呢？

我的推荐是：

1. 首选：静态内部类（Static Inner Class）
   它完美地平衡了延迟加载、线程安全、高性能和代码简洁性。它不需要额外的同步开销，也不需要 volatile 关键字的复杂性，是大多数场景下最“不装逼”且极其可靠的选择。如果需要防御反射和序列化，可以轻松添加相应的防御代码。

2. 次选：枚举单例（Enum Singleton）
   如果你对它的语法形式没有顾虑，那么枚举单例提供了最强的防御性，天然免疫反射和序列化攻击，并且代码极致简洁。它唯一的“缺点”是严格意义上不是延迟加载，但对于大多数单例而言，其初始化成本通常不高，这个缺点可以忽略不计。在《Effective Java》中，Joshua Bloch 明确推荐使用枚举来实现单例，称其为“最佳实践”。

3. DCL (Double-Checked Locking) with volatile
   DCL 也是一个非常好的选择，它实现了延迟加载、线程安全和高性能。但由于需要正确理解并使用 volatile 关键字，其心智负担略高于静态内部类。如果你对 Java 内存模型和 volatile 有深入理解，使用它也完全没有问题。

总结

在选择单例实现时，我们不仅要考虑其线程安全性，还要权衡性能、可读性以及对潜在攻击的防御能力。在现代应用开发中，如果项目使用了依赖注入框架，优先让框架管理单例的生命周期。如果需要手动实现，静态内部类和枚举单例无疑是兼顾所有优点，并且“不装逼”的优秀选择。理解每种方式的优缺点和适用场景，才能做出最明智的技术决策。