电商商品详情页应使用CompletableFuture.supplyAsync配合自定义线程池并行调用各服务，通过allOf等待完成后再join获取结果，统一用exceptionally降级，配置合理线程池与超时避免阻塞和雪崩。
电商系统中常见的“商品详情页”需要同时查商品信息、库存、价格、促销、评价、物流等服务，用 CompletableFuture 并行调用多个远程接口，能显著降低总耗时，避免串行阻塞。
用 supplyAsync 启动并行异步任务
每个服务调用应封装为独立的异步任务，推荐使用 supplyAsync（支持自定义线程池），避免阻塞默认 ForkJoinPool。不要直接在 lambda 里写业务逻辑，而是抽成清晰的方法：
- 商品服务：返回
Product对象 - 库存服务：返回
StockInfo - 价格服务：返回
PriceInfo - 促销服务：返回
PromotionList
示例：
ExecutorService customPool = Executors.newFixedThreadPool(10);CompletableFuture<Product> productF = CompletableFuture.supplyAsync(() -> productService.get(id), customPool);
CompletableFuture<StockInfo> stockF = CompletableFuture.supplyAsync(() -> stockService.getBySku(id), customPool);
// 其他类似...
用 allOf 汇总所有任务并统一处理结果
CompletableFuture.allOf() 等待全部完成，但它返回 CompletableFuture<Void>，不携带结果。需配合 join() 或 get() 主动取值 —— 注意：必须在每个 future 后显式调用 join()，否则结果丢失：
立即学习“Java免费学习笔记（深入）”；
- 先用
allOf(f1, f2, f3, f4)触发并发等待 - 再用
f1.join()、f2.join()分别获取结果（不会阻塞，因 allOf 已确保完成） - 最后组装聚合对象，如
ProductDetail
错误写法：allOf(...).join() 后直接访问未 join 的 future —— 结果可能为 null 或抛异常。
统一异常处理与降级策略
任一服务失败不应导致整个详情页崩溃。用 exceptionally() 或 handle() 做兜底：
- 库存查询失败 → 返回 “库存未知”，不影响商品展示
- 促销服务超时 → 返回空促销列表，前端静默降级
- 关键服务（如商品主数据）失败才整体失败，可用
thenCompose链式校验
建议对非核心字段设置默认值或空对象，避免 NPE；日志记录异常但不中断流程。
合理配置线程池与超时控制
不要共用 ForkJoinPool.commonPool()，尤其在 Web 容器中易被其他任务挤占资源。为 CompletableFuture 单独配线程池：
- 核心线程数 ≈ 远程服务数量 × 期望并发度（如 4 个服务 × 2 = 8）
- 最大线程数设上限（如 20），防止雪崩
- 搭配
orTimeout(2, TimeUnit.SECONDS)防止单个慢请求拖垮整体 - 超时后走
exceptionally降级，而非让线程一直等
不复杂但容易忽略：线程池拒绝策略建议用 CallerRunsPolicy，让调用方自己执行，避免丢任务。
