spring 容器管理的 bean 默认是单例作用域，其引用存于栈、对象实例存于堆；线程安全与否取决于 bean 自身是否可变——无状态 bean 天然线程安全，有状态 bean 需显式同步或重构。
spring 容器管理的 bean 默认是单例作用域，其引用存于栈、对象实例存于堆；线程安全与否取决于 bean 自身是否可变——无状态 bean 天然线程安全，有状态 bean 需显式同步或重构。
在 Spring 应用中，通过 @Autowired 注入的 Bean（如 MyClass myClass;）默认以 Singleton 作用域存在于应用上下文（ApplicationContext）中。这意味着：整个 JVM 生命周期内，该 Bean 仅被创建一次，所有线程共享同一个对象实例——该实例存储在堆内存中；而每个线程调用时持有的 myClass 变量本身是一个引用，存于各自线程的栈内存中。
✅ 关键结论：
Spring 框架自身完全负责 Bean 的实例化与注入过程（即对象创建、依赖装配、生命周期管理），该过程是线程安全的——你无需也不应手动在多线程中重复构造或缓存 Bean。但Bean 实例本身的线程安全性，由开发者定义，Spring 不做保证。
为什么“单例 + 共享”不等于“线程不安全”？
根本在于：线程安全的本质是“对共享可变状态的并发访问控制”。若一个 Singleton Bean 是无状态（stateless）或不可变（immutable）的，则天然线程安全。例如：
@Component
public class Calculator {
// ✅ 无任何成员变量 → 无共享可变状态 → 线程安全
public int add(int a, int b) {
return a + b; // 仅操作局部变量（栈上），无副作用
}
}
反之，若引入可变成员变量，则风险立现：
@Component
public class Counter {
private int count = 0; // ❌ 共享可变状态 → 非线程安全
public int increment() {
return ++count; // 竞态条件：读-改-写非原子操作
}
}
多个线程并发调用 increment() 将导致结果丢失（如预期100次调用得100，实际可能为98）。
保障线程安全的实践方案
| 方案 | 说明 | 示例 |
|---|---|---|
| ✅ 推崇：无状态设计 | 移除所有实例/静态可变字段，仅依赖方法参数与局部变量 | 如上 Calculator 类 |
✅ 使用 final + 不可变对象 |
成员变量声明为 final，且类型本身不可变（如 String, LocalDateTime, ImmutableList） |
private final String serviceName = "API_V1"; |
| ✅ 同步控制 | 对临界区加锁（synchronized、ReentrantLock）或使用线程安全类型（AtomicInteger, ConcurrentHashMap） |
private AtomicInteger count = new AtomicInteger(0); → count.incrementAndGet();
|
| ⚠️ 避免：ThreadLocal（慎用） | 虽可隔离线程状态，但易引发内存泄漏（尤其在线程池场景），且违背 DI 共享初衷，应优先考虑重构为无状态 |
注意事项与最佳实践
-
不要在 Singleton Bean 中持有 HTTP Session、Request 或 User Context 等请求级对象——它们生命周期与线程绑定，强行保存将导致严重数据污染。需改用
@Scope("request")或RequestContextHolder。 -
Spring AOP 代理（如
@Transactional）不影响线程安全性：代理层本身无状态，但被代理的目标 Bean 仍需自行保障。 -
测试验证：可通过 JUnit +
ParallelTestExecutor或 JMH 编写并发测试，模拟高并发调用，验证计数类、缓存类等敏感组件的行为一致性。
总之，Spring 的 DI 解决了“对象如何创建与复用”，而线程安全是“对象如何正确使用”的契约。牢记：容器不担保行为，只提供基础设施；安全始于设计，成于实现。
