多线程下单例模式的线程安全：从DCL到枚举的全面解析-代码聚汇网

多线程下单例模式的线程安全：从DCL到枚举的全面解析

单例模式多线程线程安全

|难度：普通|阅读约 36 分钟

1. 一个单例引发的线上事故：从根源说起

先说个我实际经历过的线上问题。当时一个订单服务在压测时偶发出现"订单号重复"的诡异日志，排查了大半天，最后发现罪魁祸首竟然是——一个单例对象被创建了多份。一个订单号生成器，设计时用单例模式确保全局唯一，结果在某些并发条件下，不同线程拿到的不是同一个实例，各自维护了一份独立的序号池，订单号自然就重复了。

这不是段子，是真实事故。很多人觉得单例模式简单到不值一提——"不就是构造函数私有化加一个静态方法吗？"——但单例恰恰是最容易在多线程环境下写崩的代码模式之一。不管是Java、C++还是C#，只要涉及多线程，单例的线程安全问题就会从"基础题"变成"送命题"。最简单的if (instance == null)判断，放在并发环境下，随时可能给你搞出几个"单例"来。

这篇博文就围绕"多线程 + 单例"这个组合做一次完整的拆解：从问题根源，到各种写法演进，再到面试追问，最后给出我踩坑多年的选型建议。无论你是刚接触多线程的新手，还是写了几年业务代码的老手，我相信总有你能用上的东西。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 为什么最简单的懒汉式在多线程下必挂

先看最经典的懒汉式单例写法，几乎所有教材里都出现过：

java复制public class Singleton {

    private static Singleton instance;

    private Singleton() {
        // 私有构造
    }

    public static Singleton getInstance() {
        if (instance == null) {          // 线程A、B同时到达这里
            instance = new Singleton();  // 然后各自创建实例
        }
        return instance;
    }
}

这段代码单线程下毫无问题，但放到多线程环境里，它的正确性完全建立在运气上。

2.1 竞态条件：两个线程同时看到了"空"

问题出在if (instance == null)这个判断不是原子操作，new Singleton()也不是原子操作。当两个线程同时调用getInstance()时，可能发生这样的情况：

线程A先执行if (instance == null)，发现instance确实是null，然后进入if代码块，准备执行new。
就在A还没完成new Singleton()赋值时，线程B也执行了if (instance == null)，它看到的instance依然是null，于是也进入了if代码块。

结果：A和B各自new了一个Singleton对象，全局唯一的约束被打破。更细的问题，扒到CPU和内存层面更值得聊——可见性和重排序才是这里真正的主角。

2.2 加了同步方法就安全了吗

很自然的想法是给getInstance()加synchronized：

