Java单例模式详解：饿汉式与懒汉式实现对比

1. 单例模式基础认知

单例模式（Singleton Pattern）是Java中最基础的设计模式之一，它的核心目标是确保一个类在任何情况下都绝对只有一个实例，并提供一个全局访问点。这种模式在需要控制资源访问、配置管理或线程池等场景中尤为常见。

设计模式的本质是前人总结的最佳实践方案，就像建筑领域的标准施工图纸，能避免重复踩坑。单例模式解决的核心问题是"如何确保一个类只有一个实例"。

1.1 单例模式三大特征

1. 私有化构造器：通过private修饰构造方法，禁止外部通过new关键字创建实例。这是实现单例的基础保障。
2. 静态实例持有：在类内部创建并持有该类的唯一实例，通常使用static修饰保证全局唯一性。
3. 全局访问点：提供public static方法作为获取实例的统一入口，通常命名为getInstance()。

java复制// 典型单例结构示例
public class Singleton {
    private static Singleton instance = new Singleton(); // 静态实例
    
    private Singleton() {} // 私有构造
    
    public static Singleton getInstance() { // 全局访问点
        return instance;
    }
}

1.2 单例模式的应用场景

• 配置管理：如数据库配置、系统参数等需要全局统一访问的对象
• 资源管理：线程池、连接池等需要严格控制数量的资源
• 工具类：无状态的工具类避免重复创建消耗资源
• 缓存系统：全局缓存需要保证唯一性

2. 饿汉式单例实现详解

饿汉式（Eager Initialization）是单例模式最直接的实现方式，其特点是类加载时就立即初始化实例。这种方式简单粗暴，但需要考虑资源占用问题。

2.1 基础实现代码

java复制public class EagerSingleton {
    // 静态常量保证实例唯一性
    private static final EagerSingleton INSTANCE = new EagerSingleton();
    
    // 私有构造器阻断外部实例化
    private EagerSingleton() {
        System.out.println("EagerSingleton实例被创建");
    }
    
    // 全局访问点
    public static EagerSingleton getInstance() {
        return INSTANCE;
    }
}

2.2 关键实现原理

1. final关键字的作用：

   • 防止实例被重新赋值：INSTANCE = null;这样的操作会在编译时报错
   • 保证可见性：final变量的初始化对其他线程立即可见
   • 禁止指令重排序：避免JVM优化导致的初始化问题

2. 类加载机制保证线程安全：

   • JVM在类加载阶段会加锁保证线程安全
   • static变量在类初始化阶段被赋值，天然线程安全

3. 资源消耗考量：

   • 如果实例化过程耗时或占用资源多，会影响程序启动速度
   • 即使用不到该实例也会被创建，可能造成资源浪费

2.3 饿汉式变体：静态代码块初始化

java复制public class EagerSingletonV2 {
    private static final EagerSingletonV2 INSTANCE;
    
    static {
        try {
            INSTANCE = new EagerSingletonV2();
        } catch (Exception e) {
            throw new RuntimeException("创建单例失败", e);
        }
    }
    
    private EagerSingletonV2() {}
    
    public static EagerSingletonV2 getInstance() {
        return INSTANCE;
    }
}

静态代码块方式允许我们在初始化时进行异常处理，适合需要复杂初始化逻辑的场景。但本质上仍是类加载时初始化，与基础饿汉式没有性能差异。

3. 懒汉式单例实现解析

懒汉式（Lazy Initialization）与饿汉式相反，它延迟实例的创建，只有在第一次请求实例时才进行初始化。这种方式更节约资源，但需要考虑线程安全问题。

3.1 基础懒汉式实现

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

3.2 线程安全问题分析

基础懒汉式实现存在严重的线程安全问题：

1. 竞态条件：当多个线程同时检查instance == null时，可能都会进入创建实例的代码块
2. 指令重排序：JVM可能优化new操作的指令顺序，导致返回未初始化完成的对象

通过以下代码可以验证线程安全问题：

java复制public class TestThreadSafety {
    public static void main(String[] args) {
        for (int i = 0; i < 10; i++) {
            new Thread(() -> {
                LazySingleton instance = LazySingleton.getInstance();
                System.out.println(instance.hashCode());
            }).start();
        }
    }
}

运行后会打印出不同的hashCode，证明创建了多个实例。

3.3 线程安全改进方案

方案1：同步方法（不推荐）

java复制public synchronized static LazySingleton getInstance() {
    if (instance == null) {
        instance = new LazySingleton();
    }
    return instance;
}

