Tomcat运行的Spring Web应用使用Java Thread API是否安全？相关疑问解析
核心结论
Java EE/Servlet环境禁止直接使用Thread、Timer API的规则，完全适用于Spring Web应用——因为Spring Web本质是运行在Servlet容器中的托管环境，直接创建线程会脱离容器管控，引发一系列问题。
一、直接创建Thread会丢失哪些上下文/参数？
直接用new Thread()启动线程时，新线程无法继承原请求线程的以下关键上下文：
- Web请求上下文：
RequestContextHolder中存储的HttpServletRequest、HttpServletResponse属性，比如请求头、请求参数、会话信息（Session）； - Spring作用域Bean：
@RequestScope、@SessionScope的Bean实例，新线程无法直接注入或获取这些作用域的Bean； - 安全上下文：
SecurityContextHolder中当前登录用户的认证信息（比如用户名、权限），在新线程中调用权限校验会失败； - 事务上下文：原线程的事务上下文不会传播到新线程，新线程中的数据库操作无法参与原事务。
举个实际例子：在Controller里启动新Thread，调用RequestContextHolder.getRequestAttributes()会返回null，也无法直接获取当前登录用户的Authentication对象。
二、是否存在可以安全使用Thread API的场景？
理论上仅有一种极端场景：完全脱离Web上下文的纯计算任务——比如无需访问任何请求参数、会话数据、Spring作用域Bean，只是独立执行一段纯逻辑（比如计算某个数学公式）。
但即使是这种场景，也不推荐直接使用Thread API：因为容器无法管控这些线程的生命周期，应用关闭时无法优雅终止线程，可能导致资源泄漏（比如未关闭的IO流、数据库连接）。
三、Spring的TaskExecutor、@Async是如何解决问题的？
Spring提供的TaskExecutor、@Async本质是容器托管的线程池方案，从两个核心维度解决了直接用Thread的问题：
1. 容器管控线程生命周期
Spring的TaskExecutor（比如ThreadPoolTaskExecutor）由Spring容器管理，应用启动时初始化线程池，关闭时会优雅停止所有线程（等待正在执行的任务完成，或超时强制终止），避免资源泄漏。
2. 自动上下文传播
Spring会通过TaskDecorator机制，自动将原线程的上下文复制到新线程中：
- 执行异步任务前，把原线程的
RequestAttributes、SecurityContext等上下文保存下来； - 在新线程执行任务时，将这些上下文设置到新线程的
RequestContextHolder、SecurityContextHolder中； - 任务执行完成后，清除新线程的上下文，避免污染后续任务。
比如使用@Async注解时，Spring会自动处理上下文传播，你在异步方法中可以正常调用RequestContextHolder.getRequestAttributes()获取请求信息，或通过SecurityContextHolder获取当前用户的认证数据。
内容的提问来源于stack exchange，提问作者nikiforov.java
