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：

• IO 密集型任务：核心线程数建议设为 CPU 核数 × 2～4，队列用 LinkedBlockingQueue（容量按批次量预估，比如 1000～10000）
• CPU 密集型任务：核心线程数 ≈ CPU 核数，避免过度上下文切换
• 拒绝策略推荐 CallerRunsPolicy：任务被拒时由调用线程执行，能自然降速防雪崩

批量提交 + 统一等待 + 安全取值

allOf 不返回结果，只表示“全都完成了”。所以不能靠它拿数据，得配合原始 future 列表手动 join：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

立即学习“Java免费学习笔记（深入）”；

• 用 supplyAsync(Runnable, executor) 批量提交任务，每个返回 CompletableFuture<T>，全部 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() 做熔断