Java线程池不主动捕获异常，execute()异常交UncaughtExceptionHandler默认打印stderr，submit()异常封装在Future中需get()才抛出；推荐任务内try-catch或重写afterExecute统一处理。
Java 线程池本身不会主动捕获或传播异步任务中的异常，处理方式取决于你用 execute() 还是 submit() 提交任务，也取决于是否主动封装、监听或钩住执行过程。核心原则是：**异常不处理，就静默丢失或仅打印堆栈，无法触发业务响应。**
区分 execute() 和 submit() 的异常表现
execute() 提交 Runnable 时，若任务内抛出未捕获异常（如 RuntimeException），该异常会直接交给线程的 UncaughtExceptionHandler 处理，默认行为是打印到 System.err，但不会中断线程池运行。
submit() 提交 Runnable 或 Callable 后返回 Future，异常不会立即抛出，而是被 Future 封装。必须显式调用 future.get() 才会以 ExecutionException 形式重新抛出，其 getCause() 才是原始异常。
-
execute()：异常可见（控制台有堆栈），但无返回值，无法程序化感知 -
submit()：异常不可见，除非调用get()；但get()会阻塞，且需手动处理InterruptedException和ExecutionException
在任务内部加 try-catch 是最直接的方式
无论用哪种提交方式，都可以把异常逻辑收口到任务体里：
立即学习“Java免费学习笔记（深入）”；
executor.submit(() -> {
try {
doBusiness();
} catch (Exception e) {
log.error("异步任务执行失败", e);
// 上报监控、触发告警、写入重试表等
}
});
这种方式简单可靠，适用于绝大多数业务场景，尤其适合对异常有明确补偿或记录需求的任务。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
用 afterExecute 钩子统一兜底处理
ThreadPoolExecutor.afterExecute(Runnable r, Throwable t) 是官方提供的扩展点，t 参数就是任务执行中抛出的异常（包括 Runnable 未捕获的异常，以及 Future.get() 调用时暴露的异常）。
重写它可实现集中日志、指标打点、熔断降级、自动补偿等：
- 只对
t != null的情况做处理，避免干扰正常流程 - 注意
Callable的异常已被Future捕获，只有显式调用get()才会触发此处的t - 适合与监控系统（如 Prometheus）、告警通道（如钉钉机器人）集成
通过自定义 ThreadFactory 设置未捕获异常处理器
对 execute() 类任务特别有效。创建线程池时传入自定义 ThreadFactory，为每个工作线程设置 setUncaughtExceptionHandler：
ThreadFactory factory = r -> {
Thread t = new Thread(r, "biz-async-" + counter.incrementAndGet());
t.setUncaughtExceptionHandler((thread, ex) ->
log.error("线程 {} 异常终止", thread.getName(), ex)
);
return t;
};
注意：Callable 任务的异常不会走这个处理器，因为 Future 已将其拦截并封装。
慎用 Future.get()，超时和中断必须处理
若必须用 submit() 并依赖 get() 获取结果或异常，务必：
- 使用带超时的
get(long, TimeUnit)，避免无限阻塞 - 捕获
ExecutionException并调用e.getCause()取原始异常 - 捕获
InterruptedException后调用Thread.currentThread().interrupt()恢复中断状态 - 不要在循环或高频调用中无保护地
get()，容易拖慢主线程
