handle不能替代finally，它仅在CompletableFuture正常完成时执行，不响应取消或未完成状态；需用whenComplete或Java 21+的finallyAsync确保资源在所有终态下释放。
handle 方法不是 finally，它只在前序阶段完成时触发
handle 确实能同时接收 result 和 exception，但它不会在异常未被捕获（比如上游抛出 RuntimeException 且没被 exceptionally 或 whenComplete 拦截）的情况下执行。更关键的是：如果上游 CompletableFuture 被取消（cancel(true)），handle 也不会运行——它只响应「完成」（completed），不响应「取消」（cancelled）或「中断」。
所以想靠 handle 做“最终释放”，必须确保两点：上游一定完成（不能任由它悬停或被 cancel），且 所有异常路径都收敛到该 handle 调用点。
- 避免直接链式调用
thenApply(...).handle(...)，因为中间任意一环抛异常且未被处理，后续handle就不会触发 - 推荐统一用
whenComplete或finallyAsync（Java 21+）替代；若坚持用handle，需前置兜底：用exceptionally把异常转为 null/占位对象，再进handle - 示例写法：
future .exceptionally(t -> { cleanup(); return null; }) .handle((r, t) -> { if (t == null) cleanup(); return r; });——但注意这会执行两次cleanup()（exceptionally里一次，handle里一次），需加标记位
资源释放逻辑必须幂等，且不能阻塞线程
异步链路中，handle 默认在上游任务完成的同一线程（或 ForkJoinPool.commonPool()）中执行。如果 cleanup() 是 IO 密集型（如关闭数据库连接、发 HTTP 请求），可能拖慢整个线程池，甚至引发死锁（比如清理逻辑又依赖另一个 CompletableFuture 的结果）。
- 释放操作本身应是轻量、无副作用、可重入的：比如把
AtomicBoolean closed = new AtomicBoolean()设为 true，再检查是否已关才真正调resource.close() - 不要在
handle里调Thread.sleep、CountDownLatch.await()或任何同步等待 - 若必须异步清理，用
CompletableFuture.runAsync(() -> cleanup(), executor)显式指定专用线程池，别依赖默认池
handle 无法捕获上游未 complete 的情况，cancel 需单独监听
当调用 future.cancel(true)，handle 不触发，whenComplete 也不触发——只有 cancel 后立即执行的回调才是 isCancelled() 为 true 的状态。这意味着：如果你的资源需要在取消时也释放（比如长连接、文件句柄），handle 完全不可靠。
- 正确做法是：在创建原始
CompletableFuture时，用CompletableFuture.supplyAsync(..., executor)并持有对Future的引用，在外部调用cancel前手动触发清理 - 或者改用
CompletableFuture的子类 + 重写cancel方法（不推荐，破坏封装） - 更实用的折中：用
whenComplete+if (future.isCancelled()) { cleanup(); }，但前提是这个future是你可控的源头，且没被多次thenCompose包装丢失引用
Java 21+ 的 finallyAsync 是更安全的选择
如果你能升级 JDK，finallyAsync(Runnable) 是专为此类场景设计的：它保证在 CompletableFuture 的三种终态（success / exception / cancel）下都执行，且自动提交到指定执行器，不阻塞原线程。
- 用法简单：
future.finallyAsync(() -> cleanup(), cleanupExecutor);
- 注意：它不接收参数，所以清理逻辑不能依赖结果值或异常对象；若需区分原因，仍得回到
whenComplete+ 手动判断isDone()/isCancelled()/isCompletedExceptionally() - 低版本 JDK 可模拟：用
whenComplete+try { future.getNow(null); } catch (CancellationException e) { cleanup(); }，但不够优雅，且getNow在未完成时返回 null 可能掩盖问题
真正难的从来不是写个 handle，而是厘清谁拥有资源生命周期、谁负责触发释放、以及 cancel 是否算“终结”。多数线上泄漏，都源于假设 handle 能覆盖所有退出路径——而它不能。
