在日常开发中，你是否遇到过这样的问题：数据库连接池创建过多导致内存溢出？日志工具类实例不唯一导致日志错乱？这些问题的根源往往是对象实例未被正确控制，而单例模式正是解决这类问题的 "特效药"。
一、为什么需要单例模式？
单例模式是最常用的设计模式之一，核心目标是保证一个类在整个应用中仅有一个实例，并提供全局访问点。
存在的痛点
重复创建重量级对象（如数据库连接池、线程池）会浪费内存和 CPU 资源；
多实例可能导致数据不一致（如配置文件同时被多个实例修改）；
全局工具类若实例不唯一，会增加组件间通信成本。
典型使用场景
工具类（如日志工具、日期工具）；
资源密集型对象（数据库连接池、线程池、缓存）；
全局配置管理（应用配置类、常量类）；
硬件资源访问（打印机驱动、摄像头控制）；
账户登录系统（确保同一账号仅登录一次）。
二、单例模式的核心实现原则
要实现一个标准的单例模式，必须满足 3 个核心条件，缺一不可：
私有构造函数 ：禁止外部通过 new 关键字创建实例，从源头控制实例数量；
静态私有实例：在类内部维护唯一的实例对象，确保全局唯一性；
公共静态访问方法 ：提供全局获取实例的接口（如 getInstance()），隐藏实例创建细节。
三、6 种常见实现方式及代码实战
单例模式有多种实现方式，不同方式在线程安全 、延迟加载 和实现复杂度上各有优劣，实际开发中需按需选择。
1. 饿汉式（Eager Initialization）
特点：类加载时立即初始化实例，天然线程安全，但可能提前占用资源。
csharp
复制代码
public class EagerSingleton {
// 静态私有实例（类加载时初始化，JVM保证线程安全）
private static final EagerSingleton INSTANCE = new EagerSingleton();
// 私有构造函数：禁止外部创建实例
private EagerSingleton() {}
// 公共访问方法：返回唯一实例
public static EagerSingleton getInstance() {
return INSTANCE; // 注意：原代码此处拼写错误（INSANCE→INSTANCE）
}
}
适用场景 ：实例占用资源少（如工具类），或程序启动时必须初始化（如配置加载）。优缺点：线程安全无需额外处理，但未使用时也会占用内存，不适合重量级对象。
2. 懒汉式（Lazy Initialization）
特点：首次使用时才初始化实例（延迟加载），但需手动处理线程安全问题。
2.1 基础懒汉式（非线程安全）
csharp
复制代码
public class LazySingletonUnsafe {
private static LazySingletonUnsafe instance;
private LazySingletonUnsafe() {}
// 多线程下可能创建多个实例（无锁保护）
public static LazySingletonUnsafe getInstance() {
if (instance == null) {
// 线程A和线程B同时进入此处，会创建两个实例
instance = new LazySingletonUnsafe();
}
return instance;
}
}
问题 ：多线程环境下，若两个线程同时执行 if (instance == null)，会创建多个实例，违反单例原则。适用场景：仅单线程环境（几乎不用，仅作反面案例）。
2.2 同步方法懒汉式（线程安全但性能差）
csharp
复制代码
public class LazySingletonSyncMethod {
private static LazySingletonSyncMethod instance;
private LazySingletonSyncMethod() {}
// 同步方法保证线程安全，但每次调用都加锁，性能开销大
public static synchronized LazySingletonSyncMethod getInstance() {
if (instance == null) {
instance = new LazySingletonSyncMethod();
}
return instance;
}
}
优化点 ：通过 synchronized 关键字保证线程安全，避免多实例问题。缺点 ：每次调用 getInstance() 都会触发锁竞争，即使实例已初始化，导致性能下降（适合并发量极低的场景）。
2.3 双重检查锁定（DCL，推荐）
核心优化 ：减少锁粒度，仅在实例未初始化时加锁，并用 volatile 禁止指令重排序。
csharp
复制代码
public class LazySingletonDCL {
// volatile 作用：1. 保证实例可见性；2. 禁止指令重排序
private static volatile LazySingletonDCL instance;
private LazySingletonDCL() {}
public static LazySingletonDCL getInstance() {
// 第一次检查：未加锁，快速判断实例是否已初始化（减少锁竞争）
if (instance == null) {
// 加锁：仅在可能创建实例时同步
synchronized (LazySingletonDCL.class) {
// 第二次检查：防止多线程同时通过第一次检查后重复创建
if (instance == null) {
instance = new LazySingletonDCL();
}
}
}
return instance;
}
}
**为什么需要双重检查？**假设线程 A 和线程 B 同时通过第一次检查，线程 A 先获取锁并创建实例，线程 B 获取锁后若不再次检查，会重复创建实例。为什么需要 volatile？ new LazySingletonDCL() 实际分为 3 步：分配内存→初始化实例→引用指向内存。若发生指令重排序，可能导致线程获取到 "未初始化完成的实例"，volatile 可禁止这种重排序。适用场景：多线程环境下的延迟加载场景（最常用的实现方式之一）。
3. 静态内部类（Holder 模式）
特点：利用 JVM 类加载机制实现延迟加载和线程安全，性能优异。
csharp
复制代码
public class StaticInnerClassSingleton {
// 静态内部类：仅在调用 getInstance() 时才会被加载
private static class SingletonHolder {
// 内部类中初始化实例，JVM保证线程安全
private static final StaticInnerClassSingleton INSTANCE = new StaticInnerClassSingleton();
}
// 原代码此处类名拼写错误（StaticIneerClassSingleton→StaticInnerClassSingleton）
private StaticInnerClassSingleton() {}
public static StaticInnerClassSingleton getInstance() {
// 调用时触发内部类加载，初始化实例
return SingletonHolder.INSTANCE;
}
}
核心原理 ：JVM 规定，静态内部类不会在外部类加载时初始化，仅在首次被引用时加载，且类加载过程是线程安全的。优缺点：延迟加载 + 线程安全 + 无锁开销，性能优于 DCL，但无法防止反射和序列化攻击。
4. 枚举（防止反射和序列化攻击，最安全）
特点：通过枚举特性天然实现单例，代码简洁且能抵御反射和序列化攻击。
csharp
复制代码
public enum EnumSingleton {
INSTANCE; // 枚举常量即为唯一实例
// 枚举可包含业务方法
public void doSomething() {
System.out.println("执行单例任务");
}
}
// 使用方式
EnumSingleton.INSTANCE.doSomething();
**为什么枚举能防反射？**JVM 禁止通过反射调用枚举的构造函数（Constructor.newInstance() 会抛 IllegalArgumentException）。**为什么枚举能防序列化？**枚举的反序列化由 JVM 特殊处理，readObject() 会直接返回已有的枚举实例，不会创建新对象。适用场景：对安全性要求高的场景（如权限管理、核心配置），推荐优先使用。
5. 容器式单例（统一管理多实例）
特点：通过容器管理多个单例实例，适合需要维护大量单例的场景（如 Spring 容器）。
java
复制代码
import java.util.Map;
import java.util.Objects;
import java.util.concurrent.ConcurrentHashMap;
public class ContainerSingleton {
// 用ConcurrentHashMap保证线程安全
private final Map
// 根据beanName获取对应单例实例
public Object getSingletonInstance(String beanName) {
Object bean = singletonMap.get(beanName);
if (Objects.isNull(bean)) {
// 若实例不存在，创建后放入容器（putIfAbsent保证原子性）
bean = new Object(); // 实际场景中应根据beanName创建对应实例
Object existing = singletonMap.putIfAbsent(beanName, bean);
// 若并发时已有其他线程创建实例，取已存在的实例
if (Objects.nonNull(existing)) {
bean = existing;
}
}
return bean;
}
}
核心思想 ：将多个单例实例统一存放在容器中，通过 key 获取，避免硬编码多个单例类。实际应用：Spring 容器默认将 Bean 定义为单例，正是通过类似容器式单例的机制管理实例（结合了依赖注入 DI）。
四、6 种实现方式对比表
实现方式
线程安全
延迟加载
防反射 / 序列化
性能
适用场景
饿汉式
✅ 安全
❌ 否
❌ 不支持
高
轻量级实例、启动必加载
基础懒汉式
❌ 不安全
✅ 是
❌ 不支持
高
单线程环境（不推荐）
同步方法懒汉式
✅ 安全
✅ 是
❌ 不支持
低
并发量极低的场景
双重检查锁定（DCL）
✅ 安全
✅ 是
❌ 需额外处理
高
多线程延迟加载（推荐）
静态内部类
✅ 安全
✅ 是
❌ 需额外处理
高
性能优先的延迟加载场景
枚举
✅ 安全
✅ 是
✅ 天然支持
高
安全性要求高的场景（首选）
容器式单例
✅ 安全
✅ 是
❌ 需额外处理
高
多单例统一管理（如框架场景）
五、单例模式的优缺点
优点
资源优化：避免重复创建实例，减少内存占用和对象初始化开销；
全局访问：通过统一接口获取实例，简化组件间通信（如日志器无需层层传递）；
数据一致：确保全局状态唯一（如配置信息修改后全应用可见）。
缺点
违反单一职责原则：单例类既负责业务逻辑，又负责实例管理，职责过重；
测试困难：单例实例在测试中难以 Mock，可能导致测试用例依赖全局状态；
扩展性差：私有构造函数导致单例类通常无法被继承（部分实现可通过反射绕过，但不推荐）；
隐藏依赖 ：全局访问点可能导致代码耦合度升高（如多处直接调用 getInstance()）。
六、实战避坑指南
1. 防止反射攻击
非枚举实现的单例可能被反射破坏（通过 setAccessible(true) 强制调用私有构造函数）：
ini
复制代码
// 反射攻击示例（针对非枚举单例）
Constructor
constructor.setAccessible(true);
LazySingletonDCL hackedInstance = constructor.newInstance(); // 创建新实例
防护方案：在私有构造函数中添加校验，若实例已存在则抛异常：
csharp
复制代码
private LazySingletonDCL() {
if (instance != null) {
throw new RuntimeException("禁止通过反射创建实例");
}
}
2. 防止序列化攻击
非枚举单例在序列化后反序列化时，可能创建新实例（破坏单例）：
ini
复制代码
// 序列化攻击示例
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("singleton.obj"));
oos.writeObject(LazySingletonDCL.getInstance());
ObjectInputStream ois = new ObjectInputStream(new FileInputStream("singleton.obj"));
LazySingletonDCL deserializedInstance = (LazySingletonDCL) ois.readObject(); // 新实例
防护方案 ：重写 readResolve() 方法，返回已有实例：
typescript
复制代码
private Object readResolve() {
return getInstance(); // 反序列化时返回现有实例
}
3. 多线程下的状态管理
单例实例若包含可变状态（如计数器、缓存 Map），多线程修改时需加锁保护：
csharp
复制代码
public class SafeStateSingleton {
private static volatile SafeStateSingleton instance;
private int count; // 可变状态
private SafeStateSingleton() {}
public static SafeStateSingleton getInstance() {
// DCL 实现...
}
// 多线程修改状态需加锁
public synchronized void increment() {
count++;
}
}
4. 框架中的单例：以 Spring 为例
Spring 容器默认将 Bean 定义为单例（singleton 作用域），但通过依赖注入（DI）解耦了单例的创建和使用：
less
复制代码
// Spring 单例Bean示例
@Component
public class UserService {
// Spring 容器会确保UserService仅有一个实例
}
// 使用时通过注入获取，而非直接调用getInstance()
@Controller
public class UserController {
@Autowired
private UserService userService; // 注入单例实例
}
优势：无需手动实现单例逻辑，框架自动管理实例生命周期，降低出错风险。
七、总结：如何选择合适的实现方式？
单例模式的核心是控制实例唯一性，选择实现方式时需遵循以下原则：
优先用枚举：简单、安全，天然防反射和序列化，适合大多数场景；
延迟加载选 DCL 或静态内部类：DCL 适合多线程延迟加载，静态内部类性能更优；
框架场景用容器式：如 Spring 的 Bean 管理，统一维护多单例实例；
避免过度使用：单例是 "全局状态" 的一种形式，过度使用会导致代码耦合升高。
掌握单例模式不仅能解决实际开发中的资源管理问题，更是面试中的高频考点。理解每种实现的原理和优缺点，才能在不同场景中灵活应用，写出既安全又高效的代码。
最后，你在项目中用过哪种单例实现？遇到过哪些坑？欢迎在评论区分享～
