线程池任务异常需特殊处理否则静默消失，可通过任务内try-catch、重写afterExecute、设置UncaughtExceptionHandler或使用Callable+Future捕获，建议内部处理结合全局兜底。
Java中线程池任务执行时抛出的异常不会像普通方法调用那样直接向上抛出，因此容易被忽略。必须通过特定方式捕获和处理，否则异常会“静默消失”，影响程序的稳定性和调试。
使用try-catch在任务内部处理异常
最直接的方式是在提交给线程池的任务（Runnable 或 Callable）中自行捕获异常。
示例：- 对于 Runnable 任务，把业务逻辑包裹在 try-catch 中，记录日志或做补偿处理。
- 对于 Callable 任务，异常会被封装在返回的 Future 中，调用 get() 时会重新抛出 ExecutionException。
这种方式简单有效，适合大多数场景，尤其是需要对不同任务做差异化异常处理的情况。
重写ThreadPoolExecutor的afterExecute方法
ThreadPoolExecutor 提供了 afterExecute 钩子方法，在任务执行结束后（无论是正常完成还是抛出异常）都会被调用。可以继承 ThreadPoolExecutor 并重写该方法来统一处理异常。
立即学习“Java免费学习笔记（深入）”；
说明：- 第二个参数 Throwable 是任务执行过程中抛出的异常，只有在 execute 提交 Runnable 且任务内部未捕获异常时才会非 null。
- submit 方法提交的任务，异常不会传递到 afterExecute，因为它们被 Future 封装了。
适用于需要全局监控任务异常的场景，比如记录错误日志、告警等。
为Thread设置UncaughtExceptionHandler
线程池中的线程如果抛出未捕获异常，默认行为是打印堆栈并终止线程。可以通过为线程设置 UncaughtExceptionHandler 来自定义处理逻辑。
操作方式：- 在创建线程时（如使用 ThreadFactory），为每个线程设置 handler。
- handler 可以统一记录日志、重启线程或上报监控系统。
注意：该方式仅对 execute 提交且未捕获异常的任务有效；submit 提交的任务仍由 Future 处理异常。
优先使用Callable + Future获取异常
如果希望主动获取任务执行结果和异常，应使用 Callable 而不是 Runnable，并通过 Future 的 get() 方法获取结果。
关键点：- get() 抛出 ExecutionException，其 getCause() 返回原始异常。
- 可以结合超时机制避免长时间阻塞。
这种方式更适合需要关注任务执行结果和失败原因的场景。
基本上就这些。选择哪种方式取决于你的任务类型和异常处理需求。通常建议任务内部做好基础 try-catch，再配合全局 handler 做兜底。这样既保证健壮性，也便于排查问题。
