Java CompletableFuture 怎么收集多个任务的成功和失败结果

做聚合接口时，常见场景是同时查库存、价格和推荐。真正麻烦的不是并行启动，而是其中一个服务失败后，怎样仍然拿到其他任务的成功结果。实用做法是：先用 handle 把每个 CompletableFuture 归一化为“成功值或失败原因”，再用 CompletableFuture.allOf 等待全部完成，最后按原列表顺序读取。

不要把 allOf 当成结果容器：它只负责等待。要保留部分成功，异常必须在每个子任务边界被转换成数据。

背景：CompletableFuture.allOf为什么拿不到结果

allOf 的返回类型是 CompletableFuture。它会等所有输入完成；如果任意输入异常，聚合 future 也会异常完成。即使全部成功，各输入的结果也不会自动塞进这个 Void 里，仍要回到每个 future 单独读取。

旧写法的问题：一个异常让汇总链断掉

下面这种写法很直观，却把“等待全部完成”和“读取所有结果”绑在了一起：

CompletableFuture.allOf(tasks.toArray(CompletableFuture[]::new))
    .thenApply(v -> tasks.stream().map(CompletableFuture::join).toList())
    .join();

只要有一个任务异常，allOf 就异常完成，后面的列表转换不会按“部分成功”语义运行。即使改成逐个 join，第一个遇到异常的元素也会中断收集，其他已完成的值没有机会被整理出来。

新规则：先把每个Future变成统一结果

先定义一个只描述业务结果的数据结构。value 和 error 二选一，taskName 用来让上层知道是哪项失败。

record TaskResult(String taskName, T value, Throwable error) {
    static  TaskResult success(String name, T value) {
        return new TaskResult(name, value, null);
    }

    static  TaskResult failure(String name, Throwable error) {
        return new TaskResult(name, null, error);
    }

    boolean isSuccess() {
        return error == null;
    }
}

然后在每个 future 的边界调用 handle。它无论上游正常还是异常，都会给下游一个 TaskResult，这样聚合屏障看到的是一组正常完成的结果对象。

代码对比：收集成功和失败结果

static  CompletableFuture> safe(
        String name, Supplier work, Executor executor) {
    return CompletableFuture.supplyAsync(work, executor)
        .handle((value, error) -> error == null
            ? TaskResult.success(name, value)
            : TaskResult.failure(name, unwrap(error)));
}

List>> tasks = List.of(
    safe("库存", inventory::query, ioExecutor),
    safe("价格", pricing::query, ioExecutor),
    safe("推荐", recommendation::query, ioExecutor)
);

CompletableFuture barrier = CompletableFuture.allOf(
    tasks.toArray(CompletableFuture[]::new));

List> results = barrier.thenApply(ignored ->
    tasks.stream().map(CompletableFuture::join).toList()
).join();

这里的顺序由 tasks 列表决定，不由任务完成先后决定。handle 已经把异常转成正常结果，所以 barrier 能等齐三项；屏障完成后再 join，只是在读取已经完成的 TaskResult，不会重新执行任务。

unwrap 可以沿着 CompletionException 或 ExecutionException 取出业务真正关心的 cause；如果项目希望保留完整调用链，也可以直接保存原始 Throwable。

兼容注意：join、get和线程池怎么选

join 抛出 unchecked 的 CompletionException，适合已经确定 future 成功或已被 handle 归一化的内部读取；get 会抛受检的 ExecutionException，还可能被中断或超时。两者都不是失败收集策略，失败收集应放在子 future 上。

supplyAsync 不传执行器时使用默认异步执行器。网络、文件等阻塞任务建议传入专用的 ioExecutor，避免和 CPU 型异步任务共享不合适的线程资源。线程池大小应结合下游并发限制设置，不能用“异步”掩盖无限制放大请求。

采用建议：把失败当数据交给业务层

如果页面允许“库存成功、推荐失败”，就把 results 分成成功项和失败项，并记录任务名与原因；如果任一失败都意味着订单不可用，则仍可在业务层检查失败项后主动抛出统一异常。关键是让策略出现在消费结果的位置，而不是被 allOf 的默认异常传播悄悄决定。

最后记住三件事：allOf 是屏障，不是列表；handle 是每项的结果归一化边界；join 只是读取方式。这样既能保留多个任务的成功和失败，也能让并发结构保持清晰。

相关问题

为什么不直接用 exceptionally？ exceptionally 只在异常时提供替代值；需要同时保留成功值、失败原因和任务名时，handle 更直接。

allOf 能保证结果顺序吗？ 不能。结果顺序来自你保存 futures 的集合；示例用 List 收集，因此按提交列表顺序读取。

资料依据：Oracle Java SE 21 CompletableFuture API。