面经策

主线程如何得知线程池中多个并行任务的完成并收集它们的结果？ ​

  • 标签：后端、场景题

🏛 业务架构师 ​

主线程等待线程池多个并行任务完成并收集结果，标准工具链很成熟，我按工具演进讲，重点补超时与降级——生产代码和 demo 的差距就在这里。

方案一：invokeAll（简单直接）

java
List<Future<Result>> futures = pool.invokeAll(tasks); // 阻塞至全部完成
for (Future<Result> f : futures) results.add(f.get());

方案二：CompletionService（谁完成先收谁）

java
ExecutorCompletionService<Result> ecs = new ExecutorCompletionService<>(pool);
tasks.forEach(ecs::submit);
for (int i = 0; i < n; i++) results.add(ecs.take().get());

适合"完成一个处理一个"的场景（如结果逐条写库），不憋大招。

方案三：CompletableFuture（现代主流，组合性最强）

java
List<CompletableFuture<Result>> fs = tasks.stream()
    .map(t -> CompletableFuture.supplyAsync(t::run, pool)).toList();
CompletableFuture<List<Result>> all =
    CompletableFuture.allOf(fs.toArray(new CompletableFuture[0]))
                     .thenApply(v -> fs.stream().map(CompletableFuture::join).toList());

allOf 聚合后 join 收集，支持任一完成（anyOf）、异常传播、链式编排。

生产必加的两件事（架构师差异）

  1. 超时控制：allOf(...).orTimeout(800, MILLISECONDS) 或 get(timeout)——没有超时的并行聚合，会被最慢的那个任务绑架，一个下游抖动拖垮整个接口
  2. 单任务失败降级：exceptionally 返回兜底值（默认数据/空结果），部分成功好过整体失败——聚合接口的设计哲学是"降级拼装"
java
t.supplyAsync(task, pool)
 .completeOnTimeout(DEFAULT, 500, MILLISECONDS)  // 超时给默认值
 .exceptionally(ex -> DEFAULT);                  // 异常给默认值

收尾：这道题的真实业务背景是"聚合接口"（商品页聚价格、库存、评价）。我的原则：核心数据必须成功才返回，非核心数据全部可降级——用业务分级决定哪些任务允许兜底，而不是技术上无差别 allOf。

🏗 系统架构师 ​

主线程收集并行任务结果，我按工具演进讲，重点落在 CompletableFuture 与虚拟线程时代的选择。

1. CompletableFuture.allOf（首选）

java
List<CompletableFuture<Integer>> futures = tasks.stream()
    .map(t -> CompletableFuture.supplyAsync(t::call, pool))
    .toList();

CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();
List<Integer> results = futures.stream()
    .map(CompletableFuture::join).toList();

优点：声明式编排，thenApply/thenCompose/exceptionally 支持依赖链、超时（orTimeout）、异常隔离，是现代 Java 异步的标准答案。

2. invokeAll（同步批量提交）

java
List<Future<Integer>> fs = pool.invokeAll(callables);
for (Future<Integer> f : fs) results.add(f.get(3, TimeUnit.SECONDS));

invokeAll 阻塞到全部完成，适合"提交后只等一次"的简单场景；注意设置单任务超时防卡死。

3. CountDownLatch / CyclicBarrier（老项目常见） 主线程 await()，每个任务 finally 里 countDown()。要在子任务里显式埋点，容易漏 countDown（异常路径必须 finally），新代码我不再用它收集结果，只剩"等待 N 个完成"的语义场景。CyclicBarrier 可复用，还能让子线程间互相同步（分治归并的 barrier 点）。

4. CompletionService——谁先完成谁先处理ExecutorCompletionService 的 take() 按完成顺序返回，适合"结果处理耗时、不想等最慢者"的流水线。ForkJoinPool + fork/join 递归合并则是 CPU 密集分治的选择。

5. 2026 年的简化：虚拟线程 JDK21+ 结构化并发（StructuredTaskScope）：

java
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    var a = scope.fork(() -> queryA());
    var b = scope.fork(() -> queryB());
    scope.join().throwIfFailed();
    return new Result(a.get(), b.get());
}

代码形态回到"看似同步"，失败自动取消兄弟任务，这是我现在写并行聚合的首选。要点：无论哪种方式，每个 Future 的 get 必须带超时，防止一个慢任务拖死主线程。

💻 全栈开发专家 ​

这题我按场景选方案，核心是别自己写 wait/notify，用 JUC 现成的编排工具。

方案一：invokeAll + Future（任务集合固定，一次性等齐）

java
List<Callable<Result>> tasks = List.of(this::queryUser, this::queryOrder, this::queryStock);
List<Future<Result>> futures = executor.invokeAll(tasks); // 阻塞至全部完成
List<Result> all = futures.stream().map(f -> {
    try { return f.get(); } catch (Exception e) { throw new RuntimeException(e); }
}).toList();

方案二：CompletableFuture（异步编排，主流）

java
CompletableFuture.allOf(f1, f2, f3)
    .thenApply(v -> List.of(f1.join(), f2.join(), f3.join()));

allOf 等全部完成、anyOf 取最快，还能 orTimeout(3, SECONDS) 加超时，2026 年的业务代码我基本都用这套。

方案三：CompletionService（完成一个处理一个）

ExecutorCompletionService.take() 返回最先完成的 Future，适合结果逐个落库的场景，慢任务不拖住快结果的消费。

方案四：虚拟线程 + 结构化并发

JDK 21+ 虚拟线程让"一任务一线程"重新成立：Executors.newVirtualThreadPerTaskExecutor() 配 invokeAll，上万并行任务也无压力；再进一步用 StructuredTaskScope（JDK 25 转正）的 fail-fast 语义，任一子任务失败整体短路，父线程统一收集，生命周期不泄漏。

生产上的坑

  • Future.get() 必须带超时，防止一个卡死拖住主线程。
  • 单任务失败别让整批报废：exceptionally 兜底默认值，或收集后统一补偿。
  • 用 SkyWalking 把子任务 trace 串到主链路，否则排查"哪个子任务慢"全靠猜。