Spring单例bean线程安全：事故、源码与修复实践

Spring 框架里，bean 默认就是单例的，"Spring 单例线程安全"这个问题我在面试里被人问过，也在代码评审时追着别人问过。后来发现很多人的理解停留在背答案的层面：要么张口就说"单例不安全，所以要用 prototype"，要么觉得只要 Spring 给我管好了单例，并发就是容器的事。这两种理解都有偏差。今天我不打算背书，想从一次线上事故讲起，配合源码把这事的底层逻辑拆开，最后给出一套真正能落地的排查、修复和测试方法。无论你是准备面试的后端新人，还是正在为一个偶发 bug 头疼的开发，这篇文章应该都能帮上忙。

1. 先把"单例"和"线程安全"这两个词对齐

1.1 Spring 的 singleton 到底承诺了什么

Spring 的 bean 默认 scope 是 singleton，严格来说是容器层面的约定：同一个 beanName 在同一个 ApplicationContext 里只会有一个实例，所有依赖这个 bean 的地方拿到的都是同一个引用。这跟经典单例模式（类加载层面保证 JVM 里只有一个实例）不是一回事，虽然两者都强调"唯一实例"，但都没有承诺过"这个实例可以被多线程安全地并发使用"。

容器做的事情很有限：创建实例、完成依赖注入、执行初始化回调，然后把实例放进单例池。之后每个线程通过getBean拿到的都是同一个对象引用。至于这个对象内部的字段怎么读写、方法有没有加锁，Spring 一概不关心。

所以"单例导致线程不安全"这个说法本质上不严谨。不安全的是"单例 + 可变状态 + 并发访问"这个组合，单例只是放大了问题，不是问题的根源。

1.2 判断一个 Bean 安不安全，看的不是"单例"，而是"状态"

我习惯把 bean 分成两类来判断：

实际项目里，Controller、Service、DAO 层大部分 bean 都是无状态的：它们只是声明依赖，调用其他方法，不自己存数据。这类单例 bean 无论被多少线程并发调用都没问题，因为方法里的局部变量是每个线程独立的栈空间，互相看不见。

真正危险的是那些在字段里偷偷存东西的 bean：一个计数器、一个缓存 Map、一个 SimpleDateFormat、一个共享的加密器。只要有一个可写字段，并发问题就随时可能出现。判断方法很简单：拿到一个单例类，先看字段，再问三个问题——这个字段可变吗？会被写吗？写完之后会被别的线程读到吗？三个都"是"，就必须处理。

提示：判断单例 bean 是否线程安全，别急着上锁，先问自己"这些字段状态真的需要被共享吗"。很多时候答案是"不需要"，那最优解就是去掉字段而不是加锁。

2. 一次线上事故：问题藏在 SimpleDateFormat 的字段里

2.1 事故现场还原

之前接手过一个内部报表系统，它的核心服务里有一个生成报表编号的方法，代码大致长这样：

