本文介绍在 spring rest 场景下，针对一个父请求包含 10–50 个动态子请求的场景，通过线程安全的并行 http 调用（如 `completablefuture` 或并发集合）显著提升响应性能，并解决 `parallelstream()` 中无法修改非 final 变量的核心问题。
在 Spring Boot REST API 开发中，常见一种“聚合型”请求模式：客户端提交一个父请求（Parent Request），其中携带多个子请求（Child Requests，数量通常为 10–50）。服务端需对每个子请求调用外部第三方 API，收集所有子响应（Child Responses），再组装成统一的父响应返回。若采用串行调用（for-loop + RestTemplate/WebClient），总耗时 ≈ Σ 单次调用延迟（含网络 RTT），极易导致接口超时或体验卡顿。
直接使用 parallelStream().forEach(...) 是常见误区——它虽能并发发起请求，但因 Java Lambda 要求捕获变量为 effectively final，无法直接向普通 List 或 Map 写入结果，导致编译错误或竞态异常。
✅ 推荐方案：使用线程安全容器 + 显式并发控制（优于 parallelStream）
✅ 方案一：基于 ConcurrentHashMap（推荐，适用于无序/按 ID 查找场景）
// 假设 ChildRequest 有唯一 String ID（如 "order-123", "item-456"）
final Map<String, ChildResponse> responseMap = new ConcurrentHashMap<>();
List<ChildRequest> childRequests = ...; // 来自父请求
// 并发调用所有子请求
childRequests.parallelStream()
.forEach(request -> {
try {
ChildResponse resp = webClient.get()
.uri("https://api.example.com/child/{id}", request.getId())
.retrieve()
.bodyToMono(ChildResponse.class)
.block(); // 生产环境建议用 .toFuture() + CompletableFuture.allOf()
responseMap.put(request.getId(), resp);
} catch (Exception e) {
log.error("Failed to call child API for id: {}", request.getId(), e);
responseMap.put(request.getId(), ChildResponse.error(request.getId(), e.getMessage()));
}
});
// 组装父响应（按原始 childRequests 顺序保持一致性）
List<ChildResponse> orderedResponses = childRequests.stream()
.map(req -> responseMap.getOrDefault(req.getId(), null))
.collect(Collectors.toList());
return ParentResponse.builder()
.childResponses(orderedResponses)
.build();⚠️ 注意：parallelStream() 默认使用 ForkJoinPool.commonPool()，在 Web 应用中可能与 Tomcat 线程池争抢资源。生产环境更推荐 显式管理线程池：
ExecutorService executor = Executors.newFixedThreadPool(20); // 根据 QPS & 外部 API SLA 调整
List<CompletableFuture<ChildResponse>> futures = childRequests.stream()
.map(req -> CompletableFuture.supplyAsync(() -> callExternalApi(req), executor))
.collect(Collectors.toList());
// 等待全部完成（带超时保护）
CompletableFuture.allOf(futures.toArray(new CompletableFuture[0]))
.orTimeout(5, TimeUnit.SECONDS)
.join();
List<ChildResponse> results = futures.stream()
.map(CompletableFuture::join)
.collect(Collectors.toList());✅ 方案二：基于 CopyOnWriteArrayList + 索引映射（适用于 ID 为连续整数）
若 ChildRequest.getId() 返回 int 且范围已知（如 0–49），可预分配列表并用索引定位：
final List<ChildResponse> responses = new CopyOnWriteArrayList<>(Collections.nCopies(childRequests.size(), null));
childRequests.parallelStream().forEach(request -> {
int index = request.getId(); // 确保 index < childRequests.size()
ChildResponse resp = callExternalApi(request);
responses.set(index, resp); // 线程安全的 set 操作
});? 关键总结
- ❌ 避免 parallelStream().forEach() 直接操作普通 ArrayList/HashMap —— 不安全且违反 final 规则；
- ✅ 优先选用 ConcurrentHashMap（ID 为字符串）或 CopyOnWriteArrayList（ID 为有序整数）；
- ✅ 生产环境务必使用 自定义 ExecutorService 替代 commonPool，防止线程饥饿；
- ✅ 强烈建议用 WebClient + CompletableFuture 替代阻塞式 RestTemplate，实现真正异步非阻塞；
- ✅ 必须添加超时、重试、降级逻辑（如 resilience4j），避免单个子请求拖垮整个聚合链路。
通过上述改造，原本 3–5 秒的串行聚合接口，通常可优化至 300–800ms（取决于外部 API 并发能力），同时保障线程安全与响应顺序一致性。
