completablefuture任务“未执行”或“卡死”的主因是线程资源耗尽、调度阻塞或异常静默，需从线程模型（如避免commonpool混入i/o）、执行路径（禁用get/join阻塞）、可观测性（加traceid、监控队列）三方面排查。
CompletableFuture 任务“未执行”或“卡死”，往往不是代码没写，而是线程资源被耗尽、调度被阻塞或异常被静默吞掉。这类问题在压测或流量突增时高频出现，排查需从线程模型、执行路径和可观测性三方面入手。
看线程池是否已满或被共享阻塞
默认的 ForkJoinPool.commonPool() 是全局共享的，一旦有 I/O 阻塞任务（如数据库查询、HTTP 调用）混入，就会拖垮所有异步逻辑。常见表现是：CPU 低、线程数卡在上限、大量任务堆积在队列中。
- 用
jstack <pid></pid>查看线程堆栈，重点搜ForkJoinWorkerThread和WAITING/BLOCKED状态；若看到大量线程停在get()、join()或 I/O 调用上，基本锁定线程池争用 - 检查代码是否混用
supplyAsync(() -> ...)（无显式线程池）和thenApplyAsync(..., pool)（带线程池）——前者全走 commonPool，后者可能隔离，但源头仍污染全局池 - 强制替换为自定义线程池：对 DB、RPC、文件等 I/O 型操作，必须指定专用线程池，且拒绝策略建议设为
AbortPolicy或带告警的自定义策略，避免无声丢任务
查异步链是否被阻塞式调用中断
在 CompletableFuture 链中混用 get()、join()、allOf(...).get() 等同步等待，会把异步流水线强行拉回阻塞模式，尤其当它们出现在子任务内部（如嵌套 runAsync 中调 allOf().get()），极易引发线程池饥饿型死锁。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 搜索代码中所有
.get(、.join()、.getNow(调用，确认是否在非主线程上下文中使用；生产环境应禁止在supplyAsync或回调中直接阻塞等待 - 将
allOf(futures).get()替换为allOf(futures).thenRun(...)，让后续逻辑也异步化；如必须等结果，改用orTimeout+exceptionally控制超时边界 - 注意
thenCompose内部若返回未完成的 CompletableFuture，外层会一直挂起——确保嵌套返回的是已完成对象，或显式complete()
验异常是否被跳过或未传播
CompletableFuture 的异常不会自动打印，也不会中断主线程，一旦漏写 exceptionally、handle 或 whenComplete，任务就“悄无声息地失败”，看起来像“没执行”。
- 检查每个
supplyAsync、thenApplyAsync后是否至少配一个异常处理节点；特别警惕thenAccept这类无返回值方法——它不接收异常，上游异常会直接终止整条链 - 用
whenComplete((r, e) -> { if (e != null) log.error("task failed", e); })兜底记录，比exceptionally更安全，因它不改变返回值类型，也不依赖异常是否被“消费” - 测试时主动抛异常（如在
supplyAsync中 throw new RuntimeException），验证日志是否打出、降级逻辑是否触发，避免“以为写了其实没生效”
加基础可观测性快速定位
没有指标和日志，排查就是盲人摸象。最简可行方案只需三步：
- 给每个关键
CompletableFuture打唯一 traceId（如用MDC或ThreadLocal透传），并在whenComplete中统一打开始/结束/异常日志 - 用
ThreadPoolExecutor的getActiveCount()、getQueue().size()定期上报，监控线程活跃度与队列积压趋势 - 在 JVM 启动参数加
-Djava.util.concurrent.ForkJoinPool.common.parallelism=4（调小默认并行度），避免 commonPool 被无意撑爆
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
