CompletableFuture.anyOf返回CompletableFuture，因Java泛型擦除无法推断多泛型统一上界；其完成不区分成功或异常，异常作为Object值返回，需用handle检查ex!=null或result instanceof Throwable来安全处理。
anyOf 不是“取最快成功结果”的银弹，它连成功失败都不区分——直接用会把异常当正常值返回。
anyOf 返回的 CompletableFuture
Java 泛型擦除导致 CompletableFuture.anyOf 无法推断多个不同泛型参数（比如 CompletableFuture 和 CompletableFuture）的统一上界，只能退化为 CompletableFuture。哪怕你传的全是 String，返回值类型仍是 Object。
常见错误现象：
- 调用
anyOf(f1, f2).join()后直接强转成String，运行时抛ClassCastException - 没意识到返回的
Object可能是Throwable实例（某个子任务失败了，但 anyOf 把它当“结果”返回） - 误以为
exceptionally()能捕获它——不会，因为这个 future 是「正常完成」的
如何安全提取第一个成功结果（跳过所有失败）
业务目标是“多机竞速查缓存，只要一个成功就立刻返回”，但 anyOf 本身不筛异常。必须手动判断结果是否有效。
推荐写法（使用 handle）：
CompletableFuture<string> cacheA = queryCache("host-a");
CompletableFuture<string> cacheB = queryCache("host-b");
CompletableFuture<string> cacheC = queryCache("host-c");
CompletableFuture<string> fastestOk = CompletableFuture.anyOf(
cacheA, cacheB, cacheC
).handle((result, ex) -> {
if (ex != null) {
// anyOf 自身 completion 异常（极少见，比如参数 null）
return null;
}
if (result instanceof String) {
// 成功结果
return (String) result;
}
if (result instanceof Throwable) {
// 某个子 Future 失败了，Throwable 被当 result 返回
return null;
}
return null;
}).thenCompose(s -> s != null ? CompletableFuture.completedFuture(s) : CompletableFuture.failedFuture(new RuntimeException("All caches failed")));
// 最终用 fastestOk.join() 或异步链式消费</string></string></string></string>
关键点：
- 必须用
handle，不是thenApply——因为要同时处理ex和result - 先判
ex != null（anyOf自身构造失败），再判result instanceof Throwable（子任务失败） - 返回
null表示当前结果不可用，后续用thenCompose转成失败 future，避免空指针
allOf 等待全部完成时，异常会被静默吞掉
如果你误把 anyOf 场景换成 allOf（比如想等所有缓存节点都返回再选最优），要注意：allOf 的 join() 抛出的是 CompletionException，原始异常堆栈被丢弃；而且只要有一个失败，你就拿不到其他成功的值。
正确做法：
- 用
allOf(f1, f2, f3).join()确保全部完成 - 再分别对每个原始
CompletableFuture调用join()或get()，自己捕获并处理各自异常 - 别依赖
allOf的返回值做任何逻辑判断——它永远是CompletableFuture
为什么 applyToEither 比 anyOf 更适合双节点竞速
如果只查两个缓存节点（比如主备），applyToEither 是更干净的选择：
cachePrimary.applyToEither(cacheBackup, s -> "hit: " + s)
优势：
- 类型保留：
applyToEither的返回类型由第一个参数决定，不会退化成Object - 自动跳过失败：只有成功完成的 future 才触发函数；若两者都失败，返回的 future 会以第一个失败的异常完成
- 语义清晰：明确表达“任一成功即用”，不用手动筛
Throwable
anyOf 的复杂性主要来自它必须兼容任意数量、任意类型的 future，而实际缓存场景中，你往往知道类型且数量可控——这时候硬套 anyOf 反而增加出错概率。
