单例模式 “四兄弟” 图鉴：饿汉、懒汉与 DCL 的 “单身保卫战”

秋难降
185 阅读9分钟

深入解析单例模式的四种经典实现方式

在软件开发领域，设计模式是解决重复问题的成熟方案，而单例模式作为创建型模式的核心成员，其核心目标是确保一个类在整个应用程序中仅有一个实例，并提供一个全局统一的访问入口。这种模式广泛应用于线程池、配置管理、日志记录等场景，能有效避免资源重复占用、保证数据一致性。本文将详细拆解单例模式的四种经典实现方式，从原理、代码到优缺点进行全面分析，帮助开发者根据实际场景选择最合适的方案。

一、单例模式的核心原则

在深入具体实现前，需明确单例模式的两个核心约束：

  1. 构造方法私有化：禁止外部通过 new 关键字创建实例，确保实例创建权完全由类自身控制；
  1. 提供全局访问点：通过静态方法（如 getInstance()）向外部暴露唯一实例，保证所有调用者获取的是同一个对象。

基于这两个约束，不同实现方式在线程安全性、懒加载（延迟初始化） 和性能上存在差异，这也是区分四种实现方式的关键维度。

二、四种经典实现方式解析

（一）饿汉式：“饿” 在初始化，线程安全但无懒加载

饿汉式的核心思想是 “提前创建实例”—— 在类加载时就完成实例初始化，而非等到第一次调用时再创建。由于类加载过程由 JVM 保证线程安全（同一类仅加载一次），因此无需额外加锁即可避免多线程下的实例重复创建问题。

1. 实现代码
public class HungrySingleton {
    // 1. 私有静态成员变量：类加载时直接初始化实例
    private static final HungrySingleton INSTANCE = new HungrySingleton();
    
    // 2. 构造方法私有化：禁止外部创建实例
    private HungrySingleton() {}
    
    // 3. 静态全局访问点：返回已初始化的实例
    public static HungrySingleton getInstance() {
        return INSTANCE;
    }
}
2. 核心原理
  • 类加载阶段（JVM 执行 clinit() 方法时），静态变量 INSTANCE 会被初始化，且整个过程由 JVM 保证线程安全；
  • 外部调用 getInstance() 时，仅需直接返回已创建的实例，无需任何判断或锁操作。
3. 优缺点分析
优点缺点
实现简单，无任何线程安全隐患无懒加载特性：若类实例占用资源大（如数据库连接池），且程序全程未使用，会造成资源浪费
调用 getInstance() 时性能极高（无锁、无判断）无法通过配置文件动态初始化实例（初始化时机过早，无法接收外部参数）
4. 适用场景

适用于实例占用资源小、程序启动后大概率会使用的场景，例如工具类（如日期格式化工具）、简单配置管理器等。

（二）懒汉式（基础版）：“懒” 在初始化，线程不安全

懒汉式的核心思想是 “延迟创建实例”—— 仅在第一次调用 getInstance() 时才初始化实例，避免资源浪费。但基础版的懒汉式未考虑线程安全，在多线程环境下会导致实例重复创建。

1. 实现代码
public class LazySingletonBasic {
    // 1. 私有静态成员变量：初始化为 null，不提前创建实例
    private static LazySingletonBasic INSTANCE = null;
    
    // 2. 构造方法私有化
    private LazySingletonBasic() {}
    
    // 3. 静态全局访问点：第一次调用时创建实例
    public static LazySingletonBasic getInstance() {
        // 若实例未创建，则创建；否则直接返回
        if (INSTANCE == null) {
            INSTANCE = new LazySingletonBasic();
        }
        return INSTANCE;
    }
}
2. 核心问题：线程安全隐患

在多线程并发调用 getInstance() 时，会出现 “竞态条件”：

  • 线程 A 进入 if (INSTANCE == null) 判断，发现实例未创建，准备执行 new 操作；
  • 此时线程 B 也进入判断，同样发现实例为 null，也执行 new 操作；
  • 最终线程 A 和线程 B 会创建两个不同的实例，违反单例模式的核心约束。
3. 优缺点分析
优点缺点
实现简单，支持懒加载（避免资源浪费）线程不安全：多线程环境下会创建多个实例，完全不符合单例要求
初始化时可接收外部参数（如配置文件路径）无
4. 适用场景

仅适用于单线程环境（如本地工具类、非并发的桌面应用），严禁在多线程环境（如 Web 应用、分布式系统）中使用。

（三）懒汉式（线程安全版）：加锁保证安全，但性能受损

为解决基础版懒汉式的线程安全问题，最直接的方案是在 getInstance() 方法上加锁（使用 synchronized 关键字），确保同一时间仅一个线程能执行实例创建逻辑。

1. 实现代码
public class LazySingletonSafe {
    private static LazySingletonSafe INSTANCE = null;
    
    private LazySingletonSafe() {}
    
    // 在方法上添加 synchronized 锁，确保线程安全
    public static synchronized LazySingletonSafe getInstance() {
        if (INSTANCE == null) {
            INSTANCE = new LazySingletonSafe();
        }
        return INSTANCE;
    }
}
2. 核心原理
  • synchronized 关键字修饰静态方法时，锁对象为当前类的 Class 对象（全局唯一）；
  • 多线程调用 getInstance() 时，需先获取类锁，只有获取锁的线程能执行方法体，其他线程需排队等待；
  • 实例创建完成后，后续线程进入方法时，会直接跳过 if 判断并返回实例，无需再执行 new 操作。
