runAfterBoth用于在两个CompletableFuture均完成（无论成功或异常）后同步执行无返回值的Runnable，适用于清理、日志等收尾操作，不消费结果、不支持链式调用、默认在触发完成的线程执行。
runAfterBoth 是做什么的
runAfterBoth 用来在两个 CompletableFuture 都完成（无论成功或异常）后，**同步执行一个无返回值的 Runnable**。它不关心两个前置任务的结果值，只等它们“落地”就触发后续动作。
常见错误现象：有人误以为它会等两个任务都成功才执行——其实不是。runAfterBoth 对异常不敏感，只要两个阶段进入完成态（complete、completeExceptionally 或被取消），它就跑；如果其中一个抛了异常，另一个照常完成，它照样执行。
- 适合场景：清理资源、发日志、更新 UI 状态、触发通知等「收尾型」操作
- 不适合场景：需要基于两个结果做计算 → 应该用
thenCombine或thenAcceptBoth - 它本身不返回新
CompletableFuture，所以不能链式往下接thenApply这类方法
runAfterBoth 和 thenAcceptBoth / thenCombine 的区别在哪
三者都处理“两个任务完成后”的逻辑，但语义和能力完全不同：
-
runAfterBoth：只执行动作，无参数、无返回值，不消费结果 -
thenAcceptBoth：接收两个结果作为参数（(a, b) -> {}），执行消费动作，仍无返回值 -
thenCombine：接收两个结果，返回一个新值（(a, b) -> a + b），会生成新的CompletableFuture
举个例子：你有两个异步加载任务，loadUser() 和 loadConfig()，想在两者都结束时隐藏 loading 动画——用 runAfterBoth 最干净；如果还要把用户和配置拼成一个对象存进缓存，就得换 thenCombine。
为什么 runAfterBoth 不传结果，却还要写两个 CompletableFuture 参数
因为它的职责是「协调时序」，不是「传递数据」。两个参数分别代表你要等待的两个独立异步阶段，runAfterBoth 内部靠监听这两个阶段的完成状态来决定何时触发 Runnable。
容易踩的坑：
- 传入已手动完成（
complete()）或已失败的CompletableFuture，它依然会等——没问题，但要注意这可能导致“看似没动”，其实是它在等那个还没完成的 - 如果其中一个任务永远不完成（比如忘了
complete()，或死锁），runAfterBoth就永远卡住，没有超时机制 - 不要试图在
Runnable里调用get()去取两个前置任务的结果——它们可能已完成，也可能刚完成，但你拿不到引用；真要结果，请改用thenAcceptBoth
实际写法要注意线程上下文
runAfterBoth 默认在「**触发它的那个 CompletableFuture 完成时所在线程**」上执行 Runnable，不是 ForkJoinPool，也不是主线程，更不是你期望的 UI 线程。
这意味着：
- 如果你在 Android 或 JavaFX 中用它更新界面，大概率抛
IllegalStateException（不在 FX 主线程） - 如果前置任务用了自定义线程池，而
Runnable里有 IO 操作，可能阻塞那个线程池的工作线程 - 没有
Async版本，所以无法指定执行器；如需控制线程，请包一层runAsync(() -> {}, executor)
示例：
CompletableFuture<String> userF = CompletableFuture.supplyAsync(() -> fetchUser());
CompletableFuture<String> configF = CompletableFuture.supplyAsync(() -> fetchConfig());
// 下面这行 Runnable 很可能在 ForkJoinPool-worker-X 上执行
userF.runAfterBoth(configF, () -> {
System.out.println("both done"); // ✅ 安全
updateUi(); // ❌ 危险：非 UI 线程
});
真正难的不是怎么写，而是想清楚：这个“之后”到底该在哪个线程发生、要不要等结果、出错了是否还要执行——这些决策一旦错，调试起来比加日志还慢。