java复制public class Singleton {

    private static Singleton instance;

    private Singleton() {}

    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

线程安全确实解决了，但性能代价非常大。注意，synchronized锁的是整个方法——当实例已经创建完毕，后续所有的getInstance()调用依然要串行拿锁。在高并发场景下，所有线程相当于排着队过一个单行道闸机，吞吐量直线下降。

我见过不少项目早期这样写，访问量小的时候没什么感觉，一上压测就原形毕露。打个不恰当的比方：就像一个已经开门营业的商店，每来一个顾客你都要临时关门确认"店里有没有人"，确认完了再放他进来，这不是搞笑吗？

这里其实引出了后面很多优化的核心逻辑：锁的粒度要尽量小，而且只在真正需要同步的阶段才同步。实例已经创建之后，根本不需要再走锁。

3. 双重检查锁定（DCL）与volatile：一次被重排序坑惨的优化

为了解决"每次调用都加锁"的浪费，聪明的前辈们设计出了双重检查锁定（Double-Checked Locking，简称DCL），这是面试必考，也是实际项目里用得最多的一种方案。

java复制public class Singleton {

    private static volatile Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {                          // 第一次检查：无锁
            synchronized (Singleton.class) {
                if (instance == null) {                  // 第二次检查：加锁
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

它的思路是：先无锁地判断一次，只有instance为null时才进入同步代码块；进入同步块后再判断一次，防止多个线程同时进入后重复创建。当实例已经存在时，后续调用直接走第一次判断的"快速通道"，完全不会碰到锁。

3.1 不加volatile会怎样

这里的重点是volatile关键字，少了它，DCL就是错的。为什么？

核心在于instance = new Singleton()这行代码在JVM层面并不是一步操作，它大致可以拆成三步：

text复制1. 分配内存空间
2. 初始化Singleton对象
3. 将instance引用指向这块内存

但JVM在运行时允许指令重排序——只要不改变单线程内的语义，第2步和第3步的顺序可能被调换。也就是说，实际执行顺序可能是：

text复制1. 分配内存空间
2. 将instance引用指向这块内存      // 此时对象还没初始化完成
3. 初始化Singleton对象

在多线程环境下，这个重排序是致命的。设想一个具体时序：

线程A进入同步块，执行new Singleton()，执行到第2步——instance已经指向了一块内存，但对象里的字段都还是默认值，构造方法还没跑完。
此时线程B调用getInstance()，第一次检查instance == null——发现不为null，直接return instance。
线程B拿到的是一个"半初始化"的对象，访问里面的字段时拿到的是默认值或null，随后出现各种不可预知的问题。

volatile在这里干了两件事：第一，禁止指令重排序（针对JSR-133内存模型），保证new Singleton()的三步按顺序执行；第二，提供可见性，保证一个线程对instance的修改，能立刻被其他线程看到。

3.2 我第一次写DCL踩的坑

这段写出来给后来的朋友避坑。我很早以前写DCL时，代码是照着教程敲的，volatile也加了，自认为稳如老狗。结果有一次做高并发测试，单例里的一个配置Map偶尔出现key丢失的情况。

排查了很久才发现，我把volatile加在了private static volatile Singleton instance上，但跑测试的JDK版本比较老，用的是JDK 1.4——在JDK 5之前，volatile的语义还不完整，不能禁止重排序。后来升级JDK版本才解决问题。

所以这里必须强调：DCL + volatile的正确性依赖JDK 5+（准确说是JSR-133之后的内存模型）。如果你们项目里还有老古董JDK，要么升级，要么放弃DCL改用其他方式。当然，现在2024年了还在用JDK 1.4的项目几乎绝迹，但了解这段历史能帮你理解为什么volatile在这里是必需品。

4. 饿汉式和静态内部类：放弃锁，从类加载机制上解决问题

有没有一种方式，既不用写锁，又能保证线程安全，还能延迟加载？有——利用JVM的类加载机制。

4.1 饿汉式：最简单，但不是没有代价

java复制public class Singleton {

    private static final Singleton INSTANCE = new Singleton();

    private Singleton() {}

    public static Singleton getInstance() {
        return INSTANCE;
    }
}

饿汉式的原理很直接：类加载到JVM时，INSTANCE就会被初始化。而JVM保证一个类的初始化过程在多线程环境下是线程安全的——多个线程同时触发类初始化时，只会有一个线程执行<clinit>（类构造方法），其他线程阻塞等待。

所以饿汉式天然是线程安全的，不需要任何同步手段。

它的问题在于：没有延迟加载。不管这个单例用不用，类一加载就创建实例。如果单例的构造过程很重——比如要初始化数据库连接池、加载大配置文件、建立远程连接——那么类加载的耗时会被拖得很长，应用启动时会有明显卡顿。

此外，如果这个类被加载了但从未使用，实例就白白创建了，浪费内存。像Spring Boot这种启动时扫描大量类的场景，饿汉式对启动时间的影响会更明显。

4.2 静态内部类：延迟加载和线程安全我都想要

java复制public class Singleton {

    private Singleton() {}

    private static class Holder {
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return Holder.INSTANCE;
    }
}

这个写法简直是"既要又要"的典范。

原理拆开讲：外部类Singleton被加载时，内部类Holder并不会被加载——JVM的类加载是懒加载的，只有在首次主动使用时才加载。也就是说，只要没有人调用getInstance()，Singleton实例就不会创建，实现了真正的延迟加载。

当第一个线程调用getInstance()时，触发Holder的类加载，JVM保证类初始化的线程安全性——同一时刻只有一个线程执行Holder的<clinit>。于是实例既延迟创建了，又线程安全了，还不需要任何锁和volatile。

从运行效率看，getInstance()在实例已创建后就是一次静态字段读取，性能上几乎和饿汉式一样快——比DCL的"无锁检查"还要快一点，因为DCL好歹有个volatile读的屏障开销。

4.3 静态内部类和饿汉式的实际区别

很多人问我，这俩最终都是类加载时创建实例，区别真有那么大吗？我从实际使用体验角度说一下：

饿汉式的INSTANCE初始化发生在外部类被主动使用的那一刻。比如你的Singleton类里有静态方法、静态字段，其他代码一访问这些内容，类就加载了，实例也就创建了——哪怕你只想用它的一个静态工具方法，也白白把单例初始化了。
静态内部类的实例创建被放在Holder里，和外部类的其他静态内容完全解耦。只有明确调用getInstance()，才会触发实例创建。

所以如果你的单例构造很重，又希望它做到"按需创建"，静态内部类是比饿汉式稳妥得多的选择。如果单例构造很轻、类本身也很少被其他静态内容牵连，饿汉式也不是不行——很多开源框架里其实大量使用饿汉式单例。

5. 枚举单例：最优雅，还能防反射和反序列化

如果让我给"多线程环境下最省心的单例写法"投票，我会投给枚举单例。代码长这样：

java复制public enum Singleton {

    INSTANCE;

    // 业务方法
    public void doSomething() {
        // ...
    }
}

用完就没了，一行字段都不用写。调用方式更简单：

java复制Singleton.INSTANCE.doSomething();

5.1 为什么枚举天生线程安全

枚举的实例创建也由JVM类加载机制保证，和静态内部类一样——枚举类在第一次被访问时初始化，JVM保证这个初始化过程在多线程环境下只执行一次，天然线程安全。

你要说它是不是延迟加载？严格来说，枚举的实例是在枚举类被加载时创建的，也带有一点"饿汉"的性质。但因为枚举的语法极其简洁，这个特性在实际使用中几乎不算缺点。

5.2 枚举单例的隐藏Bonus

常规单例模式有一个著名的理论漏洞——反射攻击。你可以这样破坏一个普通单例：

java复制Class<?> clazz = Singleton.class;
Constructor<?> constructor = clazz.getDeclaredConstructor();
constructor.setAccessible(true);
Singleton another = (Singleton) constructor.newInstance();

构造器被私有化了？没关系，setAccessible(true)强行打开。newInstance照样执行私有构造器，单例被复制出一个新实例。

另外还有反序列化破坏。如果一个单例类实现了Serializable，那么反序列化时，JVM会绕过构造器直接创建一个新实例——单例又失效了。普通单例想防住反序列化破坏，需要自己实现readResolve()方法，把反序列化得到的对象替换成原单例，代码还要多写几行。

但枚举单例对这两种攻击免疫：

反射攻击：JVM明确规定不能用反射创建枚举实例，newInstance()遇到枚举会直接抛IllegalArgumentException。
反序列化破坏：枚举反序列化有特殊处理，返回的是已有的枚举常量，不会创建新对象。

这段"防护能力"面试时经常被追问，尤其是企业招Java后端，问到单例实现方式时，枚举单例几乎是标准答案之一的加分项。

5.3 为什么很多人不写枚举单例

虽然枚举单例看起来完美，但实际项目里它的出镜率并不如DCL那么高。我分析下来主要有两个原因：

第一，迁移成本。很多项目的单例类原本是普通class，改成枚举需要调整调用方式（从Singleton.getInstance()变成Singleton.INSTANCE），涉及改动面大，团队嫌麻烦。

第二，认知惯性。很多老程序员接触单例模式时学的是传统的class写法，技术选型时第一反应是"最熟悉的写法"，而不是"最好的写法"。

此外，如果你的单例需要继承某个类或实现某个接口，且这个类本身不是枚举类型，那枚举就没办法继承了——Java的枚举隐式继承java.lang.Enum，不能再继承其他类。不过在绝大多数业务场景下，单例不需要继承，这个限制实际影响很小。

6. 破坏单例的隐藏攻击面：反射、序列化与类加载器

前面已经提过反射和序列化能破坏单例的"唯一性"，这一节展开聊聊实际的破坏路径和应对方法。这块内容偏面试向，但在设计底层基础设施时也用得上。

6.1 反射攻击的实际演示

以DCL单例为例，写一段攻击代码：

java复制public class Singleton {

    private static volatile Singleton instance;

    private Singleton() {
        System.out.println("构造函数被调用");
    }

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }
}

攻击者可以做到：

java复制Class<?> clazz = Class.forName("com.demo.Singleton");
Constructor<?> constructor = clazz.getDeclaredConstructor();
constructor.setAccessible(true);
Singleton s1 = (Singleton) constructor.newInstance();
Singleton s2 = Singleton.getInstance();
System.out.println(s1 == s2); // false，出现了两个"单例"

防御手段其实很有限——在私有构造器里加一个标志位：

java复制public class Singleton {

    private static volatile Singleton instance;
    private static boolean created = false;

    private Singleton() {
        synchronized (Singleton.class) {
            if (created) {
                throw new RuntimeException("禁止反射创建实例");
            }
            created = true;
        }
    }
}

这样能挡住大部分常规攻击，但"道高一尺魔高一丈"，通过反射修改created字段的值，还是能绕过。所以从根本上说，普通Java单例无法完全防御反射攻击，这是语言层面的限制。如果你面对的安全要求极其严格，枚举单例是更可靠的方案。

6.2 反序列化破坏与readResolve

如果一个单例类实现了Serializable，序列化后再反序列化，会得到一个新实例。要防住这个，需要加一个readResolve()方法：

java复制public class Singleton implements Serializable {

    private static volatile Singleton instance;

    private Singleton() {}

    public static Singleton getInstance() {
        if (instance == null) {
            synchronized (Singleton.class) {
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return instance;
    }

    protected Object readResolve() {
        return getInstance();
    }
}

readResolve()的机制是：反序列化时，JVM会调用这个方法，用返回的对象替换掉反序列化出来的新对象。这样外部拿到的仍然是那个全局唯一的实例。

我记得早期做分布式缓存客户端时，缓存客户端对象是单例，内部封装了连接池，结果测试反序列化后连接数翻倍，就是因为没写readResolve()。这种坑只有在线上特定场景才会遇到，排查起来很费劲。

6.3 类加载器差异导致的多实例

还有一个更隐蔽的坑——类加载器。如果同一个类被两个不同的类加载器加载，那么在JVM看来它们就是两个不同的类，各自的静态字段互不相同，单例自然也不唯一。

典型场景是Java Web应用的Tomcat环境：如果同一个类被部署在WEB-INF/classes和共享lib两个位置，或者被多个classloader加载，可能会各自维护一份静态状态。这种问题定位起来特别痛苦，因为代码层面完全看不出问题——Singleton.class对象都不相等。

应对策略通常是：使用线程上下文类加载器加载单例，或者从框架层面保证单例类只被一个类加载器加载。这块内容比较深，普通业务开发遇到的机会不多，但写公共库、中间件时一定要留意。

7. 选型参考：不同场景该用哪种单例写法

“纸上得来终觉浅”，我把这些年实际项目里的选型经验整理成了一张表，方便你对照场景做决策：

实现方式	线程安全	延迟加载	使用成本	防反射	防序列化	适用场景
饿汉式	是	否	极低	否	否	单例构造轻，类本身不常被其他内容牵连
懒汉式（同步方法）	是	是	低	否	否	几乎不推荐，性能差
DCL + volatile	是	是	中	否	否	需要延迟加载，代码可控性强
静态内部类	是	是	低	否	否	推荐，兼顾懒加载和性能
枚举	是	否（类加载时）	极低	是	是	最推荐，简单安全

我的习惯是：

新项目新代码，优先写枚举单例。代码量最小，线程安全无忧，反射序列化都防了，几乎没有理由不用。
需要延迟加载的，用静态内部类。比如一个重量级工具类的单例，用起来既稳又懒。
**老项目中已有大量getInstance()调用，继续用DCL **。迁移成本太高时，没有改的必要，只要volatile写对，DCL在JDK 5+上就是安全的。

这里特别提醒一点：不要为了"性能"过早优化单例写法。单例的创建通常发生在系统启动或首次调用时，对整体性能的影响微乎其微。真正的性能问题是"每次调用都加锁"这种——用DCL或静态内部类解决的是持续性的锁开销，而饿汉式在构造轻量时也完全够用。

8. 多线程面试中的单例追问：答好这些才算真懂

单例是多线程面试的高频考点，但很多面试者只背了代码就上战场，一问原理就露馅。我作为面试官经常追这么几个问题，你们可以对照自测：

8.1 "synchronized加在静态方法上锁的是什么？"

public static synchronized Singleton getInstance()，锁的是Singleton.class这个Class对象。Java中每个类加载后都有一个唯一的Class对象，所以静态同步方法天然是所有线程共享同一把锁。如果把synchronized加在实例方法上，锁的是this，对于单例来说this也是同一个实例，锁也能生效——但会让人费解，规范做法是加在静态方法上。

8.2 "volatile在这里到底解决什么问题？"

两个作用：第一是禁止指令重排序，保证对象引用赋值发生在对象初始化完成之后；第二是保证可见性，让其他线程立即可见instance引用的更新。如果只说一个，只答"防止拿到半初始化对象"，可以算及格；能把可见性也答出来，说明理解是完整的。

8.3 "静态内部类为什么能线程安全地实现延迟加载？"

核心在于JVM类加载机制：类在首次被主动使用时才触发加载、连接、初始化，而初始化过程由JVM保证线程安全——多个线程同时触发时只有一个线程执行<clinit>。Holder类只有调用getInstance()时才会被加载，所以实例创建被推迟到首次调用那一刻。

8.4 "枚举单例为什么能防反射？"

Constructor.newInstance()的源码里有明确判断：如果调用构造器的目标是枚举类，直接抛IllegalArgumentException。这是JVM层的硬限制，不是靠代码逻辑防御的。至于序列化，枚举的序列化是由JVM特殊处理的——反序列化时通过Enum.valueOf()获取已有常量，不会走普通对象创建的路径。

8.5 "把单例类的构造器改成public会怎样？"

会完全破坏单例的语义。虽然单例的实现通常私有化构造器，但反射攻击说明私有构造器不是绝对屏障。所以考察单例的强健性，重点看的不是构造器是不是private，而是在"攻击者不遵守规则"的前提下，是否还能保证唯一性——枚举在这种语境下的优势就非常明显。

9. 多线程单例的进阶话题：线程局部单例与作用域单例

最后扩展一个容易混淆的概念——ThreadLocal实现"线程内单例"。

有时候业务需要的是"每个线程只有一个实例"，而不是"整个JVM只有一个实例"。典型场景：SimpleDateFormat不是线程安全的，如果全局共享一个实例会被并发搞崩，如果每次new一个又浪费；常见优化就是用ThreadLocal包装它，让每个线程各自持有一个SimpleDateFormat实例，既线程安全又避免反复创建：

java复制private static final ThreadLocal<SimpleDateFormat> DATE_FORMAT =
        ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));

public String formatDate(Date date) {
    return DATE_FORMAT.get().format(date);
}

这不是传统意义上的单例模式（JVM范围内不唯一），但在"线程作用域"内它确实是单例的，而且天然不需要加锁。理解了这个区别，你对"单例的粒度"会有更深的认识。

需要澄清的是，ThreadLocal和单例模式不是一回事：单例追求全局唯一，ThreadLocal追求线程隔离。但在多线程面试题里，它们经常被放一起讨论——同样是为了解决多线程环境下的实例安全问题，方案思路完全不同。能把两者的关系和区别讲清楚，面试官会认为你是真的理解多线程，而不是背了几个模板。

10. 我的最后建议

多线程环境下的单例实现，发展到现在其实已经是一个非常成熟的话题，方案排序大体是：枚举 > 静态内部类 > DCL > 饿汉式 > 懒汉式（同步方法）。新代码，尤其是中间件、基础库这种对稳定性要求高的模块，直接用枚举或静态内部类；老代码如果已经在跑DCL，只要JDK版本大于等于5，volatile写对了，就没有必要为了"优雅"去重构——改动带来的风险往往比技术债更大。

最后分享一个判断代码质量的土办法：一个多线程环境下的单例实现，如果除了getInstance之外还需要额外写"保护措施"（比如反射标志位、readResolve），那它就不是最优方案；而枚举只写了一行INSTANCE，什么保护都不需要，反而最安全。多写不一定好，少写才是本事，这点在并发编程里尤其成立。