手动绑定CompletableFuture而非使用链式API有何优势

在研究AWS SDK Java v2异步代码时，会发现源码中大量使用手动绑定CompletableFuture的编码模式，典型实现如下：

CompletableFuture<Response<OutputT>> toReturn = new CompletableFuture<>();
(...)
CompletableFutureUtils.forwardExceptionTo(requestFuture, toReturn);
CompletableFutureUtils.forwardExceptionTo(toReturn, requestFuture);

requestFuture.thenAccept(request -> {
    try {
        CompletableFuture<Response<OutputT>> executeFuture = executeHttpRequest(request, context);
        executeFuture.whenComplete((r, t) -> {
            if (t != null) {
                toReturn.completeExceptionally(t);
            } else {
                toReturn.complete(r);
            }
        });
        CompletableFutureUtils.forwardExceptionTo(toReturn, executeFuture);
    } catch (Throwable t) {
        toReturn.completeExceptionally(t);
    }
});

return toReturn;

很多人会疑惑为什么不用更简洁的线性链式写法，比如：

return requestFuture.thenAccept(request -> executeHttpRequest(request, context));

很多人初看这段手动绑定的代码会觉得冗余啰嗦，远不如链式写法简洁，实际上这种看似笨拙的实现，是基础类库在高并发场景下踩过无数坑之后沉淀的方案，相比链式写法有不可替代的优势。

• 简化链式写法本身存在功能性缺陷
  上面给出的链式示例根本无法正常工作：thenAccept是消费型接口，返回值为CompletableFuture<Void>，会直接丢失executeHttpRequest返回的响应结果，就算替换成语义匹配的thenCompose实现链式串联，依然存在很多无法解决的问题。
• 实现可靠的双向异常、取消信号传播
  JDK原生CompletableFuture的链式调用是单向信号传递：上游任务的异常、完成结果会传给下游，但如果下游（返回给业务调用方的最终Future）被主动取消、主动设置异常，这个信号不会反向传递给上游的requestFuture、executeFuture，会导致上游任务在后台空跑，长期占用HTTP连接、线程资源，最终造成资源泄漏。
  源码中双向调用forwardExceptionTo的逻辑，就是把多个关联的Future做双向绑定：任意一个Future出现异常、被取消，其他关联Future都会立刻收到信号，及时中断任务、释放占用资源，不会出现悬空的异步任务。
• 兜底捕获所有同步异常，避免调用方永久挂起
  链式调用只能捕获回调函数返回的Future内部的异常，如果executeHttpRequest方法在返回Future之前就直接抛出异常（比如参数校验失败、连接池耗尽直接报错、请求上下文初始化异常），虽然部分场景下JDK能兜底捕获，但在类加载异常、某些Error类型抛出的场景下，存在异常漏传的风险，会导致调用方拿到的Future永远不会完成，业务线程挂死。手动写try-catch块包裹整个执行逻辑，可以保证所有异常都能被正确传递到返回的Future中，彻底避免这类问题。
• 精准控制语义，规避JDK实现缺陷
  原生CompletableFuture的链式实现会把所有异常包装成CompletionException抛出，上层业务需要额外拆包才能拿到真实异常，手动调用completeExceptionally可以直接透传原生异常，减少不必要的包装。同时不同JDK版本的CompletableFuture取消逻辑存在已知bug，比如取消信号传递延迟、取消后上游任务无法正常中断等，手动绑定信号可以绕过这些JDK层面的缺陷，还可以自定义取消逻辑：比如取消时清理请求上下文、上报监控指标、决定要不要中断正在执行的IO请求，这些都是硬编码实现的原生链式调用做不到的。
• 减少链式包装开销，提升高并发场景性能
  每调用一次thenAccept/thenCompose这类链式方法，都会新增一个CompletionStage节点，不仅会让异常栈变深、提升调试难度，还会带来额外的内存分配、回调注册开销。SDK作为高并发场景下的基础组件，需要把性能开销压到最低，手动控制Future的完成逻辑可以省去不必要的阶段包装，在高QPS场景下能带来明显的性能提升。

内容的提问来源于stack exchange，提问作者Tomaz Fernandes