acceptEither不能用于微服务调用，因其同步执行且回调不注册监听，若两任务均未完成则返回未触发回调的空壳对象；必须改用acceptEitherAsync并配IO专用自定义线程池，否则会卡死或丢失上下文。
直接结论：用 acceptEither 做抢占式响应是错的，它不适用于微服务多副本调用场景；必须改用 acceptEitherAsync 并配自定义线程池，否则会卡死或返回错误结果。
为什么 acceptEither 不能用于微服务调用
这个方法名带 “Either”，容易让人误以为“任一完成就触发”，但它实际行为是：同步执行回调函数，且只在当前线程中运行。也就是说，它不会主动等待两个 CompletableFuture 中任意一个完成，而是等调用时“碰巧”有一个已结束——如果都未完成，它立刻返回一个新 CompletableFuture，但该实例处于未完成状态，后续也不会自动触发回调。
微服务调用本质是异步 IO 操作（HTTP 请求、RPC），耗时长、不可控。你无法保证 acceptEither 被调用时已有任一任务完成，所以它大概率返回一个永远不触发回调的空壳对象。
- 现象：主线程调用
acceptEither后立即往下走，回调函数从不执行 - 原因：两个 HTTP 请求都还在网络等待中，
acceptEither不监听完成事件，也不注册监听器 - 对比：真正监听并响应完成事件的是带
Async后缀的方法，比如acceptEitherAsync
acceptEitherAsync 必须传自定义线程池
默认使用 ForkJoinPool.commonPool()，而这个线程池是为 CPU 密集型任务设计的，核心线程数 ≈ availableProcessors - 1，且全是守护线程。微服务调用是典型的 IO 密集型操作，大量线程会阻塞在 socket read 上，迅速耗尽 commonPool，导致后续所有异步逻辑卡住甚至 JVM 无响应。
正确做法是显式传入专用于 IO 的线程池：
- 用
Executors.newCachedThreadPool()或newFixedThreadPool(20)（按 QPS 和平均 RT 估算） - 避免用
Executors.newSingleThreadExecutor()，单线程无法并发发请求，失去“抢占”意义 - 线程名建议带业务标识，例如
"svc-fallback-pool-%d"，便于排查日志中的线程归属
示例：
ExecutorService ioPool = Executors.newFixedThreadPool(10, r -> {
Thread t = new Thread(r, "fallback-io-" + counter.incrementAndGet());
t.setDaemon(false);
return t;
});
<p>CompletableFuture<User> userSvcA = CompletableFuture.supplyAsync(() -> callUserSvc("A"), ioPool);
CompletableFuture<User> userSvcB = CompletableFuture.supplyAsync(() -> callUserSvc("B"), ioPool);</p><p>userSvcA.acceptEitherAsync(userSvcB, user -> {
log.info("抢到响应：来自副本 {}", user.source);
}, ioPool); // 注意：这里必须再传一次 ioPool
如何确保“真正抢占”而非“运气好”
微服务多副本之间通常有网络延迟差异，但单纯靠 acceptEitherAsync 仍可能因超时、重试、熔断等机制导致响应顺序不可控。要稳定实现抢占，需叠加以下控制：
- 两个请求必须同时发起，不能串行调用
supplyAsync；推荐用allOf包裹后统一触发，或用同一个ExecutorService提交 - 每个请求应设独立超时（如
HttpClient的connectTimeout和readTimeout），避免某副本卡死拖累整体 - 若需 fallback 行为（如 A 副本 200ms 内没回，就强制走 B），不能依赖
acceptEitherAsync，得用orTimeout+exceptionally组合 - 注意：
acceptEitherAsync只消费结果，不取消另一个请求；如需释放资源，得手动对未完成的CompletableFuture调用cancel(true)
最容易被忽略的线程上下文丢失问题
微服务调用常依赖 MDC、TraceId、用户身份等上下文信息，而 acceptEitherAsync 的回调是在新线程中执行的，默认不继承父线程的 InheritableThreadLocal。如果你的日志里突然看不到 traceId，或者权限校验失败，大概率是这里断掉的。
解决方式只有两种：
- 在提交任务前，手动把关键上下文快照传入 lambda（例如
MDC.getCopyOfContextMap()）并在回调开头 restore - 用支持上下文传播的线程池封装器，例如
com.google.common.util.concurrent.MoreExecutors.privilegedThreadFactory()配合自定义ThreadLocal复制逻辑
没有银弹。这个点在压测时往往不暴露，上线后才发现日志链路断裂、审计字段为空——它不报错，只悄悄失效。
