java线程池异常默认不冒泡不打印，需分层兜底：execute异常走uncaughtexceptionhandler，submit异常封装在future中；应组合使用任务内捕获、自定义threadfactory、重写afterexecute、显式调用future.get，并禁用executors工厂、统一接入异常通道。
Java线程池里的异常不会自动冒泡到主线程，也不会默认打印日志，任务失败后悄无声息——这不是Bug，而是设计使然。关键在于理解不同提交方式的异常流向，并建立分层兜底机制。
execute() 和 submit() 的异常行为完全不同
这是最常被混淆的起点：
-
execute(Runnable)：异常会“逃出”工作线程，触发线程的
UncaughtExceptionHandler，默认打印堆栈（但若日志配置不输出控制台，就等于丢失） -
submit(Callable)：异常被
FutureTask捕获并封装进Future，不调用get()就永远不会暴露，连日志都不会有
四层兜底策略，缺一不可
单靠某一种方式容易遗漏，建议组合使用：
- 任务内 try-catch：最直接，在 Runnable/Callable 内部捕获并记录日志或上报监控
-
自定义 ThreadFactory：为每个线程设置
setUncaughtExceptionHandler，捕获 execute 类异常和未处理的运行时错误 -
重写 afterExecute()：ThreadPoolExecutor 提供的钩子方法，可统一检查
Future是否异常完成，适合处理 submit 场景 -
Future.get() 显式调用：对 submit 提交的任务，必须在合适时机（如结果使用前、定时轮询）调用
get()，否则异常永远沉睡
生产环境必须做的三件事
避免“线上出问题才第一次看到异常”：
-
禁用 Executors 工厂方法：改用
ThreadPoolExecutor显式构造，才能设置ThreadFactory和RejectedExecutionHandler -
所有 submit 结果必须配超时 get：例如
future.get(30, TimeUnit.SECONDS)，防止阻塞+掩盖异常 -
接入统一异常通道：把
UncaughtExceptionHandler和afterExecute中捕获的异常，发往日志系统、告警平台或指标服务（如 Prometheus）
别忽略虚拟线程的新变化
使用 Project Loom 虚拟线程时，异常仍可能静默：
- 虚拟线程默认不继承宿主线程的异常处理器，需显式调用
Thread.ofVirtual().uncaughtExceptionHandler(...) - 在
CompletableFuture或反应式链中抛出的异常，会被包装成CompletionException，要用join()+ 外层 catch 捕获 - 堆栈追踪可能断裂，建议配合结构化日志，记录虚拟线程 ID 和调度上下文
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
