直接迁移串行for循环到fork/join需三重判断：是否纯计算密集型、无共享状态依赖、结果可合并；否则优先选虚拟线程或抽离计算内核。
直接迁移串行 for 循环到 Fork/Join 不是简单“加线程”，关键在于识别可并行边界、控制拆分粒度、隔离状态依赖，并保留原有语义与可观测性。平滑重构的核心不是一步到位，而是分阶段验证、渐进替换、风险可控。
明确哪些循环能迁、哪些必须绕开
不是所有批量循环都适合 Fork/Join。先做三重判断：
- 是否纯计算密集型：循环体里主要是 CPU 运算（如数值转换、加密校验、规则匹配），没有数据库查询、HTTP 调用、文件读写等 IO 操作；
- 是否无共享状态依赖：每次迭代只读输入数据、只写局部变量或独立输出容器（如每个 item 生成一个 DTO），不修改全局 Map、静态计数器、共享 List；
- 是否结果可合并：最终需要的是总和、最大值、聚合列表、统一响应体等，而非强顺序执行副作用（如按序发消息、逐条落库）。
若含 IO 或状态竞争，优先考虑虚拟线程 + 结构化并发，或保留主流程串行，仅将计算内核抽离为 Fork/Join 子任务。
设计可验证的递归任务骨架
避免直接改原方法，新建 RecursiveTask
- 构造参数只传不可变输入（如原始 List、数组、配置对象），不传 Service 或 DAO；
- 设置合理 THRESHOLD（如 500–2000 条/任务），太小导致调度开销压倒收益，太大则负载不均；
- compute() 中严格区分：小任务直算（for 循环遍历子段）、大任务 fork+compute+join（左 fork、右 compute、再 join）；
- 首次上线时在 compute() 中加轻量日志（如“[ForkJoin] 处理 [12000–12499] 共 500 条”），便于比对串行结果与执行范围。
安全过渡的三步走策略
不删除旧代码，用灰度方式逐步接管：
- Step 1：双跑比对 —— 新增 Fork/Join 版本方法，与原串行方法同参同调，返回值做 assertEquals，记录耗时与结果一致性；
- Step 2：开关控制 —— 引入配置项（如 batch.process.mode=serial|forkjoin），线上可随时切回；
- Step 3：分批放量 —— 按业务维度分流（如“订单号尾号为 0–3 走并行，其余走串行”），观察错误率、GC、线程池队列水位后再全量。
规避常见陷阱的实操细节
这些点看似微小，但极易引发线上问题：
- 别用 CommonPool 做核心业务：默认 ForkJoinPool.commonPool() 是共享池，被 parallelStream、CompletableFuture 等共用，建议显式创建专用 ForkJoinPool（new ForkJoinPool(4)），避免任务饥饿；
- 异常要主动捕获封装：RecursiveTask 的 compute() 抛异常会包装成 CompletionException，需在 join() 后 catch 并还原业务异常类型，否则上层无法识别错误码；
- 禁止在任务中初始化重量级资源：如 new ObjectMapper、创建 HttpClient 实例——应在任务外构建好，作为 final 字段传入；
- 慎用 ThreadLocal：Fork/Join 工作线程复用频繁，ThreadLocal 可能残留旧数据，改用任务局部变量或显式 cleanup。
