spring boot rest接口天然线程安全，关键在于避免多线程共享可变变量；单例bean的可变成员变量是主要风险源，应通过无状态设计、threadlocal、并发集合、原子类或completablefuture等方案安全处理共享状态。
Spring Boot 处理 REST 接口并发请求时，线程安全问题本质不是框架“自动解决”的，而是由开发者对共享状态的控制方式决定的。关键不在于“有没有并发”，而在于“有没有被多线程同时读写的可变共享变量”。只要避开常见陷阱，REST 接口天然就是线程安全的。
默认控制器和 DTO 是线程安全的
Spring MVC 为每个 HTTP 请求创建全新的 Controller 实例（实际是单例 Controller + 新建的参数对象），JSON 反序列化生成的请求体（如 RequestBody 对象）也是每次请求独立的新对象。这意味着：
- Controller 中的局部变量、方法参数、新建的 List/Map 等，完全隔离，无需额外处理；
- 静态内部类里的实例字段（如 private String requestId）也属于每个新实例，彼此不共享；
- 只要不把请求数据存到类级别字段（private List
cache ）、静态变量或单例 Bean 的成员变量里，就不存在污染风险。
单例 Bean 是并发问题的主要源头
Spring 默认所有 @Service / @Component Bean 都是单例，整个应用共用一个实例。如果在其中定义了可变成员变量，就会被所有请求线程共享：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 例如 private int counter = 0;，多个线程执行 counter++ 会丢失更新；
- 又如 private List
tempResults; 被不同请求反复 add()，结果互相覆盖； - 即使服务方法返回 new ArrayList()，若该 list 被赋值给类字段或缓存起来，后续线程仍可能修改它。
安全处理共享状态的实用方案
遇到必须跨请求维护状态的场景，应按需选择合适机制，而非直接暴露可变字段：
- 无状态优先：把计算逻辑全放在方法内，返回不可变结果（如 List.of()、ImmutableList），让调用方按需复制；
- ThreadLocal：适合单次请求内跨方法传递上下文（如 traceId、用户权限），每个线程独享副本，用完记得 remove()；
-
并发集合 + 明确标识：并行调用多个下游接口时，用 ConcurrentHashMap
存响应，键用订单号等唯一 ID，避免 ArrayList.add() 的竞态； - 锁或原子类：仅当真需全局计数或状态同步时使用，如 AtomicInteger 替代 int，或 synchronized 块包裹临界区；
-
CompletableFuture 封装结果：异步调用中，服务层返回 CompletableFuture
- >
异步与并行调用中的典型污染点
很多问题发生在“以为异步就安全”或“以为并行就高效”的误操作中：
- 用 runAsync() 启动任务，却在主线程继续操作服务返回的同一个 ArrayList 引用；
- 用 parallelStream().forEach() 并发请求，但往非线程安全的 ArrayList.add() 写结果，导致数据丢失或异常；
- 把 CompletableFuture 的结果 list 直接塞进类字段，下次请求一调用就拿到脏数据。
真正安全的做法是：每次请求都走“新建 → 计算 → 返回不可变结果 → 消费即弃”这一闭环。
