技术面试指南（Interview_Question_for_Beginner）设计模式篇：Java 单例模式（Singleton）的四种实现与线程安全演进
技术面试指南（Interview_Question_for_Beginner）设计模式篇：Java 单例模式（Singleton）的四种实现与线程安全演进
本文以 Interview_Question_for_Beginner 技术面试指南仓库中 DesignPattern/README.md 章节为绝对主体，系统讲解 Java 单例模式（Singleton Pattern）的必要性、实现三要素，以及从"非线程安全懒加载"到 synchronized 方法同步、volatile + DCL 双重检查锁定、类加载时提前初始化四种实现方案的完整演进脉络。读完本文，你不仅能从容回答"为什么需要单例""如何写出线程安全的单例"这类高频技术面试题，还能借助仓库中 Java 多线程编程资料 与 OS 进程同步资料 深入理解每版实现背后的并发原理。
一、为什么需要单例模式：适用场景与设计动机
Singleton pattern（单例模式）是在应用程序中只创建一个实例并复用它的设计模式，属于创建型模式（Creational Pattern），也是设计模式面试中入门必考的基础主题。
典型适用场景：连接池、线程池与设备配置对象
原文档明确指出，以下三类对象是单例模式的典型应用场景：
- 连接池（Connection Pool）：数据库连接对象的创建和销毁代价高昂，池中的连接应全局唯一管理；
- 线程池（Thread Pool）：线程的创建与销毁开销大，线程池实例应在整个应用生命周期内保持唯一；
- 设备设置对象（Device Settings Object）：硬件配置、应用配置等全局设置应只有一个权威来源。
多实例的代价：资源浪费与潜在 Bug
如果上述对象被创建多个实例，会带来两类严重问题：
- 资源浪费：重复持有连接、线程、配置副本，白白消耗内存与系统资源；
- 潜在 Bug：多个实例状态不一致，可能导致数据竞争、配置漂移等难以排查的并发问题。
因此，单例模式的核心目的就是：保证只有一个实例被创建，并让所有调用方共享该实例。
值得一提的是，本仓库主 README.md 的"Part 1. 计算机基础（전산 기초）"目录中，Design Pattern 章节目前聚焦的主题正是 Singleton，可见这是该仓库设计模式部分的基石内容。
二、单例模式的实现三要素
要保证"整个应用只有一个实例"，必须对实例的创建过程施加特殊约束。原文档给出了三条关键设计约束：
| 要素 | 实现方式 | 目的 |
|---|---|---|
| 私有构造函数 | private Singleton() {} |
阻断外部通过 new 关键字随意创建实例 |
| 静态工厂方法 | public static Singleton getInstance() |
提供获取唯一实例的入口 |
| 静态引用变量 | private static Singleton singletonObject |
持有（引用）唯一的单例对象 |
- 构造器私有化是单例的根基：
new无法被外部执行，实例创建权完全收归类内部； - 静态方法作为全局访问点，让所有调用方通过统一入口获取对象；
- 静态引用变量负责保存那个唯一的实例，供静态方法返回。
三、第一种实现：懒加载，但线程不安全
原文档给出的第一版实现如下：
public class Singleton {
private static Singleton singletonObject;
private Singleton() {}
public static Singleton getInstance() {
if (singletonObject == null) {
singletonObject = new Singleton();
}
return singletonObject;
}
}
这一版是经典的**懒加载（Lazy Initialization）**写法：实例在第一次调用 getInstance() 时才创建，之后复用。
但原文档用"这个代码真的很危险"来评价它。原因是：在多线程环境下，单例模式会出问题——当多个线程同时首次访问 getInstance() 时，可能发生竞态条件（Race Condition）：
- 线程 A 执行
if (singletonObject == null)，判断为null，进入 if 分支； - 在线程 A 执行
new Singleton()之前，线程 B 也执行了if (singletonObject == null)判断，同样看到null； - 线程 A、B 各自创建了一个实例。
结果就是：本应"只有一个"的实例被创建了两个，单例约束被打破。这正是连接池、线程池等场景中最需要避免的并发 Bug。
竞态条件的本质
从仓库 OS/README.md 的进程同步知识看，if (singletonObject == null) 判断加上对象创建这段代码，正是一个典型的临界区（Critical Section）——多个执行流同时访问同一共享资源（singletonObject）的代码区域。临界区问题需要满足**互斥（Mutual Exclusion）、进展（Progress）、有限等待（Bounded Waiting）**三个基本条件，而第一版实现一个都不满足。
四、第二种实现：synchronized 方法级同步
为了解决多线程竞争问题，原文档给出第二版实现——给 getInstance() 方法直接加上 synchronized 关键字：
public class Singleton {
private static Singleton singletonObject;
private Singleton() {}
public static synchronized Singleton getInstance() {
if (singletonObject == null) {
singletonObject = new Singleton();
}
return singletonObject;
}
}
synchronized 保证同一时刻只有一个线程能进入该方法，从而彻底解决了并发下创建多个实例的问题，多线程环境下的隐患被消除。
性能代价：每次调用都要拿锁
但原文档随即指出：使用 synchronized 关键字存在性能问题。
原因是 synchronized 修饰的是整个方法，意味着每次调用 getInstance()——包括单例早已创建好之后的所有只读返回操作——都要经历一次锁的获取与释放。在高并发、高频调用的场景下（例如连接池每次取连接的调用），这种不必要的加锁会显著拖慢吞吐。
仓库 Java/README.md 中关于 synchronized 的说明可以印证这一点：在方法上直接加锁，锁的是整个类实例，加锁范围越大，线程串行化的概率越高，性能影响越大。这也是原文档提出"能不能控制得更高效一些"这一追问的动机。
五、第三种实现：DCL 双重检查锁定（Double Checked Locking）
为了在保证线程安全的同时缩小加锁范围，原文档给出第三版实现——DCL（Double Checked Locking，双重检查锁定）：
public class Singleton {
private static volatile Singleton singletonObject;
private Singleton() {}
public static Singleton getInstance() {
if (singletonObject == null) {
synchronized (Singleton.class) {
if(singletonObject == null) {
singletonObject = new Singleton();
}
}
}
return singletonObject;
}
}
双重检查：外层判断 + 内层判断
这段代码的"双重检查"体现在两个 if (singletonObject == null)：
- 外层检查（无锁）：单例已创建时，绝大多数调用直接通过判断返回，完全不需要进入同步块，同步区域被显著缩小；
- 内层检查（持锁）：多个线程同时通过外层检查时，只有拿到锁的线程真正创建实例，其余线程在进入同步块后再次检查，发现实例已存在便直接返回。
原文档明确评价：使用 DCL 后，"getInstance() 中同步化的区域可以被缩小"，既保留了懒加载（初始时不创建对象），又把加锁的粒度做到最小。
多核环境下的问题：为什么必须有 volatile
然而原文档接着指出了 DCL 的一个隐患：这段代码在多核环境下运行时，除了一个 CPU 之外，其他 CPU 会陷入锁竞争/等待状态——即各线程所在的 CPU 核心可能持有对 singletonObject 的旧缓存值，导致判断失真、锁竞争加剧。
这正是字段上 volatile 关键字存在的原因。原文档末尾的 cf 说明给出了精确定义：
volatile：防止编译器（优化器）对特定变量应用缓存优化的关键字。
也就是说，volatile 禁止了编译器/CPU 将 singletonObject 缓存到寄存器或核内缓存，保证一个线程对单例引用的写入，对其他线程立即可见（内存可见性），同时配合 JVM 内存模型禁止指令重排，避免其他线程"看到"一个尚未构造完成的对象。可以推断：没有 volatile 的 DCL 在旧版内存模型下是不完整、不可靠的。
六、第四种实现：类加载时提前初始化（饿汉式）
由于 DCL 写法仍然存在多核环境下的锁竞争与复杂度，原文档给出第四种、也是最简洁的方案——在类加载时提前创建对象：
public class Singleton {
private static volatile Singleton singletonObject = new Singleton();
private Singleton() {}
public static Singleton getSingletonObject() {
return singletonObject;
}
}
原文档对这一版的解释是："在类加载的时间点预先创建好对象，然后直接返回该对象。"
为什么它天然线程安全
从 JVM 语义可以推断：类的加载与初始化阶段是 JVM 内部串行化处理的过程，多个线程首次使用该类时会等待其初始化完成。因此，静态字段在类加载时完成的初始化天然具备线程安全性，不需要任何显式加锁，也不存在竞态条件。
这一版本的优势显而易见：
- 无
synchronized，无锁竞争，读取性能最优； - 代码最简单，实现与维护成本最低；
- 无需判断，
getInstance直接返回已就绪的实例。
对应的取舍是：实例在类被加载时（甚至可能尚未被真正使用前）就被创建，属于"饿汉式"（Eager Initialization），若该单例创建成本高且实际很少被用到，会产生无谓的资源占用——这需要结合具体场景权衡。
小提示：原文档中这一版的访问方法名写作
getSingletonObject()，与前几版的getInstance()略有差异，这并不影响其单例语义；在工程实践中建议统一命名规范。
七、volatile 关键字补遗
原文档在四种实现之后，专门以 cf（参考）形式补充了 volatile 的定义，这是理解 DCL 写法的关键，单独展开如下：
- 语义：
volatile是 Java 的关键字，用于修饰变量； - 作用：禁止编译器优化器对该变量应用缓存优化——即不把变量值缓存在寄存器或 CPU 缓存中，每次读写都直接作用于主内存；
- 在多线程中的价值：保证一个线程对
volatile变量的修改，能被其他线程立即感知（可见性），这正是 DCL 版本中单例引用跨线程可见的保障； - 适用前提：
volatile解决的是"可见性"问题，并不替代synchronized的"互斥"能力——因此在 DCL 中，对象创建动作仍需要synchronized块来保证"同一时刻只有一个线程执行new"。
原文档中，volatile 在 DCL 版本与类加载初始化版本中均被保留修饰，可见其在单例线程安全写法中的重要性。
八、仓库源码纵深：单例、多线程与并发同步
单例模式在多线程环境下的安全性，与仓库其他章节的内容相互印证。以下结合本仓库的 Java/README.md 与 OS/README.md 做纵深展开。
1. 单例对象的字段状态问题
Java/README.md 的"Field member"一节给出了与单例直接相关的警示：
如果对象是被多个线程访问的单例对象，就不应该在字段（field）中保存状态值；所有变量都应通过参数传入、通过返回值传出。
这从使用侧印证了单例的线程安全实践：单例天然被多线程共享，一旦在实例字段中保存可变状态，就会引发并发数据竞争。因此，线程安全的单例不仅要求"只创建一个实例"，还要求"实例内部无共享可变状态"，这是面试中经常延伸考察的点。
2. synchronized 的方法锁与块锁
Java/README.md 明确指出 synchronized 的两种用法差异：
- 加在方法上：对该类实例（class instance）整体加锁，锁范围最大；
- 加在代码块上：仅对块包裹的区间加锁。
对照本文的第二种与第三种实现：方法级同步对应"整方法加锁"，DCL 则改用 synchronized (Singleton.class) 块锁，把锁的范围收敛到"仅在首次创建时需要"。原文档"同步化区域可以被缩小"的说法，正是对块锁价值的直接体现。
3. 多线程环境下的集合容器选型
Java/README.md 还给出了单例对象若不得不持有集合字段时的容器选型路径：
- 线程安全但 API 少、性能一般的：
Vector（替代List）、HashTable（替代Map）； - 通过工具类包装：
Collections.synchronizedList()、Collections.synchronizedSet()、Collections.synchronizedMap()； - JDK 1.7 起引入的
ConcurrentHashMap：同步范围更窄、性能更好。
这组资料可以作为单例持有共享容器时的扩展知识，但结合第 1 点的结论，最稳妥的做法仍然是：避免单例持有可变集合状态。
4. OS 层面的并发原语：临界区、互斥锁、信号量与监视器
单例线程安全背后的原理，最终落到操作系统进程同步层面。OS/README.md 的系统性讲解构成了完整的底层知识链：
- 临界区（Critical Section）：多线程同时访问共享资源的代码区域，本节中的
getInstance()判断与创建逻辑正是临界区； - 互斥锁（Mutex Lock）：进入临界区前获取锁、退出时释放锁，与 Java
synchronized的语义一一对应； - 信号量（Semaphore）：二值信号量即互斥锁（MUTEX），计数信号量用于控制有限资源的并发访问——连接池、线程池这类单例场景恰好就是"有限资源"；
- 监视器（Monitor）：高级语言（如 Java）内建的抽象，自动处理"获取锁 → 访问共享资源 → 释放锁"全过程，开发者无需手工释放——
synchronized正是基于监视器机制实现的。
理解了这一层，就能把"为什么 synchronized 能保证单例线程安全""为什么过度的锁会带来性能瓶颈"回答到操作系统原理的高度。
九、四种实现对比与面试常见追问
实现方式对比
| 实现方案 | 初始化时机 | 线程安全 | 同步开销 | 特点与取舍 |
|---|---|---|---|---|
| 懒加载（无同步） | 首次调用 getInstance() |
否 | 无 | 实现最简单，但多线程下可能创建多个实例 |
synchronized 方法 |
首次调用 getInstance() |
是 | 每次调用都加锁 | 线程安全但性能差，同步范围过大 |
volatile + DCL |
首次调用 getInstance() |
是（配合 volatile） |
仅首次创建时加锁 | 兼顾懒加载与性能，但实现复杂，多核下仍有锁竞争 |
| 类加载时初始化（饿汉式） | 类加载时 | 是 | 无 | 无锁无竞争、代码最简，但实例创建时机提前 |
常见追问
基于本文内容，技术面试中围绕单例的高频追问通常包括：
- 为什么
synchronized方法版本性能差？（同步范围过大，每次调用都串行化） - DCL 为什么需要
volatile？去掉会怎样？（可见性与指令重排问题，见第七节） - 懒加载与饿汉式各自的适用场景？（延迟初始化 vs 简单可靠）
- 多线程访问单例时，字段中能否保存状态？（不能，见第八节第 1 点）
synchronized与volatile解决的是同一个问题吗？（互斥 vs 可见性）
十、小结
单例模式是设计模式面试的入门必考题，也是实际工程中连接池、线程池、全局配置等场景的基石。本仓库 DesignPattern/README.md 以一条清晰的演进线——非线程安全懒加载 → 方法级同步 → DCL 双重检查锁定 → 类加载时初始化——展示了"线程安全"与"性能"这对矛盾如何被逐步化解：同步方法解决了安全问题但牺牲性能，DCL 用块锁收窄了同步范围，饿汉式则借助 JVM 类加载机制在无锁前提下彻底解决了竞争。配合仓库 Java/README.md 的多线程实践与 OS/README.md 的并发原语，你可以把这一知识点从"背代码"提升到"讲原理"的层次，这正是技术面试中最有价值的能力。