从“能跑”到“安全”：单例的基础实现与线程安全方案
单例模式的核心就是“保证一个类只有一个实例，并且提供全局访问点”，听着简单，但实现起来坑可不少。我先带你从最基础的写法入手，再一步步解决面试高频的线程安全问题。
基础写法先吃透：懒汉式vs饿汉式
最开始学单例时，我以为“饿汉式”和“懒汉式”就是两个名字，用起来没差，直到有次帮学弟改代码才发现，选错实现方式可能直接导致线上bug。
饿汉式就像“提前打包好行李”，类加载时就创建实例，代码特简单：
public class HungrySingleton {
private static final HungrySingleton instance = new HungrySingleton();
private HungrySingleton() {} // 私有构造器，防止外部new
public static HungrySingleton getInstance() {
return instance;
}
}
这种方式线程安全（类加载时只会初始化一次），但问题是如果实例一直用不上，就白占内存——比如一个工具类单例，用户可能整个流程都用不到，却在程序启动时就加载了，浪费资源。
懒汉式则是“按需打包”，用到时才创建实例，看似更灵活：
public class LazySingleton {
private static LazySingleton instance;
private LazySingleton() {}
public static LazySingleton getInstance() {
if (instance == null) { // 第一次调用才创建
instance = new LazySingleton();
}
return instance;
}
}
但你千万别在多线程环境用这个“裸奔版”！我之前帮朋友排查过一个线上问题：他用了这种懒汉式单例管理用户会话，结果高并发时多个线程同时进入if (instance == null)，硬生生创建了3个实例，导致用户数据串了。后来查日志发现，同一时间有5个线程都通过了空判断，这就是典型的线程不安全。
线程安全怎么破？从“加锁”到“优雅方案”
既然懒汉式裸奔不行，最直接的想法就是“加锁”——给getInstance()方法加synchronized：
public static synchronized LazySingleton getInstance() { // 加锁
if (instance == null) {
instance = new LazySingleton();
}
return instance;
}
这下线程安全了，但问题是每次调用都要加锁释放锁，性能太差。比如一个单例工具类被频繁调用，加锁会成为性能瓶颈。我之前在一个支付项目里试过，这种方式比不加锁慢了近10倍，后来果断换了方案。
面试时面试官肯定会追问：“有没有既安全又高效的写法？”这时候你就得搬出双重检查锁定（DCL） 了。原理是“先判断实例是否存在，不存在再加锁创建”，减少加锁次数：
public class DCLSingleton {
private static volatile DCLSingleton instance; // 注意volatile
private DCLSingleton() {}
public static DCLSingleton getInstance() {
if (instance == null) { // 第一次检查（不加锁）
synchronized (DCLSingleton.class) { // 加锁
if (instance == null) { // 第二次检查（加锁后）
instance = new DCLSingleton();
}
}
}
return instance;
}
}
这里有个坑：instance必须用volatile修饰！我见过很多人漏写这个关键字，结果还是出问题。因为instance = new DCLSingleton()这句代码，在JVM里可能被拆成“分配内存→初始化对象→赋值给引用”三步，不加volatile可能出现“指令重排”，导致一个线程拿到还没初始化完的实例，调用方法时直接报错。
如果觉得DCL还是复杂，静态内部类实现是更优雅的选择。我个人在项目里最爱用这个，代码简洁还自带线程安全：
public class InnerClassSingleton {
private InnerClassSingleton() {}
// 静态内部类，只有被调用时才加载
private static class SingletonHolder {
private static final InnerClassSingleton instance = new InnerClassSingleton();
}
public static InnerClassSingleton getInstance() {
return SingletonHolder.instance; // 调用时才加载内部类并创建实例
}
}
这种方式利用Java的“类加载机制”保证线程安全：静态内部类SingletonHolder只有在getInstance()被调用时才会加载，且类加载过程是线程安全的。既实现了延迟加载，又不用自己加锁，简直是“懒人福音”。
为了让你更清晰对比，我整理了一张表格，你可以根据场景选择：
| 实现方式 | 线程安全 | 延迟加载 | 优点 | 缺点 |
|---|---|---|---|---|
| 饿汉式 | 是 | 否 | 简单，无锁 | 可能浪费内存 |
| 懒汉式（synchronized） | 是 | 是 | 安全，简单 | 性能差，每次加锁 |
| 双重检查锁定 | 是（需volatile） | 是 | 高效，安全 | 实现复杂，易漏volatile |
| 静态内部类 | 是 | 是 | 优雅，无锁，安全 | 无法传参（构造器无参） |
表格里没列出来的还有一种“终极方案”——枚举单例，《Effective Java》作者Joshua Bloch强烈推荐的写法，几行代码搞定所有问题：
public enum EnumSingleton {
INSTANCE; // 唯一实例
// 业务方法
public void doSomething() {}
}
枚举天生线程安全，还能防止反射和序列化破坏，简直是“懒人神器”。我去年在一个电商项目里用枚举实现了订单号生成器，不管多少并发，实例永远只有一个，比之前用DCL省心多了。
避坑指南：别让单例“死”在反射和序列化手里
学会了实现方式，你以为就完了？太天真！面试时面试官还会问：“你的单例真的安全吗？反射能破坏它吗？”我之前就栽过这个坑——自以为用了静态内部类很安全，结果被面试官一句话问懵：“我用反射调用私有构造器，能不能创建新实例？”
还真能！比如你写了个静态内部类单例，我用反射就能“暴力破解”：
// 反射攻击示例
Class> clazz = StaticInnerClassSingleton.class;
Constructor> constructor = clazz.getDeclaredConstructor();
constructor.setAccessible(true); // 跳过访问检查
StaticInnerClassSingleton instance2 = (StaticInnerClassSingleton) constructor.newInstance();
这时候instance2和原来的单例实例根本不是一个对象！怎么防？你可以在构造器里加个判断：
private StaticInnerClassSingleton() {
if (SingletonHolder.instance != null) { // 已有实例，抛异常
throw new IllegalStateException("单例实例已存在，禁止创建多个！");
}
}
我朋友的项目就吃过这个亏，之前没加判断，被测试用反射搞出了bug，加上这段代码后，反射攻击直接抛出异常，安全多了。
另一个“隐形杀手”是序列化。如果你的单例实现了Serializable接口，序列化后再反序列化，会得到一个新实例！比如：
// 序列化破坏示例
Singleton instance = Singleton.getInstance();
// 序列化
ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("singleton.obj"));
oos.writeObject(instance);
// 反序列化
ObjectInputStream ois = new ObjectInputStream(new FileInputStream("singleton.obj"));
Singleton instance2 = (Singleton) ois.readObject();
// instance != instance2！
解决办法也简单，在单例类里重写readResolve()方法：
private Object readResolve() {
return getInstance(); // 返回已有实例，而不是新创建的
}
这样反序列化时就会用你返回的单例实例，而不是新创建的对象。我之前在一个日志工具类里遇到过这个问题，日志文件老是被多个实例同时写入，加上readResolve()后才恢复正常。
实战案例：单例在项目里怎么用才不踩坑？
说了这么多理论，咱来点实际的——单例在项目里到底能干嘛？我 了两个最常用的场景，你可以直接套用。
场景一：配置管理类
项目里的数据库连接信息、API密钥这些配置，通常只需要加载一次，用单例再合适不过。我之前做的一个CMS系统，用静态内部类实现了ConfigManager：
public class ConfigManager {
private Properties props; // 配置信息
private ConfigManager() {
loadConfig(); // 加载配置文件
}
private static class Holder {
private static final ConfigManager instance = new ConfigManager();
}
public static ConfigManager getInstance() {
return Holder.instance;
}
private void loadConfig() {
// 加载application.properties
props = new Properties();
try (InputStream in = getClass().getResourceAsStream("/application.properties")) {
props.load(in);
} catch (IOException e) {
throw new RuntimeException("加载配置文件失败", e);
}
}
public String getProperty(String key) {
return props.getProperty(key);
}
}
这样整个应用启动时，配置只加载一次，哪里需要配置就调用ConfigManager.getInstance().getProperty("db.url")，既方便又安全。
场景二：日志工具类
日志工具需要保证写入日志时不会出现并发问题，单例就能派上用场。我之前用枚举实现了一个Logger：
public enum Logger {
INSTANCE;
private FileWriter writer;
private Logger() {
try {
writer = new FileWriter("app.log", true); // 追加写入
} catch (IOException e) {
throw new RuntimeException("初始化日志失败", e);
}
}
public void log(String message) {
try {
writer.write("[" + LocalDateTime.now() + "] " + message + "n");
writer.flush();
} catch (IOException e) {
e.printStackTrace();
}
}
}
不管多少地方调用Logger.INSTANCE.log("用户登录")，日志都会按顺序写入，不会出现多个实例抢着写导致日志错乱的情况。
最后给你个小 面试时被问到单例，别只说“我会写懒汉式、饿汉式”，主动提一句“在实际项目中，我更推荐用枚举或静态内部类，既能保证线程安全，又能防止反射和序列化破坏”，面试官绝对对你刮目相看。
如果你按这些方法试了，或者在项目中遇到了单例相关的问题，欢迎回来留言告诉我，咱们一起讨论怎么解决！
单例模式在实际开发里其实用得挺多的，尤其是那些需要“独一无二”实例的场景，你想想，要是一个类随便就能new出好几个对象，不仅浪费内存，还可能出各种幺蛾子。最常见的就是配置管理类，比如项目里的全局配置——数据库连接地址、API密钥、系统参数这些，总不能每个模块用的时候都去读一遍配置文件吧？用单例模式把配置加载一次，整个项目哪里都能直接调用，既省时间又避免配置不一致，我之前帮一个小项目改代码，把分散的配置读取改成单例管理后，启动速度都快了不少。
日志工具类也是单例的“老搭档”，你想啊，要是日志工具能new多个实例，同时往一个日志文件里写内容，不就乱套了？不是这条日志被截断，就是那条日志顺序颠倒，排查问题的时候能把人逼疯。用单例模式保证日志工具只有一个实例，所有地方写日志都走同一个“出口”，日志内容就能整整齐齐按顺序来。还有线程池、数据库连接池这些“重量级”资源，要是允许创建多个实例，线程或者连接数量就控制不住了，服务器资源分分钟被占满，单例就能帮你把这些资源“管”起来，只留一个实例统一调度，既安全又高效。 单例就是帮你守住“只创建一个实例”的底线，还能让整个项目方便调用，省资源又少麻烦，这才是它在实际开发里受欢迎的原因。
单例模式适用于哪些实际开发场景？
单例模式适用于需要控制实例唯一性的场景，例如配置管理类（全局配置只需加载一次）、日志工具类（避免多实例写入冲突）、线程池管理（防止重复创建线程池）、数据库连接池（控制连接数量）等。核心是确保某个类的实例在系统中只有一个，且提供全局访问点。
懒汉式和饿汉式单例该如何选择？
选择需结合场景：若实例一定会被使用（如核心工具类），可优先用饿汉式，实现简单且线程安全；若实例可能不被使用（如按需加载的功能模块）， 用懒汉式（需配合线程安全方案，如静态内部类或双重检查锁定），避免内存浪费。高并发场景下，静态内部类或枚举单例通常是更优选择。
双重检查锁定（DCL）中为什么必须使用volatile关键字？
volatile关键字主要用于防止指令重排。在创建对象时，JVM可能将“分配内存→初始化对象→赋值给引用”的步骤重排，若不加volatile，可能导致一个线程拿到未初始化的实例（引用已赋值但对象未初始化），其他线程使用时会报错。volatile可保证实例的可见性和禁止指令重排，确保双重检查锁定的安全性。
如何防止反射机制破坏单例模式？
可在私有构造器中添加实例存在性检查：当通过反射调用构造器时，若单例实例已存在，直接抛出异常。例如在构造器中判断“若实例不为null，则抛出IllegalStateException”，阻止反射创建新实例。这种方式能有效防护反射攻击，确保单例的唯一性。
为什么枚举单例被称为“最佳实践”？
枚举单例天生具备线程安全（JVM保证枚举实例在类加载时唯一初始化）、防止反射破坏（枚举构造器默认被JVM保护，无法通过反射调用）、防止序列化破坏（枚举反序列化时不会创建新实例）等优势，且实现代码极简（一行定义实例）。《Effective Java》明确推荐枚举作为单例的首选实现方式，几乎无安全隐患。
