单例模式，你真的写对了吗？

单例模式作为设计模式中最基础、最常用的模式之一，其核心目标是通过控制类的实例化次数，确保一个类只有一个实例，并提供全局访问点。然而在实际开发中，许多开发者对单例模式的理解仅停留在”静态变量+私有构造方法”的表面，导致在多线程、序列化、反射攻击等场景下出现严重问题。本文将从基础实现到高级场景，系统剖析单例模式的正确写法与避坑指南。

一、单例模式的常见实现方式及其缺陷

1.1 饿汉式单例：简单但存在资源浪费

public class EagerSingleton {
    private static final EagerSingleton INSTANCE = new EagerSingleton();
    private EagerSingleton() {}
    public static EagerSingleton getInstance() {
        return INSTANCE;
    }
}

优点：实现简单，线程安全（类加载时初始化）。
缺点：无法延迟加载，若实例未被使用会造成资源浪费；若初始化过程抛出异常，会导致类不可用。

1.2 懒汉式单例：线程安全的代价

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

优点：延迟加载，按需创建。
缺点：同步方法导致性能下降（每次获取实例都需要加锁）。

1.3 双重检查锁（DCL）：看似完美实则陷阱重重

public class DCLSingleton {
    private volatile static DCLSingleton instance;
    private DCLSingleton() {}
    public static DCLSingleton getInstance() {
        if (instance == null) { // 第一次检查
            synchronized (DCLSingleton.class) {
                if (instance == null) { // 第二次检查
                    instance = new DCLSingleton();
                }
            }
        }
        return instance;
    }
}

关键点：

• volatile关键字防止指令重排序（解决JSR-133之前的内存可见性问题）
• 双重检查减少同步开销

历史问题：在Java 5之前，由于缺乏volatile的语义保证，可能导致实例未完全初始化就被其他线程访问。
现代适用性：Java 5+可安全使用，但代码复杂度高，维护成本大。

二、线程安全的最佳实践：静态内部类实现

public class StaticHolderSingleton {
    private StaticHolderSingleton() {}
    private static class Holder {
        private static final StaticHolderSingleton INSTANCE = new StaticHolderSingleton();
    }
    public static StaticHolderSingleton getInstance() {
        return Holder.INSTANCE;
    }
}

原理：

• 类加载机制保证线程安全（JVM在类初始化阶段会加锁）
• 延迟加载（Holder类在首次调用getInstance()时加载）
  优势：
• 无锁访问，性能最优
• 代码简洁，可读性强
• 天然防止反射攻击（构造方法私有且类未初始化时无法访问）

三、序列化与反序列化破坏单例的解决方案

单例对象在序列化时会默认调用ObjectOutputStream的默认机制，可能导致反序列化后产生新实例。

3.1 解决方案：实现readResolve()方法

public class SerializableSingleton implements Serializable {
    private static final long serialVersionUID = 1L;
    private static final SerializableSingleton INSTANCE = new SerializableSingleton();
    private SerializableSingleton() {}
    public static SerializableSingleton getInstance() {
        return INSTANCE;
    }
    // 防止反序列化创建新实例
    protected Object readResolve() {
        return getInstance();
    }
}

原理：反序列化时会调用readResolve()方法返回已有实例。

3.2 枚举实现：终极防御方案

public enum EnumSingleton {
    INSTANCE;
    public void doSomething() {
        System.out.println("Singleton method");
    }
}

优势：

• 绝对防止多次实例化（包括反射攻击）
• 自动支持序列化机制（无需readResolve()）
• 代码极其简洁
  《Effective Java》推荐：Joshua Bloch明确指出”单元素的枚举类型是实现单例的最佳方式”。

四、反射攻击与防御策略

攻击者可通过反射强制调用私有构造方法：

Constructor<Singleton> constructor = Singleton.class.getDeclaredConstructor();
constructor.setAccessible(true);
Singleton newInstance = constructor.newInstance(); // 创建第二个实例

防御方案：

1. 构造方法抛出异常：

   private Singleton() {
    if (INSTANCE != null) {
        throw new IllegalStateException("Singleton already initialized");
    }
   }

2. 枚举实现（天然防御反射攻击）

五、容器式单例：管理多个单例对象

当需要管理多个单例对象时，可采用容器式实现：

public class SingletonManager {
    private static final Map<String, Object> singletonMap = new ConcurrentHashMap<>();
    private SingletonManager() {}
    public static void registerSingleton(String key, Object instance) {
        if (!singletonMap.containsKey(key)) {
            singletonMap.put(key, instance);
        }
    }
    public static Object getSingleton(String key) {
        return singletonMap.get(key);
    }
}

适用场景：

• 需要集中管理多个单例类
• 动态添加/移除单例对象
  注意点：需自行保证线程安全（示例中使用ConcurrentHashMap）

六、多线程环境下的性能优化

对于高并发场景，可考虑以下优化方案：

6.1 CAS（Compare-And-Swap）实现

public class CASSingleton {
    private static volatile CASSingleton instance;
    private CASSingleton() {}
    public static CASSingleton getInstance() {
        CASSingleton result = instance;
        if (result == null) {
            synchronized (CASSingleton.class) {
                result = instance;
                if (result == null) {
                    instance = result = new CASSingleton();
                }
            }
        }
        return result;
    }
}

优化点：减少同步块执行次数（先无锁检查，再同步）

6.2 初始化于需求（Initialization-on-demand holder）

前文提到的静态内部类方案已是此类的最佳实践，无需额外优化。

七、实际应用中的选型建议

实现方式	线程安全	延迟加载	序列化安全	反射安全	复杂度
饿汉式	是	否	否	否	低
同步方法	是	是	否	否	低
双重检查锁	是	是	否	否	高
静态内部类	是	是	否	是	中
枚举实现	是	否	是	是	极低
容器管理	是	可选	需处理	需处理	高

推荐方案：

1. 大多数场景：静态内部类实现
2. 需要序列化/反射安全：枚举实现
3. 简单需求且无序列化要求：饿汉式
4. 避免使用：双重检查锁（复杂度高且易出错）

八、单例模式的滥用与替代方案

何时不应使用单例：

• 需要多个实例的场景
• 测试困难（单例的强状态导致测试隔离难）
• 与依赖注入框架冲突（如Spring的@Bean）

替代方案：

1. 依赖注入：通过容器管理唯一实例
2. 服务定位器：集中查找服务实例（但需谨慎使用）
3. Monostate模式：所有实例共享同一状态（行为类似单例但允许多个对象）

九、总结与最佳实践

1. 优先选择静态内部类或枚举实现：兼顾线程安全、延迟加载和代码简洁性
2. 必须处理序列化问题：实现readResolve()或使用枚举
3. 防御反射攻击：通过构造方法检查或枚举实现
4. 避免过度优化：双重检查锁等复杂方案通常不必要
5. 考虑替代方案：在框架环境中优先使用依赖注入

单例模式虽小，但涉及线程安全、内存模型、序列化等核心Java机制。正确实现需要深入理解这些底层原理，而非简单套用模板代码。希望本文能帮助开发者彻底掌握单例模式，写出既正确又健壮的代码。