夏骁凯1. 单例模式的两个经典实现方式
在面向对象编程中，单例模式是最常用的设计模式之一。它确保一个类只有一个实例，并提供一个全局访问点。而懒汉模式(Lazy Initialization)和饿汉模式(Eager Initialization)是单例模式的两种经典实现方式，它们的核心区别在于实例创建的时机。
我曾在多个项目中遇到过需要严格控制实例数量的场景。比如在一个电商平台的优惠券系统中，优惠券发放服务必须保证全局唯一，否则可能导致重复发放；又比如在游戏开发中，场景管理器也需要确保唯一性。这些场景下，正确选择单例模式的实现方式至关重要。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 饿汉模式：急不可待的实例化
2.1 基本实现原理
饿汉模式的特点是类加载时就立即创建实例。这种实现方式简单直接，代码示例如下：
java复制public class EagerSingleton {
// 类加载时就初始化
private static final EagerSingleton instance = new EagerSingleton();
// 私有化构造函数
private EagerSingleton() {}
public static EagerSingleton getInstance() {
return instance;
}
}
这种实现的关键点在于：
- 使用static final修饰实例变量，保证在类加载时就初始化
- 私有化构造函数，防止外部通过new创建实例
- 提供静态的getInstance方法作为全局访问点
2.2 优缺点分析
饿汉模式的主要优点：
- 实现简单，代码直观
- 线程安全，因为实例在类加载时就已创建
- 没有同步开销，性能较好
但它的缺点也很明显：
- 如果实例创建开销大但又不一定会被使用，会造成资源浪费
- 无法处理实例化时需要传入参数的情况
- 类加载时就初始化，可能影响程序启动速度
在实际项目中，我一般会在以下场景选择饿汉模式：
- 实例创建开销小
- 程序运行期间一定会用到该实例
- 对启动时间不敏感的应用
3. 懒汉模式：按需创建的智慧
3.1 基础实现与线程安全问题
懒汉模式的特点是延迟实例化，只有在第一次请求实例时才创建。基础实现如下：
java复制public class LazySingleton {
private static LazySingleton instance;
private LazySingleton() {}
public static LazySingleton getInstance() {
if (instance == null) {
instance = new LazySingleton();
}
return instance;
}
}
这种实现方式看似合理，但在多线程环境下会出现问题。当多个线程同时检查instance为null时，可能会创建多个实例。我在早期项目中就曾因此遇到过难以追踪的bug。
3.2 线程安全的改进方案
为了解决线程安全问题，常见的改进方式有：
- 同步方法（简单但效率低）：
java复制public synchronized static LazySingleton getInstance() {
if (instance == null) {
instance = new LazySingleton();
}
return instance;
}
- 双重检查锁定（推荐方式）：
java复制public static LazySingleton getInstance() {
if (instance == null) {
synchronized (LazySingleton.class) {
if (instance == null) {
instance = new LazySingleton();
}
}
}
return instance;
}
- 静态内部类方式（最优实现）：
java复制public class LazySingleton {
private static class Holder {
static final LazySingleton INSTANCE = new LazySingleton();
}
public static LazySingleton getInstance() {
return Holder.INSTANCE;
}
}
静态内部类方式是我最推荐的做法，它既实现了延迟加载，又保证了线程安全，还没有同步开销。
3.3 适用场景分析
懒汉模式特别适合以下场景：
- 实例创建开销大
- 不一定会被使用的单例
- 需要运行时参数初始化的单例
- 对启动性能敏感的应用
在微服务架构中，很多服务的客户端（如数据库连接池）就常采用懒汉模式实现单例，避免服务启动时建立过多不必要的连接。
4. 两种模式的深度对比与实践选择
4.1 关键特性对比
| 特性 | 饿汉模式 | 懒汉模式 |
|---|---|---|
| 实例化时机 | 类加载时 | 第一次调用getInstance时 |
| 线程安全 | 天然安全 | 需要额外处理 |
| 性能 | 无同步开销 | 可能有同步开销 |
| 资源利用 | 可能浪费 | 按需使用 |
| 实现复杂度 | 简单 | 相对复杂 |
| 异常处理 | 受限 | 更灵活 |
4.2 实际项目中的选择策略
根据我的项目经验，选择模式时需要考虑以下因素：
-
实例创建成本：如果创建成本高（如需要加载大文件、建立网络连接），优先考虑懒汉模式
-
使用频率：如果该实例在程序运行期间一定会被使用，饿汉模式更合适
-
启动时间要求：对启动时间敏感的应用，懒汉模式可以分散初始化压力
-
线程安全要求：如果项目对线程安全要求极高，饿汉模式更可靠
-
测试便利性：懒汉模式更容易在测试中重置实例状态
在Spring框架中，默认的单例bean实际上是类似饿汉模式的实现，但通过三级缓存等机制解决了循环依赖问题。而在Android开发中，由于资源受限，更多采用懒汉模式延迟初始化。
5. 进阶话题与常见误区
5.1 序列化与反序列化问题
即使实现了单例模式，序列化和反序列化也可能破坏单例特性。解决方案是实现readResolve方法：
java复制protected Object readResolve() {
return getInstance();
}
5.2 反射攻击防护
通过反射可以调用私有构造函数，破坏单例。防御方式是在构造函数中添加检查：
java复制private LazySingleton() {
if (instance != null) {
throw new IllegalStateException("Already initialized");
}
}
5.3 枚举单例：更好的选择？
从Java 5开始，枚举类型成为了实现单例的最佳实践：
java复制public enum EnumSingleton {
INSTANCE;
public void doSomething() {
// ...
}
}
枚举单例天然防止了反射攻击和序列化问题，代码也更简洁。我在新项目中已经全面转向使用枚举实现单例。
5.4 常见误区警示
-
认为单例模式必须用private构造函数：实际上也可以通过工厂方法等方式实现
-
过度使用单例：单例本质上是全局状态，滥用会导致代码难以测试和维护
-
忽略依赖注入：在现代框架中，通常用依赖注入容器管理单例更合适
-
线程安全考虑不足：特别是懒汉模式的各种变体，需要仔细评估线程安全性
在分布式系统中，单例模式的应用需要特别小心，因为传统的单例实现只能保证在单个JVM内的唯一性。这时可能需要借助分布式锁或外部存储来实现集群范围内的单例。