java中批量任务应避免completablefuture默认的forkjoinpool.commonpool，须用自定义threadpoolexecutor：io型设核心线程数为cpu核数×2～4、linkedblockingqueue；cpu型设核心线程数≈cpu核数，拒绝策略用callerrunspolicy；批量提交后用allof协调、遍历join取值；无关任务用allof，并行依赖用thencombine/thencompose并传自定义池；单任务加ortimeout和exceptionally，整批超时用anyof熔断。
Java 中线程池结合 CompletableFuture 处理批量任务，核心是不让 CompletableFuture 跑在 ForkJoinPool.commonPool 上，而是显式绑定专属线程池，再用 supplyAsync 提交、allOf 协调、join 提取结果，同时兼顾超时与失败兜底。
必须用自定义线程池，别碰 commonPool
CompletableFuture.supplyAsync(() -> doWork()) 默认走 ForkJoinPool.commonPool() —— 这是个全局共享池。一旦其他模块（比如并行流、第三方库）也在用它，就容易相互抢占、拖慢甚至卡死你的批量任务。
正确做法是自己配一个 ThreadPoolExecutor：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- IO 密集型任务：核心线程数建议设为 CPU 核数 × 2～4，队列用 LinkedBlockingQueue（容量按批次量预估，比如 1000～10000）
- CPU 密集型任务：核心线程数 ≈ CPU 核数，避免过度上下文切换
- 拒绝策略推荐 CallerRunsPolicy：任务被拒时由调用线程执行，能自然降速防雪崩
批量提交 + 统一等待 + 安全取值
allOf 不返回结果，只表示“全都完成了”。所以不能靠它拿数据，得配合原始 future 列表手动 join：
- 用 supplyAsync(Runnable, executor) 批量提交任务，每个返回 CompletableFuture
，全部 add 到 List 中 - 调用 CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])) 得到一个“完成信号” future
- 对原始 futures 列表遍历调用 join()（不是 get()，避免抛出检查异常打断流程）
- 最后用 stream().map(CompletableFuture::join).collect(Collectors.toList()) 汇总结果
按需选组合方式：独立并行 or 有依赖
如果批量任务之间完全无关，allOf 就够用；但若存在先后或配对逻辑，就得换更细粒度的 API：
- thenCombine：两个并行任务完成后合并结果，比如“查用户”+“查地址”→组装用户详情
- thenCompose：前一个结果作为参数触发下一个异步调用，比如“token → userId → 用户完整信息”，自动展平嵌套 future
- 这两个方法都有带 Executor 的重载，记得传入你的自定义线程池，否则可能悄悄切回 commonPool
加超时和降级，才算生产可用
单个任务卡住或失败，不该让整批任务挂起或中断：
- 每个 supplyAsync 后链式调用 orTimeout(5, SECONDS)，设置单任务超时
- 紧跟 exceptionally(ex -> fallbackValue)，提供默认值或空对象，保证后续汇总不报 NPE 或中断
- 如需整体超时（比如整批必须 10 秒内完成），可用 anyOf(timeoutFuture, allOfFuture).join() 做熔断
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
