线程池中异步任务异常不会静默消失，而是按执行模型定向传播：Runnable异常触发afterExecute或UncaughtExceptionHandler，Callable异常封装于Future需get()显式获取，CompletableFuture则支持链式传递与recover处理。
线程池中异步任务链路的异常不会自动消失，也不会被静默吞掉——它会按调用栈逐层回溯，但传播路径受执行模型影响，和普通方法调用不完全相同。
异常在任务提交后如何“落地”
线程池执行的是 Runnable 或 Callable 任务，异常不会直接抛到提交方线程（比如主线程）的调用栈上。JVM 不会把 task.run() 抛出的异常“冒泡”回 submit() 调用处，而是由线程池内部捕获并处理：
- 对于 Runnable：异常在 task.run() 中抛出后，线程池会调用 afterExecute(task, ex) 回调（若已重写），默认行为是打印堆栈并终止当前工作线程（不影响线程池整体运行）
- 对于 Callable：异常会被封装进 Future.get() 返回的 ExecutionException 中，必须显式调用 get() 才能暴露原始异常（cause）
- 未捕获的 RuntimeException 在线程池线程中抛出时，最终会触发该线程的 UncaughtExceptionHandler，默认打印日志并退出该线程
CompletableFuture 链式调用中的异常传递特点
CompletableFuture 把异常传播变成了可组合、可恢复的流程，不是简单中断，而是延续为下一个阶段的输入：
- 使用 thenApply、thenAccept 等无 async 后缀的方法时，异常会沿链向下传递，被后续的 exceptionally、handle 或 whenComplete 捕获
- 使用 thenApplyAsync 等带 async 的方法时，异常发生在新线程（如 ForkJoinPool.commonPool 或自定义线程池）中，传播范围仅限于该线程内；若未处理，仍走线程池的 afterExecute 或 UncaughtExceptionHandler
- 多个异步阶段串联时，一个阶段抛异常，后续依赖它的阶段不会执行（除非用 recover 或 handle 显式接管），但其他无关分支不受影响
深度链路里异常引发的阻塞传染风险
当异步任务链路存在强依赖（如 A→B→C，B 必须等 A 结果），而某环节因异常未被及时处理，可能造成资源滞留或响应堆积：
立即学习“Java免费学习笔记（深入）”；
- IO 密集型任务未设超时，又没用 exceptionally 补偿，会导致线程长期空等，占用线程池资源
- 任务中混用同步阻塞操作（如数据库连接未设 query timeout），异常发生前就已卡住线程，加剧线程饥饿
- 异常被吞掉（比如 try-catch 后空 return 或 log 了事），上游得不到失败信号，无法触发降级或重试逻辑
- 建议对关键链路每个阶段设置超时（orTimeout）、兜底 fallback（handle/exceptionally），并监控 Future.isDone() / isCancelled() 状态
如何让异常真正“可见且可控”
不能只靠日志被动发现，得从执行机制上确保异常能抵达决策点：
- 避免在 Runnable 中裸 throw：改用 Callable + Future.get()，或用 CompletableFuture.supplyAsync 包装，利用其异常链能力
- 统一配置线程池的 UncaughtExceptionHandler，记录线程名、任务标识、堆栈，尤其注意虚拟线程需手动命名才便于追踪
- 慎用 finally 块做资源清理——关闭流、释放连接时若再抛异常，会覆盖原始业务异常；应改为 if (res != null) try { res.close(); } catch (Exception ignored) {}
- 包装异常时务必保留 cause：new ServiceException("下单失败", originalEx)，否则调试时丢失根因
