PDF大白话说Java面试题 — 06_Spring篇第13题Spring 中 Bean 是线程安全的吗回答核心考点 Spring Bean 的线程安全性是并发编程与 Spring 框架交叉的经典问题大厂面试不会只问是否安全而是深入考察Spring 作用域与线程安全的关系singleton/prototype/request/session、有状态 Bean vs 无状态 Bean 的设计原则、ThreadLocal 在 Spring 中的正确使用姿势内存泄漏风险、以及Scope(proxyMode ScopedProxyMode.TARGET_CLASS)解决作用域代理问题的原理。面试官真正想判断的是你是否能从框架设计层面理解线程安全的本质以及能否在 Controller 层、Service 层、DAO 层等不同层级做出正确的线程安全设计。1. Spring Bean 作用域与线程安全性Spring 定义了 6 种 Bean 作用域其中 4 种在 Web 环境下可用作用域说明线程安全性适用场景singleton默认每个 Spring 容器只有一个实例不安全有状态时无状态 Service、DAO、工具类prototype每次获取都创建新实例安全天然隔离有状态对象但创建开销大request每个 HTTP 请求一个实例安全请求隔离Web 环境请求级状态session每个 HTTP Session 一个实例安全会话隔离Web 环境用户级状态application每个 ServletContext 一个实例不安全有状态时全局配置、缓存websocket每个 WebSocket 连接一个实例安全连接隔离WebSocket 场景关键结论Spring 的singleton作用域本身不提供线程安全保证线程安全取决于 Bean 的状态设计。2. 有状态 Bean vs 无状态 Bean——设计的分水岭2.1 无状态 Bean线程安全无状态 Bean 是指不保存任何实例变量的 Bean所有操作都通过方法参数和返回值完成ServicepublicclassUserService{AutowiredprivateUserDaouserDao;// 依赖注入本身无状态publicUsergetUser(Longid){returnuserDao.findById(id);// 纯查询不修改实例变量}publicvoidupdateUser(Useruser){userDao.update(user);// 操作通过参数传递无实例变量修改}}无状态 Bean 的特征没有可变的实例变量final常量除外不保存用户会话信息或请求上下文方法之间不共享状态天然线程安全所有线程共享同一个实例无风险。Spring 中 99% 的 Bean 应该是无状态的Service、DAO、Mapper、Repository 等通常都是无状态设计。2.2 有状态 Bean线程不安全有状态 Bean 保存了可变的实例变量多个线程并发访问时产生竞态条件Service// ❌ 错误有状态的单例 BeanpublicclassCounterService{privateintcount0;// 实例变量线程共享publicvoidincrement(){count;// 非原子操作线程不安全}publicintgetCount(){returncount;}}并发问题演示时间线线程 A线程 Bcount 值T1读取 count 0—0T2—读取 count 00T3计算 0 1 1—0T4—计算 0 1 10T5写入 count 1—1T6—写入 count 11两个线程各执行一次increment()预期结果为 2实际结果为 1丢失了一次更新。2.3 有状态 Bean 的典型误用场景误用场景问题正确做法Controller 中保存用户上下文多请求共享状态数据串乱使用方法参数传递或 ThreadLocalService 中缓存查询结果到实例变量多线程覆盖缓存使用外部缓存Redis/Caffeine工具类中保存临时计算状态并发计算结果互相干扰使用局部变量或改为无状态Autowired的 Bean 被修改依赖对象被替换使用final 构造器注入3. 保证线程安全的五种方案3.1 方案一无状态设计首选将 Bean 设计为无状态所有数据通过方法参数传递ServicepublicclassCounterService{// ✅ 无实例变量天然线程安全publicintincrement(intcount){returncount1;// 通过参数和返回值传递状态}}优势零同步开销性能最优代码最清晰。适用场景Service 层、DAO 层、工具类。3.2 方案二不可变对象使用final修饰字段对象创建后不可变ServicepublicclassConfigService{privatefinalMapString,StringconfigMap;// final 引用publicConfigService(Value(${app.config})Stringconfig){this.configMapparseConfig(config);// 构造时初始化之后不可变}publicStringgetConfig(Stringkey){returnconfigMap.get(key);// 只读操作线程安全}}注意final只保证引用不可变如果引用对象本身可变如ArrayList仍需同步。3.3 方案三ThreadLocal线程隔离ThreadLocal为每个线程提供独立的变量副本实现线程级隔离ServicepublicclassRequestContextService{// 每个线程有独立的 SimpleDateFormat 副本privatestaticfinalThreadLocalSimpleDateFormatdateFormatHolderThreadLocal.withInitial(()-newSimpleDateFormat(yyyy-MM-dd HH:mm:ss));publicStringformatDate(Datedate){returndateFormatHolder.get().format(date);}}ThreadLocal 在 Spring 中的经典应用场景使用方式说明日期格式化ThreadLocalSimpleDateFormatSimpleDateFormat非线程安全数据库连接ThreadLocalConnectionSpring 事务管理器底层实现用户上下文ThreadLocalUserContext拦截器设置Service 层获取请求追踪ThreadLocalTraceId全链路日志追踪⚠️ ThreadLocal 内存泄漏风险ServicepublicclassUserContextHolder{privatestaticfinalThreadLocalUsercurrentUsernewThreadLocal();publicstaticvoidsetUser(Useruser){currentUser.set(user);}publicstaticUsergetUser(){returncurrentUser.get();}// ✅ 必须在使用完毕后清理publicstaticvoidclear(){currentUser.remove();// 防止内存泄漏}}// 在拦截器中清理publicclassUserContextInterceptorimplementsHandlerInterceptor{OverridepublicvoidafterCompletion(HttpServletRequestrequest,HttpServletResponseresponse,Objecthandler,Exceptionex){UserContextHolder.clear();// 请求结束后清理}}内存泄漏原因ThreadLocal 的键是弱引用WeakReferenceThreadLocal?但值是强引用。如果线程池复用线程线程结束时 ThreadLocal 的键被 GC但值仍被线程的ThreadLocalMap引用导致内存泄漏。解决方案使用完必须remove()使用try-finally确保清理使用InheritableThreadLocal时注意子线程继承问题使用TransmittableThreadLocal阿里开源解决线程池传递问题。3.4 方案四同步机制synchronized/Lock/Atomic当必须共享可变状态时使用同步机制ServicepublicclassCounterService{privatefinalAtomicIntegercountnewAtomicInteger(0);// ✅ 原子操作publicvoidincrement(){count.incrementAndGet();// CAS 无锁线程安全}publicintgetCount(){returncount.get();}}同步方案适用场景性能代码复杂度synchronized简单临界区低阻塞低ReentrantLock需要超时/中断/条件变量中阻塞中AtomicInteger/Long简单计数器高CAS低LongAdder高并发计数器极高分段低ConcurrentHashMap并发 Map高分段锁低CopyOnWriteArrayList读多写少列表高无锁读低3.5 方案五改变作用域prototype/request当 Bean 必须保存状态时改变作用域避免共享ComponentScope(valueWebApplicationContext.SCOPE_REQUEST,proxyModeScopedProxyMode.TARGET_CLASS)publicclassRequestContext{privateStringtraceId;privateLonguserId;// ... 请求级状态}proxyMode的作用当singletonBean 注入request作用域 Bean 时由于singletonBean 只创建一次而requestBean 每个请求都不同直接注入会导致requestBean 在首次注入后固定不变。ScopedProxyMode.TARGET_CLASSCGLIB 代理或ScopedProxyMode.INTERFACESJDK 代理会为作用域 Bean 创建代理对象每次调用时从当前作用域如当前 Request获取真实实例Service// singletonpublicclassUserService{AutowiredprivateRequestContextrequestContext;// 注入的是代理对象publicvoiddoSomething(){// 每次调用都会从当前 Request 获取真实实例StringtraceIdrequestContext.getTraceId();}}4. Spring 各层的线程安全设计规范层级作用域状态设计线程安全策略Controllersingleton无状态方法参数传递请求数据不保存实例变量Servicesingleton无状态纯业务逻辑依赖通过注入获取DAO/Mappersingleton无状态只负责数据访问不保存查询结果Entity/POJOprototype有状态每个请求/线程独立实例配置类singleton不可变final字段构造时初始化缓存组件singleton有状态缓存数据使用线程安全的缓存Redis/Caffeine/ConcurrentHashMap5. 生产环境避坑指南5.1 不要在单例 Bean 中使用实例变量保存请求数据RestController// ❌ 致命错误单例 有状态publicclassUserController{privateUsercurrentUser;// 多个请求共享GetMapping(/user/{id})publicUsergetUser(PathVariableLongid){currentUseruserService.findById(id);// 请求A的数据被请求B覆盖returncurrentUser;}}// ✅ 正确无状态设计RestControllerpublicclassUserController{GetMapping(/user/{id})publicUsergetUser(PathVariableLongid){returnuserService.findById(id);// 直接返回不保存状态}}5.2 SimpleDateFormat 必须用 ThreadLocalSimpleDateFormat是非线程安全的多线程共享会导致日期解析错误ServicepublicclassDateService{// ❌ 错误共享 SimpleDateFormatprivatestaticfinalSimpleDateFormatsdfnewSimpleDateFormat(yyyy-MM-dd);// ✅ 正确ThreadLocal 隔离privatestaticfinalThreadLocalSimpleDateFormatsdfHolderThreadLocal.withInitial(()-newSimpleDateFormat(yyyy-MM-dd));}Java 8 推荐使用DateTimeFormatter线程安全彻底告别 ThreadLocalprivatestaticfinalDateTimeFormatterformatterDateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss);5.3 注意 Async 与 ThreadLocalAsync使用线程池执行异步任务子线程无法继承父线程的ThreadLocalServicepublicclassUserService{publicvoidprocess(){UserContextHolder.setUser(newUser(admin));// 主线程设置asyncTask.execute();// 子线程中 UserContextHolder.getUser() null}}解决方案使用InheritableThreadLocal或阿里TransmittableThreadLocalTTL。5.4 线程池场景下的 ThreadLocal线程池复用线程如果不清理 ThreadLocal下一个任务可能读到上一个任务的数据executor.execute(()-{try{ThreadLocalHolder.set(data);// 执行业务逻辑...}finally{ThreadLocalHolder.remove();// ✅ 必须清理}});5.5 警惕 Spring 代理对象的线程安全Transactional、Cacheable等注解基于 AOP 代理实现代理对象本身是单例且线程安全的。但目标对象中的实例变量仍然需要开发者保证线程安全。6. 面试官追问与高分回答模板追问 1“Spring 中的 Bean 是线程安全的吗”低分回答“不是单例 Bean 多线程共享有状态时不安全。”没有区分状态设计高分回答Spring Bean 的线程安全性取决于作用域和状态设计不能一概而论默认singleton作用域Spring 容器只创建一个实例多线程共享。如果 Bean 是无状态的没有可变实例变量则天然线程安全如果 Bean 是有状态的保存了可变实例变量则线程不安全。prototype/request/session作用域每个线程/请求/会话独立实例天然线程安全但创建开销大。因此Spring Bean 是否线程安全核心在于状态设计而非作用域。Spring 官方推荐将 Bean 设计为无状态这是 Service 层、DAO 层的最佳实践。追问 2“如何保证 Spring Bean 的线程安全”高分回答保证线程安全有五种方案按推荐优先级排序无状态设计首选Bean 不保存实例变量所有数据通过方法参数传递。零同步开销性能最优代码最清晰。Spring 中 99% 的 Bean 应该如此设计。不可变对象使用final字段对象创建后不可变。注意final只保证引用不可变引用对象本身可变时仍需同步。ThreadLocal 线程隔离为每个线程提供独立变量副本。适用于日期格式化、用户上下文等场景。但必须注意内存泄漏使用完必须remove()。同步机制AtomicInteger、ConcurrentHashMap、synchronized等。适用于必须共享可变状态的场景。改变作用域Scope(prototype)或Scope(request)配合proxyMode TARGET_CLASS。适用于必须保存状态且无法重构的场景但创建开销大。推荐优先级无状态 不可变 ThreadLocal 同步机制 改变作用域。追问 3“ThreadLocal 在 Spring 中怎么用有什么风险”高分回答ThreadLocal 在 Spring 中的典型应用包括日期格式化SimpleDateFormat非线程安全用 ThreadLocal 隔离用户上下文拦截器设置当前用户Service 层获取数据库连接Spring 事务管理器底层用 ThreadLocal 绑定连接请求追踪TraceId 全链路传递。内存泄漏风险ThreadLocal 的键是WeakReferenceThreadLocal?但值是强引用。线程池场景下线程复用不结束ThreadLocalMap 中的值不会被清理导致内存泄漏。解决方案使用完必须调用remove()使用try-finally确保清理在拦截器的afterCompletion()中清理使用TransmittableThreadLocal阿里 TTL解决线程池传递和自动清理问题。Java 8 替代方案DateTimeFormatter线程安全可替代ThreadLocalSimpleDateFormat。追问 4“Scope(proxyMode TARGET_CLASS) 是做什么的”高分回答proxyMode用于解决不同作用域 Bean 的注入问题。当singletonBean如 Service注入request作用域 Bean如 RequestContext时Service 只创建一次如果直接注入 RequestContext会在首次注入时固定为一个 Request 的实例后续请求获取的是旧数据。ScopedProxyMode.TARGET_CLASS会为requestBean 创建CGLIB 代理对象。Service 注入的是代理对象每次调用代理对象的方法时代理会从当前 Request 作用域中获取真实的 Bean 实例确保每次请求获取的都是当前请求的实例。类似地ScopedProxyMode.INTERFACES使用 JDK 动态代理要求目标类实现接口。追问 5“Spring 的 Transactional 是线程安全的吗”高分回答Transactional本身是线程安全的原因代理对象线程安全Spring 为 Bean 创建的 AOP 代理对象是单例的代理逻辑开启事务、提交/回滚是无状态的事务上下文线程隔离Spring 使用TransactionSynchronizationManager底层是 ThreadLocal将数据库连接绑定到当前线程每个线程有独立的事务上下文事务管理器无状态DataSourceTransactionManager等管理器本身不保存事务状态。但需要注意如果事务方法中修改了 Bean 的实例变量这些变量仍然是线程共享的需要开发者自行保证线程安全。Transactional只保证事务本身的线程安全不保证业务数据的线程安全。追问 6“你在项目中怎么设计线程安全的 Spring Bean”高分回答我的设计原则是分层的Controller 层严格无状态不保存任何实例变量。请求数据通过方法参数PathVariable、RequestBody传递响应直接返回。Service 层严格无状态业务逻辑通过参数和返回值传递。需要共享的缓存使用外部服务Redis需要计数的使用LongAdder或 Redis。DAO/Mapper 层无状态只负责数据访问。用户上下文使用 ThreadLocal 传递在拦截器中设置在afterCompletion()中清理。Java 8 用DateTimeFormatter替代ThreadLocalSimpleDateFormat。配置类使用final不可变对象构造器注入。唯一使用有状态 Bean 的场景是请求级上下文如RequestContext使用Scope(value SCOPE_REQUEST, proxyMode TARGET_CLASS)并确保通过代理访问。7. 方案选型速查表业务场景推荐方案核心理由Service/DAO 层设计无状态 Bean零同步开销性能最优Spring 推荐配置类不可变对象final构造时初始化之后只读日期格式化DateTimeFormatterJava 8线程安全无需 ThreadLocal用户上下文传递ThreadLocal 拦截器清理线程隔离记得 remove()简单计数器AtomicIntegerCAS 无锁性能高高并发计数器LongAdder分段累加避免 CAS 冲突请求级状态Scope(request) proxyMode请求隔离通过代理访问会话级状态Scope(session) proxyMode会话隔离线程池任务上下文TransmittableThreadLocal解决线程池传递和清理问题并发 MapConcurrentHashMap分段锁高并发安全读多写少列表CopyOnWriteArrayList无锁读写时复制面试官想要的满分总结Spring Bean 的线程安全性不是框架保证的而是开发者设计的责任。默认singleton作用域下无状态 Bean 天然线程安全有状态 Bean 必须采取保护措施。理解线程安全必须抓住三个核心状态是根源线程安全问题的本质是共享可变状态。无状态设计从根本上消除了这个问题是 Spring 开发的金标准。ThreadLocal 是双刃剑它实现了线程隔离但内存泄漏风险尤其是线程池场景必须警惕。使用完必须remove()Java 8 优先用DateTimeFormatter等线程安全类替代。作用域代理解决跨域注入singletonBean 注入requestBean 时必须使用proxyMode TARGET_CLASS创建作用域代理确保每次调用获取当前作用域的真实实例。工程实践中99% 的 Spring Bean 应该是无状态的。Controller、Service、DAO 层都不应保存实例变量。只有真正的请求级/会话级状态才考虑有状态设计且必须通过作用域代理或 ThreadLocal 隔离。记住线程安全不是事后加锁而是事前设计。觉得对您有帮助麻烦点点关注啦您的关注是我创作的最大动力~