3. 优缺点分析
优点缺点
支持懒加载，且完全解决线程安全问题性能损耗大：每次调用 getInstance() 都需获取类锁，即使实例已创建（后续调用无需判断，但仍需加锁 / 解锁）
实现逻辑简单，易于理解高并发场景下，锁竞争会导致性能瓶颈（如秒杀系统中频繁调用单例类）
4. 适用场景

适用于低并发场景（如后台管理系统），且对资源占用敏感（需懒加载）的场景。若为高并发场景，需进一步优化锁粒度。

（四）双重检查锁（DCL）：优化锁粒度，兼顾安全与性能

双重检查锁（Double-Checked Locking，简称 DCL）是对 “线程安全版懒汉式” 的优化 —— 仅在实例未创建时加锁，实例创建后直接返回，大幅减少锁竞争，兼顾线程安全、懒加载和高性能。

1. 实现代码（正确版）
public class DclSingleton {
    // 关键：添加 volatile 关键字，禁止指令重排序
    private static volatile DclSingleton INSTANCE = null;
    
    private DclSingleton() {}
    
    public static DclSingleton getInstance() {
        // 第一次检查：实例已创建则直接返回（无锁，高性能）
        if (INSTANCE == null) {
            // 加锁：仅实例未创建时才加锁，减少锁竞争
            synchronized (DclSingleton.class) {
                // 第二次检查：防止多线程等待锁时重复创建实例
                if (INSTANCE == null) {
                    INSTANCE = new DclSingleton();
                }
            }
        }
        return INSTANCE;
    }
}
2. 核心关键点解析
（1）为什么需要 “双重检查”？
  • 第一次检查（无锁）：快速判断实例是否已存在，避免每次调用都加锁，提升性能；
  • 第二次检查（加锁后）：若多个线程同时通过第一次检查并等待锁，当第一个线程创建实例后，后续线程进入锁内时会发现实例已存在，避免重复创建。
（2）为什么需要 volatile 关键字？

这是 DCL 实现的核心细节，需从 new 操作的底层指令说起：

  • INSTANCE = new DclSingleton() 并非原子操作，实际会拆分为 3 步指令：
    1. 分配内存空间（memory = allocate()）；
    1. 初始化实例（ctorInstance(memory)）；
    1. 将实例引用指向内存空间（INSTANCE = memory）。
  • JVM 为优化性能，可能会对指令进行 “重排序”，导致步骤 2 和步骤 3 顺序颠倒（即先赋值引用，再初始化实例）；
  • 若未加 volatile，线程 A 执行 new 操作时，指令重排序后可能先将 INSTANCE 赋值为非 null（但实例未初始化），此时线程 B 通过第一次检查（INSTANCE != null）并直接返回未初始化的实例，导致程序异常。
  • volatile 关键字的作用：禁止指令重排序，确保步骤 2（初始化）完成后，再执行步骤 3（赋值引用），避免线程获取未初始化的实例。
3. 优缺点分析
优点缺点
兼顾线程安全、懒加载和高性能：仅初始化阶段加锁，后续调用无锁实现细节复杂（需理解双重检查逻辑和 volatile 作用），易因遗漏 volatile 导致 bug
高并发场景下性能优异（锁竞争极少）JDK 1.5 及以上才支持 volatile 禁止指令重排序（早期 JDK 版本存在缺陷）
初始化时可接收外部参数（如动态配置）无
4. 适用场景

最广泛的单例实现方式，适用于高并发场景（如 Web 服务、分布式系统），且对资源占用敏感（需懒加载）的场景，例如线程池、数据库连接池、缓存管理器等。

三、四种实现方式的对比与选型建议

为帮助开发者快速选择，下表从核心维度对四种实现方式进行对比：

实现方式线程安全懒加载高性能（高并发）实现复杂度JDK 版本要求
饿汉式是否是（无锁）低无
懒汉式（基础）否是是（无锁，但不安全）低无
懒汉式（安全）是是否（每次加锁）低无
双重检查锁（DCL）是是是（仅初始化加锁）中JDK 1.5+

选型建议

  1. 优先选 DCL：若需懒加载且面对高并发，DCL 是最优解（兼顾安全、性能和资源效率）；
  1. 次选饿汉式：若实例占用资源小、启动后必用，饿汉式实现简单且无任何隐患；
  1. 避免基础版懒汉式：多线程环境下完全不安全，仅单线程场景可临时使用；
  1. 慎选安全版懒汉式：低并发场景可接受，但高并发下性能瓶颈明显，建议替换为 DCL。

四、总结

单例模式的四种实现方式，本质是围绕 “何时创建实例” 和 “如何保证线程安全” 两个核心问题的权衡。饿汉式以 “提前创建” 换安全和性能，懒汉式以 “延迟创建” 换资源效率，而 DCL 则通过双重检查和 volatile 关键字，实现了三者的最优平衡。

在实际开发中，无需过度追求 “最复杂的实现”，而应根据资源占用大小、并发量高低和初始化时机需求选择合适的方案 —— 例如工具类用饿汉式，线程池用 DCL，低并发后台系统用安全版懒汉式。只有理解每种实现的底层逻辑和适用场景，才能真正发挥单例模式的价值，写出高效、安全的代码。

avatar
文章
阅读
粉丝