单例模式大概是整个设计模式里代码量最少、但最能“拷问”功底的一个了。Java 单例类的经典写法网上随便一搜就是一大堆可真正能把它讲透、用对的人并不算多。我在带项目和招人的时候经常发现有人加了 synchronized 就觉得万事大吉有人写了双重检查锁却漏了 volatile还有人以为枚举单例只是个语法糖根本说不清它为什么能防反射破坏。这篇文章不打算做教科书式复述而是把单例从“为什么需要”到“五种写法怎么选”再到落地验证、常见陷阱和面试深挖点完整过一遍。不管你是刚接触设计模式的 Java 初学者还是准备跳槽啃八股的面试党都应该能从中拿到可以直接用的东西。1. 为什么需要单例它到底在解决什么问题1.1 从“两套配置”事故讲起先说一个我实际踩过的坑。几年前做支付对账系统时配置中心模块需要统一加载商户密钥和回调地址。最初设计很随意每个需要配置的 Service 都自己new ConfManager()结果线上出了一次事故——运营在后台更新了商户回调地址其中一个模块还抱着旧配置导致一批回调验证失败。定位半天发现原因就是各个模块各自持有一份实例改动只对新建的实例生效。这个场景特别典型当系统里多个地方需要共享同一份数据或者同一个资源时每new一次就等于复制了一个“小世界”各自为政状态完全不互通。后来改成单例所有模块通过同一个入口获取同一份配置问题立刻消失。所以单例的第一个价值就是保证“全局唯一”让状态天然一致。1.2 单例解决的三个核心痛点从那次事故往后我再看单例模式心里就有了一张清晰的图它其实在同时解决三个层面的问题。资源层面的浪费。线程池、数据库连接池、HTTP Client、日志 Logger 这类对象创建成本极高。每 new 一次就要建立一批连接、分配一大块内存十个模块就是十份开销。单例让这类重量级对象在进程内只存在一份省下的资源非常可观。状态层面的一致性。配置信息、计数器、缓存数据这些会变化的状态一旦被多个实例各自持有就会互相覆盖、彼此不同步。单例把状态收敛到一个实例上所有调用方读写同一份数据从根上避免“两套配置”的闹剧。访问层面的统一入口。业务代码如果到处手动创建、传递共享对象逻辑会散落且难维护。单例提供一个全局访问点调用方一行代码拿到实例不用知道底层实现细节。这里可以用一个生活化的类比一个公司只能有一个 CEO。全世界任何部门要汇报都只能找这一个人不能每个部门自己“任命”一个 CEO。CEO 就是那个唯一实例汇报入口就是getInstance()。1.3 单例不是“全局变量替身”有同学看完上面三点容易走另一个极端什么东西都塞进单例。我在代码评审里见过把订单实体、用户信息、临时缓存全做成单例的项目最后并发问题一团糟。这里必须说清楚单例适合的是“进程生命周期内、本身无私聊状态的共享对象”。如果对象要承载每个线程特有的数据或者涉及高并发下的频繁写操作强行单例只会把并发压力集中到一个点甚至引入严重的线程安全问题。换句话说单例保护的是“唯一性”不等于“随处可用”。设计一个单例类之前先问自己三句话这个对象真的需要全局唯一吗它的生命周期能对齐进程吗它的状态在并发访问下安全吗三句里有任何一句犹豫就该重新考虑方案。2. 五种主流单例写法选型思路与代码实现2.1 饿汉式类加载时保证唯一实例饿汉式是最直白的写法核心代码就一行静态 final 字段public class EagerSingleton { private static final EagerSingleton INSTANCE new EagerSingleton(); private EagerSingleton() { // 保护构造器防止外部 new } public static EagerSingleton getInstance() { return INSTANCE; } }它的线程安全完全靠 JVM 保证类加载阶段静态字段初始化只执行一次而这个阶段由 JVM 的类加载机制做了同步多线程不可能同时进入。所以不需要额外加锁性能最好。但它的缺点也明显类一被加载实例就创建了不管后面用不用。如果这个单例对象的构造逻辑很重比如连接数据库、加载大文件那么它会在启动阶段白白消耗时间还可能导致启动变慢、内存被提前占用。适合饿汉式的场景是实例创建开销小、类几乎一定会被用到例如工具类、常量中心。有些资料管它叫“饿汉”字面意思就是“饿得等不及类加载时我就把对象吃掉”——这个命名挺形象记住就忘不掉。2.2 懒汉式与双重检查锁性能和安全如何兼顾和饿汉相对的是懒汉式第一次调用getInstance()时才创建实例。很多人最开始写的版本长这样public class LazySingleton { private static LazySingleton instance; private LazySingleton() {} public static synchronized LazySingleton getInstance() { if (instance null) { instance new LazySingleton(); } return instance; } }synchronized保证同一时刻只有一个线程能进入方法线程安全是有了但代价很大每次调用getInstance()都要抢锁哪怕实例早就创建好了。读一个已经存在的对象引用根本不需要锁。这种写法在低并发下没问题一旦成为热点方法锁竞争会拖慢整体性能。于是就有了双重检查锁Double-Checked LockingDCLpublic class DclSingleton { private static volatile DclSingleton instance; private DclSingleton() {} public static DclSingleton getInstance() { if (instance null) { // 第一次检查不抢锁 synchronized (DclSingleton.class) { // 只有为空才加锁 if (instance null) { // 第二次检查防止并发创建 instance new DclSingleton(); } } } return instance; } }外层检查是为了避免每次调用都进同步块实例已存在时直接返回性能接近饿汉。内层二次检查是为了防止两个线程同时通过外层判断后依次进入同步块创建出两个实例。整个设计非常精巧。这个写法有一个绝对不能被省掉的关键词volatile。省略它DCL 就是在埋雷。至于为什么我放到第四章的“重排序陷阱”里专门讲这里先记住结论Java 单例里的 DCL 必须配合volatile才能做到真正的线程安全。2.3 静态内部类按需加载与线程安全的自然结合如果你既想要懒加载又不想写synchronized还想让代码看着干净静态内部类基本是最优解public class StaticInnerSingleton { private StaticInnerSingleton() {} private static class Holder { private static final StaticInnerSingleton INSTANCE new StaticInnerSingleton(); } public static StaticInnerSingleton getInstance() { return Holder.INSTANCE; } }原理是 JVM 的类加载时机外部类StaticInnerSingleton被加载时并不会立刻加载内部类Holder只有第一次调用getInstance()代码真正触碰到Holder.INSTANCEHolder才会被 JVM 加载并初始化静态字段。于是懒加载天然成立。线程安全也由 JVM 保证类的初始化阶段是被 JVM 加锁保护的同一时间只有一个线程能执行clinit方法其他线程会阻塞等待。所以我常说静态内部类是“用 JVM 的机制代替你手写同步逻辑”在绝大多数场景下它比 DCL 更推荐。这是我个人在实际项目中默认的首选写法。直到今天我写配置管理器、缓存管理器这类单例基本都是静态内部类起步。2.4 枚举单例站在 JVM 层面防破坏Joshua Bloch 在《Effective Java》里专门推荐过枚举单例它可能是代码量最少、最安全的写法public enum EnumSingleton { INSTANCE; public void doSomething() { // 业务逻辑 } }调用方直接用EnumSingleton.INSTANCE不需要getInstance()方法。它的安全体现在两个层面。反射层面Constructor.newInstance()的源码里明确禁止对枚举类型创建新实例会直接抛IllegalArgumentException所以传统反射攻击对枚举无效。序列化层面Java 对枚举的序列化做了特殊处理反序列化时不是通过反射创建新对象而是根据名称返回已有的枚举常量因此枚举类单例在序列化场景下天然不会产生第二个实例。缺点也有枚举不能继承别的类但可以实现接口延迟加载不好控制代码风格和普通类差异比较大。所以它在业务代码里不算多见更多用在框架底层、工具库或者“绝对不能被反射破坏”的敏感场景。不过面试时如果能主动提出来印象分会明显不一样。2.5 容器式注册式单例Spring 里在用的思路实际做 Java 后端的人几乎天天在用 Spring而 Spring 管理的 Bean 默认就是单例。它的底层不是上面任何一种静态写法而是一个容器注册表public class SingletonRegistry { private static final MapString, Object INSTANCES new ConcurrentHashMap(); private SingletonRegistry() {} public static Object getInstance(String className) throws Exception { if (!INSTANCES.containsKey(className)) { synchronized (SingletonRegistry.class) { if (!INSTANCES.containsKey(className)) { Class? clazz Class.forName(className); INSTANCES.put(className, clazz.getDeclaredConstructor().newInstance()); } } } return INSTANCES.get(className); } }思路是用一个 Map 缓存实例key 是类名或 bean 名value 是对应的对象实例需要时先从 Map 取取不到再创建并放进去。这和 Spring 的singletonObjects注册表在思想上完全一致。容器式单例的好处是把“唯一性”从某个类的静态变量提升到了容器层面。实例不是由类自己“写死”的而是由容器统一管理这样很容易加上代理、AOP、生命周期回调等扩展能力。这也是为什么 Spring 的单例 Bean 可以做事务增强、可以做依赖注入而普通静态单例做不到。理解这一点你就能回答那个高频面试题Spring 的单例和单例模式有什么区别答案是Spring 的单例是容器级单例单例模式是类加载器级单例。为了让理解更直观我把五种写法放在一张表里做对比写法创建时机线程安全延迟加载防反射/序列化适用场景饿汉式类加载时是JVM保证否需额外处理启动就要用、创建开销小懒汉式同步方法首次调用是性能差是需额外处理理论教学、低并发DCL首次调用是需volatile是需额外处理高并发下的经典选型静态内部类首次调用 Holder是JVM保证是需额外处理绝大多数业务默认推荐枚举JVM 加载枚举类是JVM保证否天然防御绝对安全优先、框架底层容器式首次注册是ConcurrentHashMap是与容器实现有关Spring 等 IOC 容器3. 从“能用”到“稳用”单例落地实操与验证3.1 实战配置中心单例的完整实现写一个非常贴近业务的例子配置中心。需求是应用启动后加载app.properties所有模块共享同一份配置并且支持随时读取。public class ConfigManager { private final Properties properties new Properties(); private ConfigManager() { try (InputStream is ConfigManager.class.getClassLoader() .getResourceAsStream(app.properties)) { if (is null) { throw new IllegalStateException(app.properties not found in classpath); } properties.load(is); } catch (IOException e) { throw new ExceptionInInitializerError(e); } } private static class Holder { private static final ConfigManager INSTANCE new ConfigManager(); } public static ConfigManager getInstance() { return Holder.INSTANCE; } public String get(String key) { return properties.getProperty(key); } public String get(String key, String defaultValue) { return properties.getProperty(key, defaultValue); } }这里我故意选用了静态内部类写法因为配置对象的创建涉及 IO 读取属于“慢启动”资源最好是按需加载而不是应用一启动就加载。构造器里我加了文件不存在的校验并把 IO 异常包装成ExceptionInInitializerError这样一旦配置缺失类初始化会直接失败问题能在启动阶段暴露而不是等到运行时才报空指针。调用方式也简单String callbackUrl ConfigManager.getInstance().get(callback.url, );所有模块拿到的都是同一个ConfigManager实例改配置时只需要保证资源文件更新和重新加载机制不会出现每个模块各拿一份旧配置的情况。3.2 并发环境怎么验证“真的只有一个实例”很多新手写完全单例心里没底到底是不是真的只有一个实例最直接的验证办法是用并发压测在多个线程同时第一次调用getInstance()打印每个线程拿到的对象内存地址哈希值。这里的关键是让线程尽量同时起跑否则验证没有说服力。public class SingletonConcurrentTest { public static void main(String[] args) throws InterruptedException { int threadCount 16; CountDownLatch ready new CountDownLatch(threadCount); CountDownLatch start new CountDownLatch(1); CountDownLatch done new CountDownLatch(threadCount); ExecutorService pool Executors.newFixedThreadPool(threadCount); for (int i 0; i threadCount; i) { pool.submit(() - { ready.countDown(); try { start.await(); ConfigManager instance ConfigManager.getInstance(); System.out.println(hash System.identityHashCode(instance)); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { done.countDown(); } }); } ready.await(); long begin System.nanoTime(); start.countDown(); done.await(); long cost System.nanoTime() - begin; System.out.println(并发获取耗时(ns) cost); pool.shutdown(); } }正常输出里16 个线程打印的System.identityHashCode应该全部一致。有人会问为什么用System.identityHashCode而不直接打印object.toString()因为如果单例类没有重写toString()两者等价但很多实际类会重写toString()的结果就不代表对象身份了。用identityHashCode是最稳的。如果拿到的哈希值不一致基本可以断定代码存在线程安全问题优先检查同步块是否写对、volatile是否漏掉。3.3 一个容易被忽视的扩展点带泛型的单例注册表容器式单例在日常代码中也很实用。比如一个小系统里有多种策略类需要全局唯一但每种策略类单独写一套静态单例又太啰嗦可以用一个泛型注册表统一管理public final class SingletonRegistry { private static final MapString, Object INSTANCES new ConcurrentHashMap(); private SingletonRegistry() {} SuppressWarnings(unchecked) public static T T getInstance(String key, SupplierT creator) { return (T) INSTANCES.computeIfAbsent(key, k - creator.get()); } }使用方式PayStrategy strategy SingletonRegistry.getInstance(alipay, AlipayStrategy::new);computeIfAbsent本身就是原子的能避免并发创建。不过要注意两个问题泛型信息会被擦除取出来时如果类型不匹配强转可能报ClassCastException另外注册表是全局共享的 Mapkey 的命名规则要提前定好否则容易撞车。这种写法适合“少量策略类需要全局共享”的中小型项目如果规模大了还是交给 Spring 容器管理更省心。4. 单例的陷阱清单与面试深挖点4.1 反射与序列化单例模式的破防点静态单例最容易被攻击的入口就是反射。看下面这段代码Class? clazz StaticInnerSingleton.class; Constructor? constructor clazz.getDeclaredConstructor(); constructor.setAccessible(true); Object instance1 constructor.newInstance(); Object instance2 constructor.newInstance(); System.out.println(instance1 instance2); // falsesetAccessible(true)可以强行调用私有构造器在普通静态单例面前直接“破了防”。要防御的话可以在构造器里加一道校验private StaticInnerSingleton() { if (Holder.INSTANCE ! null) { throw new IllegalStateException(Already initialized); } }这样反射第二次调用构造器时因为实例已存在直接抛异常。但这道防线依赖代码顺序第一层反射依然能成功创建后面的调用才被拦下。如果要求绝对安全直接选枚举反射框架对枚举无能为力。序列化同样会破坏单例。如果一个单例类实现了Serializable反序列化时会通过反射创建新对象即使构造器是私有的。解决办法是实现readResolve()方法protected Object readResolve() { return Holder.INSTANCE; }反序列化时 JVM 会调用readResolve()用返回值代替新创建的对象从而保证唯一性。枚举则完全不需要这些处理这也是它在安全层面更省心的原因。4.2 重排序陷阱为什么 volatile 不能省略这一节是 DCL 的核心考点。很多人只知道 DCL 要加volatile但说不出为什么。new DclSingleton()这行代码在 JVM 底层大致拆成三步分配内存空间初始化对象执行构造器把对象引用赋值给instance问题在于编译器、CPU 为了提高性能可能对指令重排序把第 2 步和第 3 步调换顺序执行。在单线程下没问题但在多线程下就会出现这个场景线程 A 执行了“分配内存”和“引用赋值”但还没有执行“初始化对象”。此时线程 B 进入getInstance()发现instance ! null直接返回一个“半初始化”的对象。线程 B 拿着这个构造还没执行完的对象去调方法轻则拿到默认值重则直接抛空指针。volatile在这里做两件事禁止该字段的读写操作被编译器、处理器重排序建立happens-before关系保证写instance前对对象的所有修改对读instance后的线程可见。加上volatile之后instance new DclSingleton()的“引用赋值”必然发生在“初始化对象”之后半初始化对象就不会被其他线程看见了。静态内部类和枚举单例都不存在这个问题是因为它们的实例创建发生在类初始化阶段JVM 在类初始化完成前不会将引用发布给其他线程所以天然安全。4.3 类加载器与 Spring 容器单例的边界在哪还有一个容易被忽略的坑类加载器。单例的唯一性其实不是“整个 JVM 唯一”而是“同一个类加载器范围内唯一”。如果同一个类被两个不同的类加载器各加载一次内存里就有两份 Class 元数据每份都有自己的静态变量单例就会出现多实例。这在 Tomcat 这种带多 Web 应用隔离的环境里尤其要留意。Spring 单例 Bean 和这个边界又不一样。Spring 的singletonObjects是一个MapString, Object即使同一个类被加载两次只要 bean 的唯一 name 对应一个实例容器从 Map 里拿到的还是同一个对象。它管理的是“容器范围内的实例”而不是“类加载器范围内的静态变量”并且还附带生命周期和代理能力。所以面试官问“Spring 单例和 GoF 单例区别”时回答思路应该落在实例缓存的位置不同、管理主体不同、扩展能力不同。4.4 面试追问实录这些问题能检验你是否真懂单例相关的面试题我见得最多的几个基本可以串成一条追问链路问题核心回答思路单例模式和静态方法 / 静态变量有什么区别静态方法没有状态单例可以持有并共享状态静态变量虽然是全局的但缺少访问控制、没有规范和扩展点。饿汉式和懒汉式怎么选看创建开销和使用时机确定会用、开销小选饿汉希望按需创建选懒汉。DCL 里 volatile 的作用是什么禁止指令重排序防止其他线程拿到半初始化对象保证可见性。枚举为什么能防止反射和序列化破坏JVM 规范层面禁止反射创建枚举实例序列化机制对枚举按名称返回常量不创建新对象。静态内部类为什么线程安全类初始化阶段由 JVM 加锁保证只有第一个线程执行初始化后续线程等待。你实际项目中推荐用哪种普通业务默认静态内部类安全敏感场景用枚举容器环境交给 Spring 管理。把这些问题想清楚单例的“纸面知识”才算真正落地。其实面试官要的不是一个标准答案而是看你有没有理解每个选择背后的 JVM 机制。最后聊一点我个人在项目里的体会。单例这个模式看起来简单但它把“全局唯一”“并发安全”“生命周期管理”三个核心命题全部卷进来了。我现在的默认选型很简单业务代码里的配置、连接池这类共享对象一律用静态内部类涉及反序列化、反射对抗或者对安全极度敏感的底层组件直接上枚举Spring 环境里能用 IoC 容器管理就不要手写单例。踩过“两套配置”的坑之后我养成了一个习惯——每次设计一个会被多处共享的类都会先问一句它需要唯一吗如果需要那谁来保证这个唯一性想清楚这一步代码的质量就已经赢了大半。