Java线程池任务异常需区分execute()和submit()：前者异常触发UncaughtExceptionHandler，需自定义ThreadFactory或重写afterExecute；后者异常封装在Future中，必须调用get()才能暴露，且需getCause()获取原始异常；推荐统一用SafeRunnable/SafeCallable包装或AOP拦截，并结合监控告警确保可观测性。
Java线程池任务异常不会自动暴露，关键在于区分 execute() 和 submit() 两种提交方式的异常路径——前者异常会逃出线程边界触发未捕获处理器，后者则被 Future 封装静默吞掉，不调用 get() 就永远看不到。
execute 提交的任务：异常会“杀死”工作线程
Runnable 通过 task.run() 执行，一旦抛出未捕获异常，就会跳出线程执行栈，触发 UncaughtExceptionHandler。默认行为是打印堆栈到控制台，但生产环境往往无日志可见，等于异常丢失。
- 必须为线程池配置自定义
ThreadFactory，在创建线程时设置setUncaughtExceptionHandler - 在 handler 中完成三件事：记录结构化日志（如发送到 ELK）、触发告警（如 Slack/邮件）、避免静默失败
- 也可重写
ThreadPoolExecutor.afterExecute(Runnable, Throwable)，该方法在线程执行完后被调用，Throwable参数即为实际异常
submit 提交的任务：异常藏在 Future 里
Callable 被包装成 FutureTask，其 run() 方法内部已用 try-catch 捕获所有异常，并调用 setException(e) 存入对象。异常不会传播出去，也不会触发任何全局处理器。
- 必须显式调用
future.get()才能触发异常抛出，且会被包装为ExecutionException - 捕获
ExecutionException后，需用getCause()获取原始异常，再做日志和降级处理 - 切忌忽略返回的
Future——不 get、不 cancel、不 isDone，异常就永远沉底
统一兜底：代理封装 + AOP 建议
靠每个任务手动 try-catch 或每个 future 都 get，容易遗漏。更可靠的方式是在任务入口层统一拦截。
立即学习“Java免费学习笔记（深入）”；
- 编写通用任务包装器，如
SafeRunnable/SafeCallable，内部包裹业务逻辑并集中处理异常 - 结合 Spring 的
@Async时，可通过 AOP 切入所有异步方法，在环绕通知中捕获异常并上报 - 若使用自定义
ThreadPoolExecutor，可覆盖beforeExecute和afterExecute，实现执行前准备与执行后清理+异常归因
监控与验证不可少
再完善的机制也需要可观测性支撑。仅靠日志还不够，要让异常真正“可见、可追溯、可响应”。
- 将异常类型、任务标识、线程池名、堆栈摘要等打点上报至监控系统（如 Prometheus + Grafana + AlertManager）
- 定期抽查线程池活跃度、拒绝数、异常任务比例，设置阈值告警
- 用单元测试模拟异常场景，验证日志是否记录、告警是否触发、线程是否复用
