Java线程池中任务抛出未捕获异常不会导致线程池整体失败，但会静默终止工作线程、掩盖问题、引发资源泄漏或任务丢失；默认不传播异常，需通过自定义UncaughtExceptionHandler或任务内try-catch主动处理。
Java线程池中任务抛出未捕获异常，不会导致线程池整体失败，但会 silently 终止该工作线程，还可能掩盖问题、引发资源泄漏或任务丢失。关键不是“线程池失败”，而是异常未被感知和处理。
任务异常默认不传播，线程会静默退出
ThreadPoolExecutor 中，Worker 线程执行 run() 时若任务抛出 RuntimeException 或 Error，线程会直接终止，然后线程池自动创建新线程补位（仅限 corePoolSize 以下或 allowCoreThreadTimeOut 开启时）。这个过程对外不可见，日志里也看不到异常堆栈——除非你主动捕获。
- Runnable 接口无受检异常声明，run() 内异常无法向上抛出
- submit(Callable) 提交的任务，异常会被包装进 ExecutionException，但必须调用 get() 才能触发；不 get 就永远埋着
- 使用 execute() 提交 Runnable 时，异常完全无人接手，只会打印到 Thread.getUncaughtExceptionHandler（默认是 System.err）
统一兜底：设置线程工厂 + 异常处理器
最简单有效的做法，是在创建线程池时通过 ThreadFactory 指定自定义 UncaughtExceptionHandler：
ThreadFactory factory = r -> {
Thread t = new Thread(r);
t.setUncaughtExceptionHandler((thread, ex) -> {
log.error("线程 {} 执行异常", thread.getName(), ex);
// 可选：上报监控、告警、记录指标
});
return t;
};
ExecutorService pool = new ThreadPoolExecutor(2, 4, 60, TimeUnit.SECONDS,
new LinkedBlockingQueue<>(), factory);
推荐写法：用 try-catch 包裹任务逻辑
比依赖异常处理器更主动、更可控。尤其适合业务关键任务：
ImageMagick 批处理处理器
下载
使用 ImageMagick 的 convert 和 mogrify 命令进行批量图像处理，支持调整大小、裁剪、水印和格式转换。与 libvips 集成以实现高性能缩略图生成。
立即学习“Java免费学习笔记（深入）”；
- 对 execute() 提交的 Runnable，直接在 run() 内 try-catch
- 对 submit() 的 Callable，建议封装一层 SafeCallable，内部 catch 所有异常并返回 Result 或打日志
- Spring 环境下可配合 @Async + 自定义 AsyncUncaughtExceptionHandler
排查技巧：看日志 + 线程状态 + 活跃数突变
线上发现任务不执行、响应变慢、线程数持续增长或骤降，可能是异常在作祟：
- 检查 GC 日志和线程 dump：频繁看到 "pool-1-thread-N" 创建/销毁，说明 Worker 在反复重启
- 开启 JVM 参数 -XX:+PrintGCDetails 和 -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput，辅助定位
- 用 JMX 或 Actuator 暴露 ThreadPoolTaskExecutor 指标：activeCount、poolSize、completedTaskCount 是否停滞或异常跳变
- 加一个定时任务，每分钟输出线程池状态（getActiveCount()、getCompletedTaskCount()），异常时趋势会明显偏离
基本上就这些。不复杂但容易忽略——异常没被 catch，线程就白跑了，任务就丢了，问题就藏住了。