@Service public class ReportService { private final SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMdd"); private final Map<String, Report> cache = new HashMap<>(); public String generateReport(Date date) { // 问题点1：共享的 SimpleDateFormat String day = sdf.format(date); // 问题点2：共享且未同步的 HashMap Report report = cache.get(day); if (report == null) { report = buildReport(date); cache.put(day, report); } return report.getId(); } }

平时低并发时一切正常，报表编号里的日期部分正确，缓存命中也正常。结果一到大促或者月底批量跑数的时候，诡异的事情就开始出现：报表编号里偶尔冒出错误的年份，甚至直接抛NumberFormatException和ArrayIndexOutOfBoundsException。更夸张的是有两次线上 JVM 的 CPU 直接飙到接近 100%，load 下不来，最后只能重启。

2.2 排查过程：从现象到根因

当时第一反应是看日志，但异常信息五花八门，没有共性业务逻辑错误。最后靠jstack连抓了几次线程快照，发现一个明显规律：大量业务线程全部卡在SimpleDateFormat.format()方法内部，还有一部分线程卡在HashMap.get()和HashMap.put()的节点遍历上。单独看任何一条线程栈都没有问题，但把它们对比一下就明白了——这些线程拿的是同一个ReportService实例，都在并发操作它的字段。

再回头看代码，问题就很清楚了：sdf和cache都是单例 bean 的可变字段。ReportService是单例，所有请求线程共享这个实例，而SimpleDateFormat内部维护了一个可变的Calendar字段，format()和parse()都会修改它；多个线程同时调用，互相覆盖状态，自然就会解析出错误的日期、抛出各种莫名其妙的异常。

HashMap那边更典型。JDK 7 时代并发扩容极端情况下可能形成环形链表导致死循环（当年那个著名的 CPU 100% 案例就是它）；JDK 8 之后改了数据结构，但并发 put 依然会丢数据，迭代时依然可能出现ConcurrentModificationException。我们那次 CPU 尖峰，就是并发扩容加链表遍历搅在一起的结果。

2.3 为什么一个"看起来正常"的格式化会崩

很多人不理解：format不就是把一个 Date 转成字符串吗，怎么会线程不安全？关键在DateFormat的继承结构。SimpleDateFormat继承自DateFormat，而DateFormat内部有一个受保护的Calendar calendar字段。调用format()时，它会先用传入的时间去设置这个 Calendar 的状态，再从这个 Calendar 上读取年月日等信息拼字符串。

两个线程同时调用，线程 A 刚把 Calendar 设置成"2024-09-01"，线程 B 立刻把它改成了"2024-09-02"，线程 A 接着往下读的时候读到的可能就变成了 B 的时间，甚至读到中间态的脏数据。这在并发编程里属于典型的"共享可变状态引发的竞态问题"，跟 Spring 本身没有半点关系，单例只是让这个 bug 从"偶发"变成了"必然"。

注意：凡是内部有可变状态的对象，都不适合直接作为单例 bean 的字段长期持有。常见的还有java.security.MessageDigest、javax.crypto.Cipher等，它们的一次操作会修改内部状态，并发复用一定会出问题。

3. Spring 单例池源码：容器的线程安全和业务代码的线程安全是两码事

3.1 singletonObjects 比你想的更结实

很多人在出事之后第一反应是"Spring 怎么连单例的并发都不帮我管"，这其实是错怪容器了。我们来看看单例池到底长什么样。核心实现在DefaultSingletonBeanRegistry里：

private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);

单例池本身用的是ConcurrentHashMap，也就是说对池子做读操作、写操作、containsKey这类操作都是线程安全的。两个线程同时getBean("orderService")，池子不会损坏，拿到的都是同一个已经创建完成的实例，不会出现一个线程拿到半成品这种容器层面的问题（前提是没有循环依赖引起的提前暴露，这个后面单独说）。

所以 Spring 在"管理实例"这件事上做得是到位的。它保证的是：同一个 beanName，并发获取时只会得到一个初始化完成的组件，不会多创建，也不会读到残缺对象。这是容器边界内的安全。

3.2 getSingleton 的完整旅程：三级缓存到底在干嘛

Spring 创建单例 bean 时会调用getSingleton方法，在 Spring 5.x 里的核心流程大致是：

1. 先从singletonObjects里查，查到就直接返回；
2. 查不到，且当前 bean 正在创建中，就去earlySingletonObjects查；
3. 再查不到，允许提前引用时，就从singletonFactories里拿一个ObjectFactory执行，生成"早期对象"放到earlySingletonObjects里。

为什么要搞这三层缓存？不是为了让单例线程安全，而是为了处理循环依赖。举个例子，A 依赖 B，B 又依赖 A，两边都用构造器注入，那谁先创建都会卡死。Spring 的解法是：创建 A 时先把一个提前暴露的 ObjectFactory 放进singletonFactories，填充属性时发现需要 B，就去创建 B，B 填充属性时引用 A，此时 A 还没创建完，但能从singletonFactories拿到 A 的早期引用，于是 B 创建成功，返回去继续完成 A。

