ortimeout仅标记超时失败，不终止底层任务；需配合exceptionally捕获异常、atomicboolean开关及atomicinteger计数实现简易熔断，且http客户端必须配置超时以确保资源及时释放。
orTimeout 本身不熔断，只标记超时失败
orTimeout 的作用非常明确：在指定时间未完成时，主动用 TimeoutException 异常完成当前 CompletableFuture。但它**不会中断底层线程或取消正在运行的异步任务**——比如一个卡在 HttpClient 阻塞读取上的请求，orTimeout 触发后，那个 HTTP 连接仍在后台挂着，资源没释放。
这意味着：只写 .orTimeout(1, TimeUnit.SECONDS) 是无效的“假熔断”。你得靠 exceptionally 捕获这个异常，并配合外部状态控制后续行为。
- 必须链式跟上
exceptionally，否则超时信号被吞掉，下游拿不到 fallback 值 - 底层任务（如 HTTP 请求）是否真正终止，取决于客户端自身是否支持 cancel 或超时配置（例如
OkHttp的call.cancel()、HttpClient的timeout参数） -
orTimeout是 JDK 9+ 特性，JDK 8 项目需自行封装或升级
如何用 AtomicBoolean + orTimeout 实现简易熔断开关
真实服务熔断不是“一次超时就拉闸”，而是基于失败率/连续失败次数做状态切换。最轻量的做法是用 AtomicBoolean 标记开关，再用 AtomicInteger 统计失败次数：
private final AtomicBoolean circuitBreakerOpen = new AtomicBoolean(false);
private final AtomicInteger failCount = new AtomicInteger(0);
public CompletableFuture<user> fetchUser(long userId) {
if (circuitBreakerOpen.get()) {
return CompletableFuture.completedFuture(fallbackUser());
}
return CompletableFuture.supplyAsync(() -> callRemoteService(userId))
.orTimeout(800, TimeUnit.MILLISECONDS)
.exceptionally(t -> {
failCount.incrementAndGet();
if (failCount.get() >= 3) {
circuitBreakerOpen.set(true);
// 可选：启动定时器恢复（半开状态逻辑略）
}
return fallbackUser();
});
}</user>
- 开关检查必须放在
supplyAsync之前，否则每次都会触发远程调用 -
failCount和circuitBreakerOpen需要线程安全，不能用普通变量或synchronized包裹整个方法（会串行化） - 这里没实现自动恢复逻辑；生产中建议加个定时任务，在休眠几秒后重置
failCount并尝试compareAndSet(true, false)
allOf 场景下 orTimeout 怎么安全降级
当多个异步调用并行执行（如 CompletableFuture.allOf(a, b, c)），其中一个超时会导致整个 allOf 失败——但你往往希望“尽力而为”，允许部分失败。
正确做法不是对 allOf 本身调用 orTimeout，而是对每个子 CompletableFuture 单独加 orTimeout + exceptionally，确保每个都返回兜底值：
CompletableFuture<string> a = CompletableFuture.supplyAsync(() -> fetchA())
.orTimeout(500, TimeUnit.MILLISECONDS)
.exceptionally(t -> "fallback-a");
CompletableFuture<string> b = CompletableFuture.supplyAsync(() -> fetchB())
.orTimeout(500, TimeUnit.MILLISECONDS)
.exceptionally(t -> "fallback-b");
CompletableFuture<string> c = CompletableFuture.supplyAsync(() -> fetchC())
.orTimeout(500, TimeUnit.MILLISECONDS)
.exceptionally(t -> "fallback-c");
CompletableFuture<void> all = CompletableFuture.allOf(a, b, c);
// 注意：allOf 不聚合结果，需手动 join 各个 future
CompletableFuture<list>> result = all.thenApply(v -> Arrays.asList(
a.join(), b.join(), c.join()
));</list></void></string></string></string>
-
allOf返回的是CompletableFuture<void></void>，它只等全部完成，不关心成功与否；所以必须先让每个子 future 自己处理超时和 fallback - 如果某个子 future 在
exceptionally中返回了null，join()会抛NullPointerException；务必保证 fallback 值非 null - 别在
thenApply里直接调a.get()——这会阻塞当前线程，破坏异步性
HTTP 客户端必须配超时，orTimeout 才不白费
orTimeout 能让 CompletableFuture 快速失败，但若底层 HTTP 请求没设超时，连接可能卡住几十秒，线程/连接池资源持续被占，orTimeout 就只是“提前通知失败”，而非“及时止损”。
- 用
OkHttp：构造OkHttpClient时设置connectTimeout、readTimeout、writeTimeout - 用
HttpClient（JDK 11+）：用HttpRequest.newBuilder().timeout(Duration.ofSeconds(3)) - 用
RestTemplate（Spring）：需配SimpleClientHttpRequestFactory并设connectTimeout和readTimeout - 虚拟线程场景下，更要配超时——否则一个卡死请求会拖垮整批虚拟线程
真正可靠的超时控制，永远是“客户端超时 + orTimeout + 熔断开关”三层组合。漏掉任何一层，都可能在高并发下引发雪崩。
