Java线程池异常默认不传播，需主动捕获：1. Callable+Future.get()获取ExecutionException；2. 重写afterExecute全局捕获；3. Runnable手动try-catch；4. 设置UncaughtExceptionHandler兜底。
Java 线程池中抛出的异常默认不会传播到主线程，也不会被外层 try-catch 捕获，容易被静默吞掉，导致问题难以排查。关键是要明确：异常发生在任务执行过程中（即 Runnable 或 Callable 内部），而线程池本身不主动暴露这些异常，必须通过特定方式主动捕获和处理。
使用 Callable + Future 显式获取异常
相比 Runnable，Callable 允许任务返回结果并抛出受检异常，配合 Future.get() 可以捕获执行时的异常（包括运行时异常）：
- 提交任务用
executor.submit(Callable)，返回Future - 调用
future.get()会阻塞直到任务完成；若任务抛异常，get()将包装为ExecutionException抛出，其getCause()即原始异常 - 注意：不调用
get()就无法感知异常；多个任务需逐个检查或使用invokeAll
重写 ThreadPoolExecutor 的 afterExecute 方法
这是最常用且可靠的全局异常捕获方式，适用于所有提交的任务（Runnable/Callable）：
- 继承
ThreadPoolExecutor，重写afterExecute(Runnable r, Throwable t) - 参数
t：仅当任务因未捕获异常而突然终止时非 null（例如 Runnable 中 throw RuntimeException） - 对于
Callable，即使它抛异常，只要没调用Future.get()，t仍为 null；此时异常已被封装进 Future，需靠 get() 触发 - 在重写方法中记录日志、告警或做自定义恢复逻辑
为 Runnable 包装 try-catch（简单直接）
在提交前手动包裹任务逻辑，把异常兜住并自行处理：
立即学习“Java免费学习笔记（深入）”；
- 适合已知任务易出错、且希望统一日志或降级的场景
- 示例：
executor.execute(() -> { try { doWork(); } catch (Exception e) { log.error("task failed", e); } }); - 缺点：每个任务都要写，不够优雅；无法影响线程池行为（如拒绝、重试）
设置 UncaughtExceptionHandler（仅对未捕获的 RuntimeException 有效）
为线程池中的工作线程设置异常处理器，但作用有限：
- 仅捕获线程内未被任何 catch 捕获的
RuntimeException和Error - 对
Checked Exception无效（编译不通过）；对Callable中的异常也无效（已被 Future 封装） - 需通过
ThreadFactory设置，例如：创建线程时调用t.setUncaughtExceptionHandler(...) - 适合兜底日志，不能替代业务级异常处理
不复杂但容易忽略，核心是分清异常来源和传播路径：任务内抛出 → 是否被 try-catch 吞掉 → 是否通过 Future.get() 主动拉取 → 是否触发线程级未捕获处理器。选对方式，才能让异常真正“可见”。
