handle 总在阶段完成后执行，无论成功或异常，通过 bifunction 双参数（结果与异常必居一空）实现双通道捕获；需同时判空二者以准确区分状态，推荐无条件调用清理方法并用 completionexception 包装异常透传。
handle 方法的核心行为：结果与异常的双通道捕获
handle 不同于 thenApply 或 exceptionally，它总会在阶段完成后执行，无论前序是否抛出异常。它的函数签名是 BiFunction<t throwable r></t> —— 第一个参数是正常结果（成功时非 null），第二个参数是异常（失败时非 null），二者**必居其一为 null**。这意味着你不能只检查 result != null 就认为成功，必须同时判空两个参数才能准确区分状态。
常见错误是写成：handle((res, ex) -> { if (res != null) { /* 清理 */ } }) —— 这会漏掉异常路径下的清理逻辑。
统一清理的典型实现模式
清理动作（如关闭资源、释放锁、记录日志）通常不依赖计算结果本身，而是需要确保“无论如何都执行一次”。推荐写法是把清理逻辑提取为独立方法，并在 handle 中无条件调用：
CompletableFuture<string> future = CompletableFuture.supplyAsync(() -> {
// 可能抛异常的耗时操作
return riskyOperation();
}).handle((result, ex) -> {
cleanup(); // 无论成功失败都执行
if (ex != null) {
throw new CompletionException(ex); // 保持异常传播
}
return result; // 保持原结果透传
});</string>
- 清理代码必须放在
handle函数体最前或最稳定位置，避免被提前 return 跳过 - 若需透传原始异常，用
CompletionException包装，这是CompletableFuture的标准异常包装约定 - 不要在
handle里做耗时阻塞操作（如 IO），否则拖慢整个异步链
与 whenComplete 的关键区别：要不要返回新值
如果你的清理不改变最终结果类型或值，whenComplete 更简洁——它签名为 BiConsumer<t throwable></t>，不强制返回值，语义更贴合“副作用”场景：
future.whenComplete((result, ex) -> {
cleanup();
if (ex != null) {
log.error("task failed", ex);
}
});
而 handle 强制返回值，适合需要转换结果（如兜底默认值）+ 清理的组合场景。选哪个取决于你是否要修改后续可获取的结果。
注意：whenComplete 不会中断异常传播，也不影响返回值；handle 若返回值则会覆盖原结果，若抛异常则替换原异常。
资源泄漏风险点：清理时机与 CompletableStage 生命周期
最容易被忽略的是：如果 CompletableFuture 被 GC 回收前未完成，你的 handle 根本不会执行，清理就彻底丢失。这在超时未设置、任务卡死、线程池饱和时很常见。
应对方式：
- 始终配合
orTimeout或completeOnTimeout设置合理超时 - 对关键资源（如数据库连接、文件句柄），考虑使用
try-with-resources在源头封装，而非全靠异步回调清理 - 避免在
handle中引用外部大对象，防止因闭包导致CompletableFuture无法被及时回收
真正可靠的清理，永远是“作用域内自动管理”优先于“异步回调手动触发”。handle 是补救手段，不是第一道防线。
