并行流中threadlocal上下文丢失，因forkjoinpool.commonpool()复用线程且inheritablethreadlocal仅在创建时复制值；业务标识类宜用transmittablethreadlocal透传，日志类需手动put/remove，web类应提前提取字段传参。

并行流中ThreadLocal上下文为何会丢失

并行流默认使用ForkJoinPool.commonPool()执行任务，其工作线程被长期复用。而InheritableThreadLocal仅在子线程创建时复制父线程值，后续复用时不会刷新——主线程设置的用户ID、请求ID、Log4j2的ThreadContext或Spring的RequestContextHolder，在并行任务中全为空。这不是代码写错，是JDK线程池与ThreadLocal机制天然不兼容。

识别关键上下文类型并分类应对

不同场景丢失的上下文性质不同，需区别处理：

• 业务标识类：如用户ID、traceId、批次号——适合用TransmittableThreadLocal（TTL）自动透传
• 日志上下文类：Log4j2的ThreadContext——需在并行任务入口手动put，出口remove
• Web请求类：Spring的RequestContextHolder——不能直接取，应提前提取必要字段（如requestURI、userId）作为参数传入lambda
• 临时状态类：如计数器、缓存Map——避免共享，改用线程局部集合（如ThreadLocal.withInitial(HashMap::new)）

三种可靠防护方案实操要点

不依赖“运气”，要结构化防护：

• TTL + 线程工厂定制：替换commonPool为TTL感知的ForkJoinPool，需调用TtlForkJoinPoolHelper.enable() 并配置自定义ForkJoinWorkerThreadFactory
• 手动包装并行操作：对每个forEach/map逻辑外层加try-finally，确保ThreadContext.put("key", value)后必remove()
• 参数化传递替代隐式上下文：把主线程中已知的上下文值（如tenantId、batchId）显式作为闭包变量捕获，而非依赖ThreadLocal查找

必须同步检查的并发副作用点

上下文丢失常伴随更隐蔽的数据问题，需一并排查：

• 写入集合是否线程安全：ArrayList::add非原子，改用CopyOnWriteArrayList或Collectors.toList()配合collect归约
• 共享对象是否可变：避免在parallelStream中修改外部HashMap或静态计数器，改用AtomicInteger或归约式聚合
• 资源清理是否遗漏：ThreadLocal未remove()会导致内存泄漏，尤其在线程池复用场景下
• 并行度是否失控：未限制commonPool并行度可能耗尽CPU，建议通过System.setProperty("java.util.concurrent.ForkJoinPool.common.parallelism", "4")设合理值