CountDownLatch 不适用于微服务并行调用，仅适用于单 JVM 线程协调；跨服务场景应使用 CompletableFuture + WebClient/OkHttp 异步 HTTP 并发控制，并注意连接池、traceId 透传和非阻塞超时。
CountDownLatch 在微服务聚合中不能直接用于跨服务的 RPC 并行调用结果汇总。它只适用于单 JVM 内的线程协调，对远程服务的响应、超时、重试、网络中断等完全不可感知——服务 A 创建的 CountDownLatch，服务 B/C/D 根本看不见，更不会主动调用 countDown()。
为什么 CountDownLatch 不适合微服务并行调用
微服务间是进程隔离、网络通信的，不存在共享内存或统一调度上下文：
- CountDownLatch 的 await() 阻塞的是本地线程，无法等待 HTTP 响应或 Dubbo/Feign 远程调用完成
- 若某 RPC 调用失败、超时或重试，对应线程可能 never countDown()，导致 await() 永久挂起
- 分布式链路中 traceId、上下文（如 SecurityContext）无法自动透传到远程服务，手动传递易出错
- 没有内置熔断、降级、超时兜底机制，不符合生产级稳定性要求
真正该用的方案：CompletableFuture + 异步 HTTP/RPC 客户端
目标是“并发发起多个远程请求 → 等待全部/部分完成 → 汇总结果”，这本质是异步 I/O 协调，不是线程同步问题：
- 用 WebClient（WebFlux）：天然响应式，推荐 Mono.zip() 或 Flux.zip() 并发聚合，自动管理背压和取消
- 用 OkHttpClient + CompletableFuture：每个 Call.enqueue() 回调中调用 completableFuture.complete() 或 .completeExceptionally()
- 用 Feign + CompletableFuture：需启用异步支持（如 feign-reactive），或封装为 supplyAsync
- 务必为每个请求设置独立超时（如 call.timeout(5, TimeUnit.SECONDS)），避免 allOf().join() 卡死
如何正确汇总多个 RPC 结果
CompletableFuture.allOf() 只等待完成，不返回结果——这是最常见误用点：
- 先用 List
> 存储所有任务（例如查用户、查订单、查地址） - 用 CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])) 等待全部完成
- 再遍历 futures 列表，逐个调用 .join() 获取实际返回值（注意 join() 抛运行时异常，get() 抛受检异常）
- 若需“任意 N 个成功即返回”，不要硬套 CountDownLatch，改用 Resilience4j 的 Bulkhead + TimeLimiter + 自定义聚合逻辑
关键细节不能漏
忽略这些，再好的异步结构也会在线上翻车：
- 线程池必须自定义：默认 ForkJoinPool.commonPool() 并行度太低（CPU 核数 −1），IO 密集型调用要用 FixedThreadPool（如 20~50 核心）
- 异常必须显式处理：RPC 异常（FeignException、DubboTimeoutException）不会被 exceptionally() 自动捕获，要用 handle() 或外层 try-catch 包裹 join()
- 连接池要调优：OkHttp/WebClient 必须配置最大连接数、空闲连接存活时间、DNS 缓存等，否则高并发下打满连接池
- traceId 和 MDC 需手动透传：在 supplyAsync 的 Runnable 中复制当前线程的 MDC，或使用 reactor-context 传递 WebFlux 上下文