注意，这里有一个常被忽视的并发隐患：循环依赖会让对象提前暴露。也就是说，在 A 的初始化方法（@PostConstruct等）执行完之前，另一个线程可能已经通过 B 间接拿到了 A 的引用并开始使用它。如果 A 有可变字段还没初始化好，这时读到的是默认值或 null。所以虽然容器层面没崩溃，但"提前暴露导致的字段未就绪"依然是真实风险。这也是我一直建议尽量别写循环依赖的原因之一，它省的那点设计功夫，迟早会在并发场景下加倍还回来。

3.3 容器不会替你做的事

把边界划清楚之后，责任就很明确了：

所以，遇到"单例 bean 并发出 bug"，正确的归因是"我的字段设计有问题"，而不是"Spring 的单例有问题"。搞清楚这一层，后面无论修复还是评审都会清晰很多。

4. 高发雷区：单例 Bean 的几种经典"自杀方式"

4.1 可变实例字段：最常见的隐患

这是最普遍的一类。表现形式多种多样：有人把计数用的int放字段里当序列号用，多个线程同时count++，最后拿到重复值；有人把 List、Map 当临时缓存放字段里，没有同步，并发读写丢数据；还有人把某个第三方的非线程安全对象（比如SimpleDateFormat、Cipher）放字段里复用。

我见过一个很典型的例子：一个订单服务里放了一个AtomicInteger当单号后缀，看起来用了原子类应该没问题，但生成单号的逻辑是"当前时间戳 + 计数器"，时间戳精度不够，多个线程同时生成时计数器会因为竞争而跳号，最后还是在并发压测下暴露了单号重复。原子类只保证单个操作的原子性，不保证"组合业务逻辑"的原子性。

4.2 懒加载写法里的竞态窗口

单例 bean 里最常见的懒加载写法长这样：

private Helper helper; public Helper getHelper() { if (helper == null) { helper = new Helper(); } return helper; }

这段代码在单线程下没问题，但多线程并发调用第一次时，两个线程都可能看到helper == null，于是各自 new 了一个对象，后写的覆盖先写的。更危险的是，在没有volatile和正确同步的情况下，一个线程可能看到"已经不为 null 但还没构造完成"的对象引用，也就是对象发布不完整，调用它的业务方法时拿到的是半初始化状态。

Spring bean 的依赖注入本身是在创建期完成的，大多数时候你根本不需要在方法里写懒加载。如果确实需要延迟初始化，建议把初始化放到@PostConstruct或者构造器里，让 Spring 在创建期就把事情做完；实在要懒加载，就用volatile加双重检查或者AtomicReference，别裸写if (xx == null)。

4.3 static 变量：最隐蔽的全局共享

比实例字段更隐蔽的是 static 变量。Spring 单例 bean 本身在容器里只有一个实例，但 static 变量是 JVM 级别的，哪怕你有两个 ApplicationContext、甚至容器外的普通类，都能共享同一个 static 字段。很多老项目里喜欢写private static SimpleDateFormat或者private static Map<String, Xxx> CACHE，一旦被并发访问，问题会被放大得比实例字段更严重。

而且 static 变量挂在类上，跟 Spring 的 bean 生命周期完全脱钩，没法享受容器管理，排查起来也更绕。我的建议是：单例 bean 里尽量别用 static 可变状态；如果一定要做全局缓存，请显式地交给一个专门的缓存组件（比如 Caffeine、Redis），而不是随手塞一个 static HashMap。

4.4 不可信的下游：你依赖的对象也可能不安全

还有一种雷区不是你自己写的状态，而是你依赖的对象本身不可信。比如某个工具类内部用了可变字段，对外提供了看似能复用的方法，实际上每个方法调用都会修改内部状态。SimpleDateFormat就是典型，DateFormat内部的那个Calendar字段就是为复用设计的，结果成了并发杀手。

排查技巧：看到一个类被作为单例 bean 的字段引用，先确认它是"无状态服务"还是"有状态工具"。无状态的随便放；有状态的就要问自己，这个对象内部会不会跨调用保存数据。不会的话继续用，会的话根据情况改成局部创建、ThreadLocal 或者换一个官方推荐的线程安全替代品（比如 Java 8 的DateTimeFormatter就是专门用来替代SimpleDateFormat的，天然不可变、线程安全）。

