submit()会将异常包装为executionexception，必须调用future.get()并解包e.getcause()才能获取原始异常；execute()仅对未捕获的runtimeexception触发uncaughtexceptionhandler；统一捕获应重写threadpoolexecutor.afterexecute()。
submit() 会把异常包装成 ExecutionException，不 catch 就看不到原始错误
用 submit() 提交 Runnable 或 Callable 时，任务里抛出的异常不会直接冒泡到主线程，而是被塞进 ExecutionException 里，再包一层。你调 future.get() 才会真正触发它——但很多人只提交、不 get，或者 try-catch 了外层异常却没解包，结果日志里全是 java.util.concurrent.ExecutionException: java.lang.NullPointerException，根本不知道 NPE 发生在哪行。
实操建议：
- 所有
submit()后必须配future.get()（或带超时的future.get(5, TimeUnit.SECONDS)），否则异常永远沉底 - catch
ExecutionException后，一定要调e.getCause()拿原始异常，再打日志或处理 - 如果只是想“fire and forget”，又希望异常不丢，改用
execute()+ 自定义ThreadFactory设置UncaughtExceptionHandler
execute() 抛出的异常会走 UncaughtExceptionHandler，但仅限未捕获的 RuntimeException
execute() 提交 Runnable，一旦运行中抛出未捕获的 RuntimeException（比如 NullPointerException、ArrayIndexOutOfBoundsException），线程池默认会调用该线程的 UncaughtExceptionHandler。但注意：它对 CheckedException 无效——因为 Runnable.run() 不允许抛出检查异常，编译就过不去；你硬塞 throws IOException 会报错。
常见错误现象：
- 自定义了
ThreadFactory并设置了 handler，但日志里还是没看到异常 —— 很可能任务里 try-catch 吞掉了异常，或者抛的是Exception而非RuntimeException - 用 Lombok 的
@SneakyThrows包装检查异常后扔进execute()，看似能跑，实际异常仍被吞（因为底层还是通过反射绕过检查，但线程执行时没走标准异常分发路径）
性能影响：handler 是同步调用的，如果 handler 里做耗时操作（比如写磁盘日志），会阻塞工作线程退出，间接拖慢线程复用。
ThreadPoolExecutor 的 afterExecute() 是唯一能统一捕获两类异常的地方
无论是 execute() 还是 submit()，只要重写 ThreadPoolExecutor.afterExecute(Runnable r, Throwable t)，就能拿到「任务本身」和「它抛出的异常」。这个方法在任务结束后、线程返回前被调用，且 t 参数对 submit() 任务也有效（此时 t 就是原始异常，不是 ExecutionException）。
使用场景：
- 统一收集异常指标（比如上报 Prometheus）
- 记录任务耗时 + 异常堆栈到结构化日志
- 对特定异常类型自动重试（需配合自定义
Runnable携带重试上下文）
注意点：
- 必须继承
ThreadPoolExecutor并重写该方法，不能靠装饰器模式实现 -
t为null表示任务正常结束；不为null时，就是原始异常（submit()和execute()在这里没有区别） - 别在
afterExecute里做阻塞操作，否则卡住线程回收
ForkJoinPool 和 Executors.newCachedThreadPool 的异常处理更隐蔽
这两个池子底层都用了 ForkJoinPool 或其变种，它们对异常的处理逻辑和普通 ThreadPoolExecutor 不同：submit() 后不 get()，异常真的就丢了；execute() 抛异常时，即使设置了 UncaughtExceptionHandler，也可能因 fork/join 任务窃取机制导致 handler 被调用在线程池外部的线程上，日志归属混乱。
参数差异：
-
Executors.newCachedThreadPool()创建的池子，其内部ThreadFactory默认没设 handler，异常全静默 -
ForkJoinPool.commonPool()完全不响应UncaughtExceptionHandler，只能靠afterExecute（但它不是ThreadPoolExecutor，没法重写）
所以，高可靠场景下，别用 Executors 工厂方法，老老实实 new ThreadPoolExecutor，自己控制构造参数和钩子方法。
最易被忽略的一点：异常掩盖往往不是代码写错了，而是监控没跟上——你得确保有地方真正在消费 afterExecute 或 future.get() 的结果，而不是只盯着线程池是否“还在跑”。
