线程池中任务抛异常导致线程消失，是因为ThreadPoolExecutor默认不捕获未处理异常，异常触发Thread.dispatchUncaughtException()终止线程，且线程池不会自动重建该线程。
线程池里任务抛异常，为什么线程直接消失了？
因为 ThreadPoolExecutor 默认不捕获任务内部未处理的异常——异常会顺着 run() 方法栈一路向上，最终由 Thread.dispatchUncaughtException() 处理，而默认行为是打印堆栈后终止该工作线程。线程没了，但线程池不会主动重建它（除非配置了 allowCoreThreadTimeOut 或非核心线程超时），导致后续任务排队甚至阻塞。
常见现象：RejectedExecutionException 突然增多、监控显示活跃线程数持续下降、日志里只有零星的异常堆栈却找不到对应业务失败记录。
- 所有提交到线程池的
Runnable任务，都必须自行包裹try-catch，不能依赖外部捕获 -
Callable的异常会被包装进ExecutionException，由Future.get()抛出，但这只对主动获取结果的场景有效；异步 fire-and-forget 场景下依然会丢异常 - 不要试图重写
Thread.setUncaughtExceptionHandler来统一兜底——线程池复用线程，handler 可能被覆盖或失效
如何让 Runnable 任务安全地吞掉异常并保活线程？
最直接有效的做法：在每个 Runnable 实现里做防御性包裹。这不是“掩盖问题”，而是防止单个任务故障引发线程资源泄漏。
典型错误写法：executor.submit(() -> riskyOperation()); —— 这个 lambda 一旦抛异常，线程就挂了。
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
立即学习“Java免费学习笔记（深入）”；
- 正确写法是显式声明
Runnable并包住逻辑：executor.submit(() -> { try { riskyOperation(); } catch (Exception e) { // 记录日志，别只打 System.out log.error("task failed, ignored to keep thread alive", e); } }); - 如果大量任务都需要同样兜底逻辑，可封装一个工具方法：
safeRun(Runnable)，内部做 try-catch + 日志，但注意避免在其中加锁或阻塞操作 - 禁止在 catch 块里吞掉异常却不记录——这会让问题彻底隐身，排查成本远高于预防成本
submit(Callable) 和 execute(Runnable) 在异常处理上有啥区别？
根本区别不在提交方式，而在你是否「主动消费异常」。execute() 是纯异步，异常只能靠任务自身捕获；submit(Callable) 则把异常转为 Future 的一部分，但你不调 get()，它就永远躺在那儿不爆发。
-
execute(runnable)：异常 → 线程终止（默认行为） -
submit(callable)：异常 → 被封装进Future→ 调用future.get()时才抛ExecutionException -
submit(runnable, result)：等价于submit(Executors.callable(runnable, result))，异常处理逻辑同Callable - 性能影响：频繁调用
Future.get()会阻塞，违背异步初衷；纯后台任务建议坚持用execute()+ 内置 try-catch
自定义 ThreadFactory 能不能解决这个问题？
可以辅助，但不能替代任务内的异常捕获。自定义 ThreadFactory 的价值在于为线程设置统一的 UncaughtExceptionHandler，适用于兜底那些「漏网」的异常（比如 Thread.sleep() 中被中断、JVM 层面的错误），但它无法阻止线程终止，也不能恢复已退出的工作线程。
- 设置 handler 示例：
new ThreadFactoryBuilder() .setUncaughtExceptionHandler((t, e) -> log.error("uncaught in thread {}", t.getName(), e)) .build(); - 这个 handler 只会在异常真正未被捕获时触发，它不改变线程池对异常的默认响应（即线程仍会退出）
- 别指望靠它来代替业务层的 try-catch——那是职责错位，且 handler 里加复杂逻辑（如重试、告警）反而可能拖慢异常处理路径
Runnable 有没有给自己系好安全带。 
