关键在于控资源、分批次、不堆积：需用有界队列自定义线程池替代commonpool，io型设2×cpu核数，批量提交后统一allof.join，再集中join取结果，并加限流、超时、信号量及关闭清理。
关键不是“少创建”，而是“控资源、分批次、不堆积”。直接在循环里无节制调用 supplyAsync 或 runAsync，尤其配合默认线程池或无界队列，极易触发内存溢出（OOM）——任务对象、回调链、未完成的 CompletableFuture 实例持续堆积，GC 来不及回收。
用自定义线程池替代 ForkJoinPool.commonPool()
默认线程池（ForkJoinPool.commonPool()）并行度低（CPU核数−1），且被全应用共享。IO型任务一多，线程长期阻塞，后续任务排队进无界队列，内存暴涨。
- 显式传入独立线程池，例如：
ExecutorService ioPool = new ThreadPoolExecutor(10, 50, 60L, TimeUnit.SECONDS,new LinkedBlockingQueue(1000), // 有界队列防爆r -> new Thread(r, "io-task-")); - 避免
Executors.newCachedThreadPool()：它用SynchronousQueue+ 无限扩容线程，高并发下瞬间创建成百上千线程，直接 OOM。 - 线程数设置参考：IO 密集型建议设为
2 × CPU 核数起步；CPU 密集型保持核数 ± 1即可。
批量提交 + 统一等待，禁止在 Stream 中 join
常见错误是在流式处理中边提交边 join()，导致逻辑串行化，且每个 join() 都可能阻塞主线程、拖慢整体节奏，间接加剧任务堆积。
- 正确做法：先全部提交，收集所有
CompletableFuture实例到列表，再统一等待：
.map(item -> CompletableFuture.supplyAsync(() -> process(item), ioPool))
.collect(Collectors.toList());
// 批量等待完成
CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();
// 再集中获取结果（注意 join() 不抛 checked exception）
List
加限流与熔断，主动控制任务速率
当数据量极大（如百万级列表），即使线程池合理，一次性提交也会压垮下游或耗尽内存。需引入速率控制。
- 按批次提交：例如每 100 个元素一组，组间加小延时或信号量控制；
- 用
orTimeout()防止单任务长期挂起：CompletableFuture.supplyAsync(() -> db.query(id), pool)<br> .orTimeout(3, TimeUnit.SECONDS)<br> .exceptionally(ex -> fallbackValue);
- 结合
Semaphore限制并发执行数（非提交数），比如只允许最多 20 个任务真正运行中。
及时清理与关闭资源
长时间运行的服务若不释放线程池，会持续持有线程和队列引用，阻碍 GC，累积内存压力。
- 应用关闭前务必调用
ioPool.shutdown()，必要时加shutdownNow()强制中断； - 避免匿名内部类或 Lambda 持有外部大对象引用（如整个 service 实例、大数据集合），防止
CompletableFuture实例无法被回收。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
