摘要：我当时脑袋一热，差点脱口而出“线程安全个毛线！”但还是忍住了，毕竟线程安全这个事儿，说容易也容易，说复杂也真复杂，特别是放在Spring框架这个大环境下，想要搞清楚背后的逻辑和原理，还真得慢慢讲。

“小米，面试官问我：Spring框架中的单例Bean是线程安全的吗？我卡壳了！”

昨天晚上，我刚准备关电脑，来自深圳的老同学阿斌给我发来了一条微信。

我当时脑袋一热，差点脱口而出“线程安全个毛线！”但还是忍住了，毕竟线程安全这个事儿，说容易也容易，说复杂也真复杂，特别是放在 Spring框架 这个大环境下，想要搞清楚背后的逻辑和原理，还真得慢慢讲。

于是，我泡了杯热茶，打开了微信语音，和阿斌聊了快一个小时。今天干脆就把这个问题整理成文章，分享给大家：

先别急着回答“安全”还是“不安全”，我们得先弄清楚，这个问题背后的核心到底是什么？

这是一个 “理论 + 实战” 的复合型问题：

所以，这不是一个 Yes or No 的问题，而是一个需要展开说明的高质量问题。

我们先回顾一下基础知识：

在Spring中，Bean的默认作用域是 Singleton（单例）

什么意思？

就是说，Spring容器中，每个Bean默认只会创建一个实例，而这个实例在容器中是共享的。每次你通过 @Autowired 或 ApplicationContext.getBean 拿到的，都是这个唯一的实例。

听起来是不是有点像设计模式里的单例？是的，但不是一模一样的。Spring中的“单例”，是容器级别的单例，不是JVM级别的那种 private static 单例。

举个不恰当但形象的例子：

我们先给出一个最直接的答案：

Spring中的单例Bean，本身不是线程安全的！

为什么？

因为 Spring并不会自动给你加锁 或提供同步控制。线程安全与否，取决于你自己的代码写法。

比如，下面这个例子就可能出问题：

这段代码中，count++ 并不是原子操作，多个线程同时调用 increment 方法时，就会发生竞态条件（race condition），结果可能不一致，甚至少加、多加。

这就得根据 业务场景 来具体分析了。

1. 无状态的Bean是线程安全的

什么叫无状态？就是不依赖成员变量，方法内部没有共享数据。

这类Bean天生线程安全，因为它不依赖任何共享状态。多个线程调用也不会互相影响。

2. 有状态的Bean要小心

只要你在Bean里维护了状态，比如计数器、缓存、List、Map，那就有风险了！

ArrayList 不是线程安全的，多线程下会出问题，轻则抛异常，重则数据错乱。

这部分就是进阶加分项了，我和阿斌在微信上聊得最多的就是这一块。

方案一：使用线程安全的集合

或者直接用 CopyOnWriteArrayList、ConcurrentHashMap 这些并发容器。

方案二：方法加锁（不推荐）

虽然这样也能实现线程安全，但性能可能不太好，不建议滥用。

方案三：换成原型Bean（prototype）

如果每次都要一个新的实例，那就用 @Scope("prototype")。

但这样Spring就不负责生命周期管理了，用的时候要注意。

方案四：用ThreadLocal存储线程私有数据

每个线程维护自己的 logs，互不干扰，非常适合日志、上下文这些场景。

这是一个设计上的深思熟虑的选择。

原因一：性能高！

每个Bean只创建一次，省内存，省CPU。对于一些重量级对象（数据库连接池、服务对象），尤其重要。

原因二：方便依赖注入

大多数业务组件其实是无状态的，没必要每次都创建。

原因三：避免重复配置

很多开发者不会管理对象的生命周期，让Spring帮你统一管理更可控。

标准回答可以这样说：

Spring中的单例Bean是容器级别的单例，即容器中只存在一个Bean实例。但这并不意味着它本身是线程安全的。

线程安全与否取决于Bean是否是无状态的。对于无状态的Bean（例如只执行查询、无共享成员变量），是线程安全的；

但如果Bean中存在可变的成员变量，且被多个线程共享访问，则需要开发者自己保证线程安全，比如使用同步机制、线程安全的集合、ThreadLocal 或者更改作用域为 prototype。

因此，Spring不会自动保证线程安全，开发者需要根据具体场景进行设计。

其实我一直觉得，技术是一种“可控的复杂”。

这个问题最可怕的地方，是它表面上很简单，一句话就能问完，但背后涉及了：

就像你看到一片海面，可能以为水很浅，但跳进去才发现下面藏着一整座珊瑚礁。

希望这篇文章能帮你理清这个面试题的来龙去脉。

如果你喜欢这种“技术故事 + 面试拆解”的风格，记得 点个在看、点个赞、分享给你的面试搭子！

来源：尚林教育