CompletableFuture.supplyAsync需手动添加降级逻辑，常用exceptionally或handle捕获异常并返回备用结果，避免使用thenApply；配合orTimeout实现超时控制，结合熔断开关防止雪崩；allOf前须对各future单独降级；I/O操作必须使用自定义线程池。
CompletableFuture.supplyAsync 里怎么塞降级逻辑
降级不是等超时再补救，而是在主逻辑启动的同时，就准备好“备胎”。supplyAsync 本身不支持自动 fallback，得靠 handle 或 exceptionally 拦住异常后手动接管。
常见错误是只用 thenApply——它根本不处理异常，一旦上游抛 ExecutionException，整个链就断了，降级根本没机会触发。
-
exceptionally只捕获Throwable，适合简单兜底（比如返回空对象或默认值） -
handle同时接收结果和异常，适合需要根据异常类型做不同处理的场景（如对TimeoutException返回缓存，对IOException返回兜底文案） - 别在
exceptionally里再调远程服务——这会把降级变成新瓶颈；优先用本地计算、静态配置或本地缓存
示例：
CompletableFuture.supplyAsync(() -> callRemoteService())<br> .exceptionally(t -> {<br> log.warn("remote call failed, use fallback", t);<br> return new User("guest", 0); // 本地构造<br> });
用 orTimeout + exceptionally 实现简易熔断
orTimeout 是 JDK 9+ 加入的硬超时控制，它会在指定时间后主动中断任务并抛 TimeoutException，比靠线程池拒绝或手动计时更可靠。
但注意：orTimeout 不会终止正在运行的异步任务（比如一个卡死的 HTTP 请求），只是让 CompletableFuture 自身失败。真正要“熔断”，得配合状态标记 + 短路逻辑。
- 超时后必须走
exceptionally，否则orTimeout的效果等于没开 - 单纯靠
orTimeout不能阻止下一次调用——它不记录失败次数，也不阻断后续请求 - 简易熔断至少要加一层开关：用
AtomicBoolean或AtomicInteger统计连续失败，达到阈值后直接 short-circuit 返回 fallback，跳过supplyAsync
示例（带开关）：
if (circuitBreakerOpen.get()) {<br> return CompletableFuture.completedFuture(fallbackUser());<br>}<br>return CompletableFuture.supplyAsync(() -> callRemoteService())<br> .orTimeout(800, TimeUnit.MILLISECONDS)<br> .exceptionally(t -> {<br> failCount.incrementAndGet();<br> if (failCount.get() >= 3) circuitBreakerOpen.set(true);<br> return fallbackUser();<br> });
CompletableFuture.allOf 怎么安全降级
allOf 本身不聚合结果，且只要任意一个子 future 失败，它就失败——这对降级很不友好。你没法知道是哪个挂了，更没法按需 fallback。
真实场景中，多个并行依赖（比如查用户 + 查订单 + 查配置）应该各自独立降级，而不是“一损俱损”。
- 别用
allOf直接组合原始 future；先对每个 future 单独加exceptionally，确保每个都返回非 null 结果 - 用
CompletableFuture.allOf+thenApply拿结果时，所有 future 必须是“已完成”状态（即已走完自己的 fallback） - 如果某个依赖完全不可用（比如配置中心宕机），它的 fallback 应该是轻量级的（如读 classpath 下默认配置），而非重试或阻塞等待
示例：
CompletableFuture<User> userF = fetchUser().exceptionally(t -> guestUser());<br>CompletableFuture<Order> orderF = fetchOrder().exceptionally(t -> emptyOrder());<br>CompletableFuture<Config> configF = fetchConfig().exceptionally(t -> defaultConfig());<br><br>CompletableFuture.allOf(userF, orderF, configF)<br> .thenApply(v -> buildDashboard(userF.join(), orderF.join(), configF.join()));
线程池选错会让降级和熔断失效
用 ForkJoinPool.commonPool()（默认）跑 I/O 密集型调用，极易导致线程饥饿：一个慢请求占着线程不放，后续所有 future 都排队，降级逻辑被堵死，熔断阈值也迟迟达不到。
这不是代码写得不对，而是执行环境没配对。
- 对外 HTTP 调用、数据库查询这类 I/O 操作，必须用自定义线程池，且核心线程数建议设为 10~50（视 QPS 和平均 RT 调整）
- 线程池拒绝策略别用
AbortPolicy——它直接抛异常，绕过所有 fallback；改用CallerRunsPolicy，让调用方自己执行，至少能进exceptionally - 别共享同一个线程池给“主调用”和“降级逻辑”——万一降级也要发请求（比如查本地缓存 Redis），它们会互相抢占资源
示例线程池声明：
private static final ExecutorService IO_POOL =<br> new ThreadPoolExecutor(<br> 20, 100,<br> 60L, TimeUnit.SECONDS,<br> new LinkedBlockingQueue<>(1000),<br> r -> new Thread(r, "io-pool-" + r.hashCode()),<br> new ThreadPoolExecutor.CallerRunsPolicy());
真正难的不是写几个 exceptionally，而是想清楚：哪条路径必须强一致，哪条可以弱一致；哪些异常值得重试，哪些该立刻降级；超时时间设成 800ms 是因为 P99 响应是 750ms，还是拍脑袋？这些决策不会出现在代码里，但会决定 fallback 到底是救命稻草，还是另一根绞索。