5. 修复手段对照：从无状态化到换 scope，各自的代价

5.1 无状态化是最优解，没有之一

所有修复手段里，无状态化的优先级最高。做法很简单：把可变字段从 bean 里拿掉，需要的数据通过方法参数传递，需要返回的结果用不可变对象返回。业务 bean 只保留依赖引用和不变量，状态数据只在方法内部产生和使用。

比如那个报表服务，修起来就是三步：

@Service public class ReportService { private final Cache<String, Report> cache; public ReportService(Cache<String, Report> cache) { this.cache = cache; } public String generateReport(Date date) { String day = DateTimeFormatter.ofPattern("yyyyMMdd") .format(date.toInstant().atZone(ZoneId.systemDefault())); return cache.get(day, key -> buildReport(date)).getId(); } }

DateTimeFormatter换成不可变的官方类，HashMap换成专门做缓存的 Caffeine 组件，方法内部不再持有任何共享可变状态，整个 bean 重新变成无状态单例，线程安全问题直接消失。无状态化的好处不只是线程安全，还让类更容易测试、更容易复用、更容易被 AOP 代理，收益是全方位的。

5.2 ThreadLocal 和并发容器：对症下药

有些场景确实绕不开共享状态，比如"每个线程需要自己的对象副本"或者"全局缓存需要并发读写"。这时就要选对工具。

ThreadLocal适合"同一个对象每个线程各用各的"这种诉求。比如老代码里必须用SimpleDateFormat，最经典的修法就是：

private static final ThreadLocal<SimpleDateFormat> DATE_FORMAT = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyyMMdd"));

每个线程第一次调用时创建一个自己的格式器，之后复用，线程之间互不干扰。使用时要注意：线程池里的线程是复用的，所以ThreadLocal里的值生命周期会被拉长；如果存的是跟业务上下文强相关的数据（比如登录用户），一定记得在请求结束后调remove()，否则可能造成串数据和内存泄漏。

并发容器适合"共享但需要并发安全访问"的结构。ConcurrentHashMap、CopyOnWriteArrayList、ConcurrentLinkedQueue这些是首选；计数器用AtomicLong或LongAdder；简单开关状态用volatile布尔值。

5.3 synchronized 不是不能用，但要想清楚锁什么

synchronized是最直接的方案，但代价是并发度下降。两个线程同时调用同一个有锁方法，只能排队执行。如果这个方法本身很快（比如毫秒级），锁的损耗可以接受；如果方法里包含 IO、远程调用这种慢操作，加锁就是在把并发压成串行，性能会很难看。

有一种错误做法是"方法有问题就整个方法加 synchronized"，这往往会把无关逻辑也锁住。正确姿势是缩小临界区：找到真正需要保护的共享变量操作，只对那几行加锁。能用无锁方案解决的问题（原子类、不可变对象、并发容器）就优先用无锁方案，锁是最后的手段。另外提醒一句，锁的对象要避免用this锁一个无状态 bean，毫无意义，还会莫名扩大锁范围。

5.4 改 prototype/request scope？先想清楚这个坑

网上一搜"单例线程安全"，最常见的回答就是"把 scope 改成 prototype"。这个方案看着简单，实际坑很多。

首先，prototype 只在getBean时才创建新实例，但 Spring 的依赖注入时机通常是在创建依赖方时。假如一个单例OrderService注入了一个 prototype 的ReportService，那么ReportService只会被创建一次，注入进OrderService后，之后无论多少个请求，用的还是那一个实例。也就是说，单例依赖 prototype，prototype 会退化成事实上的单例。想让每次调用都拿到新实例，还得引入ObjectProvider或者 scope proxy，复杂度反而上去了。

