CompletableFuture.allOf 返回 null 因其只等待完成而不聚合结果；需用 List 存储各任务，allOf 等待后遍历调用 join() 或 get() 获取结果。

CompletableFuture.allOf 为什么拿不到返回值

因为 allOf 只关心“全部完成”，返回的是 CompletableFuture<void></void>，不聚合结果。你得自己把每个任务的 CompletableFuture 存起来，再用 join() 或 get() 拿结果。

• 常见错误：写完 CompletableFuture.allOf(f1, f2, f3) 就直接 .join()，发现返回 null
• 正确做法：先用 List<completablefuture>></completablefuture> 收集所有任务，再用 allOf 等待完成，最后遍历调用 .join()
• 注意 join() 会阻塞当前线程（如果在主线程调用），但不会抛受检异常；get() 会抛 ExecutionException

多个RPC调用并发时如何统一处理超时和异常

别依赖单个 CompletableFuture 的 orTimeout 后再 exceptionally —— 它只覆盖本任务，无法控制整个批次的超时边界。

• 推荐用 CompletableFuture.anyOf + 计时器兜底：启动一个带延迟的 CompletableFuture，到期后主动 completeExceptionally，再和所有 RPC 任务一起 anyOf，谁先完成谁胜出
• 更稳妥的做法是用 CompletableFuture.supplyAsync(..., executor) 配合自定义线程池，并设置 awaitTermination 控制总耗时
• RPC 异常（如 DubboTimeoutException、FeignException）默认不会被 exceptionally 捕获，除非你显式用 handle 或在 thenApply 外层包 try-catch

结果汇总时 map/flatMap/thenCombine 怎么选

关键看数据流阶段：是“单个结果加工”、“两个结果合并”，还是“多个异步结果串行组装”。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• map：对单个已完成的 CompletableFuture<t></t> 结果做同步转换，比如 future.map(s -> s.toUpperCase())
• thenCombine：等两个独立的 CompletableFuture 都完成，再用 BiFunction 合并，适合 A+B → C 场景
• thenCompose：当前任务返回的是另一个 CompletableFuture，避免嵌套 CompletableFuture<completablefuture>></completablefuture>，比如查用户后再查其订单
• 多个结果汇总（>2个）别硬套 thenCombine 链，改用 allOf + 列表收集 + 流式处理更清晰

线程池没配好，CompletableFuture反而变慢

默认用 ForkJoinPool.commonPool()，但它的并行度 = CPU 核数 - 1，对 IO 密集型 RPC 调用严重不够，大量任务排队等待线程。

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

• 必须传自定义线程池：比如 Executors.newFixedThreadPool(20)，大小按预期并发量 × 平均 RPC 耗时 / 期望响应时间估算
• 别用 newCachedThreadPool：它无限创建线程，高并发下可能 OOM 或触发系统级线程限制
• 注意线程池未关闭会导致应用停不掉；建议配合 Spring 的 @PreDestroy 或手动 shutdown()
• 日志里看到大量 ForkJoinPool.commonPool-worker-* 在跑 RPC，基本就是没指定 executor

实际写的时候最容易漏掉的是：每个 RPC 调用的异常是否真的进了统一 fallback，以及线程池拒绝策略是否静默吞掉任务。这两点一出问题，表面看着跑通，其实部分请求根本没发出去。