虽然解决了线程安全问题，但每次获取实例都要同步，性能开销大。实际上只有第一次创建时需要同步。

方案2：双重检查锁定（DCL）

java复制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;
    }
}

关键点说明：

1. volatile关键字：防止指令重排序，保证可见性
2. 双重检查：减少同步块进入次数
3. 性能优势：只有第一次创建时需要同步，后续访问无锁

方案3：静态内部类（推荐）

java复制public class InnerClassSingleton {
    private InnerClassSingleton() {}
    
    private static class Holder {
        private static final InnerClassSingleton INSTANCE = new InnerClassSingleton();
    }
    
    public static InnerClassSingleton getInstance() {
        return Holder.INSTANCE;
    }
}

优势分析：

• 懒加载：只有调用getInstance()时才会加载Holder类
• 线程安全：由JVM类加载机制保证
• 无同步开销：不需要额外的同步控制

4. 单例模式的高级话题

4.1 反射攻击与防御

通过反射可以绕过私有构造器的限制，破坏单例：

java复制Constructor<InnerClassSingleton> constructor = 
    InnerClassSingleton.class.getDeclaredConstructor();
constructor.setAccessible(true);
InnerClassSingleton instance1 = constructor.newInstance();
InnerClassSingleton instance2 = InnerClassSingleton.getInstance();
System.out.println(instance1 == instance2); // 输出false

防御方案：在构造器中添加检查逻辑

java复制private InnerClassSingleton() {
    if (Holder.INSTANCE != null) {
        throw new RuntimeException("不允许通过反射创建实例");
    }
}

4.2 序列化与反序列化问题

当单例类实现Serializable接口时，反序列化会创建新实例：

java复制// 序列化
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("singleton.ser"));
oos.writeObject(InnerClassSingleton.getInstance());
oos.close();

// 反序列化
ObjectInputStream ois = new ObjectInputStream(new FileInputStream("singleton.ser"));
InnerClassSingleton instance = (InnerClassSingleton) ois.readObject();
System.out.println(instance == InnerClassSingleton.getInstance()); // 输出false

解决方案：实现readResolve方法

java复制private Object readResolve() {
    return getInstance();
}

4.3 枚举单例（最佳实践）

java复制public enum EnumSingleton {
    INSTANCE;
    
    public void doSomething() {
        System.out.println("执行操作");
    }
}

优势总结：

1. 绝对防止反射攻击
2. 自动处理序列化问题
3. 代码简洁
4. 线程安全

5. 单例模式实践建议

5.1 选型决策树

1. 是否需要懒加载？
   • 是 → 考虑静态内部类或枚举
   • 否 → 使用饿汉式
2. 是否需要防御反射/序列化攻击？
   • 是 → 优先选择枚举实现
   • 否 → 常规实现即可
3. 性能要求极高？
   • 是 → 饿汉式或静态内部类
   • 否 → 可考虑其他方案

5.2 常见误区警示

1. 过度使用单例：单例本质上是全局变量，滥用会导致代码耦合度高
2. 忽略线程安全：多线程环境下必须考虑同步问题
3. 忽视序列化风险：实现Serializable时要记得实现readResolve
4. 过早优化：不要为了性能而牺牲代码安全性

5.3 性能对比测试

通过JMH基准测试比较不同实现方式的性能：

测试结果显示同步方法性能最差，其他方式差异不大。

6. 单例模式在框架中的应用

6.1 Spring中的单例

Spring默认的bean作用域就是单例，但与设计模式中的单例有区别：

1. Spring单例是容器级别的，一个容器内保证唯一
2. 设计模式单例是JVM级别的，整个JVM内保证唯一

6.2 单例与依赖注入

现代Java开发更推荐使用依赖注入而非直接使用单例模式：

java复制@Service // Spring会保证单例
public class UserService {
    // ...
}

@Controller
public class UserController {
    @Autowired // 依赖注入
    private UserService userService;
}

6.3 替代方案考虑

在某些场景下可以考虑替代方案：

1. 依赖注入：通过框架管理对象生命周期
2. 工厂模式：需要灵活创建对象时
3. 静态工具类：对于无状态的操作集合

在最近的一个电商平台项目中，我们使用Spring管理的单例bean来处理全局配置信息，而对于一些工具类则采用了枚举单例实现，既保证了线程安全又避免了反射攻击。实际开发中发现，合理选择单例实现方式确实能显著减少并发问题的发生。