其次，即使真做到了每次调用新实例，也只是用"创建更多对象"换"状态隔离"，GC 压力上去了，缓存优势没了，而且别处再引用同一个 bean 时依然可能踩到并发。request/session scope 更是只适用于 Web 环境，加上代理机制后调试成本很高。除非业务有明显诉求（比如每个 HTTP 请求必须独享一个会话级对象），否则不建议为了线程安全去换 scope。线程安全的正解是把状态处理对，而不是把 bean 换掉。

6. 让线程安全问题在测试阶段现形

6.1 用并发回归测试把偶发问题打成必然

并发 bug 最大的特点是不稳定，跑一次可能没事，跑一万次出一次。所以静态代码审查只能发现问题，验证修复是否有效必须靠并发测试。我写过一个通用的并发回归测试模板，核心是让多个线程在同一时刻冲进目标方法，制造最大竞争：

@Test void concurrentGenerateReportShouldNotCorrupt() throws Exception { int threadCount = 32; int loopCount = 10000; ExecutorService pool = Executors.newFixedThreadPool(threadCount); CountDownLatch ready = new CountDownLatch(threadCount); CountDownLatch start = new CountDownLatch(1); CountDownLatch done = new CountDownLatch(threadCount); List<Throwable> errors = Collections.synchronizedList(new ArrayList<>()); for (int i = 0; i < threadCount; i++) { final int seed = i; pool.submit(() -> { ready.countDown(); try { start.await(); for (int j = 0; j < loopCount; j++) { String id = reportService.generateReport(new Date(seed * 1000L + j)); assertNotNull(id); } } catch (Throwable t) { errors.add(t); } finally { done.countDown(); } }); } ready.await(); start.countDown(); done.await(); pool.shutdown(); assertTrue("并发测试存在异常: " + errors, errors.isEmpty()); }

这里的CountDownLatch是为了把线程"压到同一起跑线"，否则线程分批启动，竞争强度不够，bug 不容易复现。循环次数要足够大，最好能让问题在测试里必然暴露。修复前先跑一遍，确认能复现异常，修复后再跑，确认通过，这才是有效的回归测试。

6.2 静态扫描和评审检查表

并发 bug 靠人肉盯总是会漏，能让工具做的事就交给工具。IDEA 自带的一些 inspection 能提示"字段可以被 final 修饰""非原子操作作用于 volatile 字段"等；PMD 和 SpotBugs 也有一组并发规则，专门查SimpleDateFormat被 static 持有、HashMap 在单例里被多线程使用之类的问题。把这些规则挂到 CI 上，每次提交自动扫描，比评审时口头提醒靠谱得多。

代码评审的时候，我手里有一份简单粗暴的检查清单，分享给你：

• 这个类的字段有哪些？哪几个是可变的？
• 可变字段会被多个线程同时读写吗？
• 引用类型字段指向的对象本身是否线程安全？
• 有没有懒加载赋值、double-check 写法？
• 有没有 static 可变状态？
• 有没有在方法里修改"传进来的对象"或"字段引用的对象"？

前面五个问题里只要有一个是"有/会"，这个 bean 就必须给出明确的处理方案，否则不许合代码。

6.3 设计习惯：把"有状态"当成异常信号

说到根子上，单例线程安全不是一个"技巧问题"，而是一个"设计问题"。一个设计良好的业务 bean 天然就是无状态的，请求进来、算完、返回，不残留任何中间状态在字段里。凡是需要状态的地方，要么放在方法参数里显式传递，要么下沉到专门的存储组件（数据库、Redis、缓存组件），要么使用不可变值对象。

我现在写一个新的 singleton bean 时，会强制自己过一遍字段清单：每个字段是 final 吗？可变吗？会被写在哪？为什么要放在 bean 里而不是方法里？如果答不上来"必须放这里"的理由，就把它拿掉。这个习惯帮我挡掉了大量潜在并发事故，也让我在评审别人的代码时能更快地定位风险点。

最后再分享一个小技巧：如果你在排查一个偶发但找不出原因的接口异常，别急着怀疑框架、怀疑中间件，先把自己写的单例 bean 的所有可变字段拉出来列出，给每个字段旁边写清"被谁写、被谁读"。大部分诡异问题的答案，就藏在这张表里。