线程池中单个线程崩溃不会导致整个池瘫痪，但会引发异常丢失、线程反复重建、监控盲区和资源泄漏；需通过统一异常处理器、Safe包装器及afterExecute钩子实现可捕获、可记录、可响应的容错机制。
线程池里某个线程意外崩溃，本身不会让整个池“瘫痪”，但会带来隐性风险：异常丢失、线程反复重建、监控盲区、资源缓慢泄漏。关键不是阻止崩溃，而是确保崩溃可捕获、可记录、可响应。
区分任务提交方式，应对不同异常路径
Java 中 execute() 和 submit() 对异常的处理机制完全不同，必须分开对待：
- execute() 提交 Runnable：异常未捕获 → 直接抛出到线程的默认异常处理器 → 当前线程终止 → 线程池自动新建线程补位（仅限允许创建新线程时）。但异常信息默认只打印到控制台，生产环境几乎不可见。
-
submit() 提交 Callable 或 Runnable：异常被封装进 Future 对象 → 不触发、不传播、不打印 → 直到调用
future.get()才抛出ExecutionException，包裹真实异常。若忘记 get，异常就永久沉没。
统一兜底：给每个线程装上“黑匣子”
靠每个任务手动 try-catch 容易遗漏，更可靠的方式是在线程层面设防：
- 自定义 ThreadFactory，为每个线程设置
UncaughtExceptionHandler - 在 handler 里做三件事：记录完整堆栈（含线程名）、上报监控系统（如 Prometheus + AlertManager）、触发告警（企业微信/钉钉）
- 避免直接吞掉异常或只打 System.err —— 这等于放弃可观测性
增强任务包装：让异常无处遁形
在提交任务前主动封装一层，把异常拦截在业务逻辑出口：
- 写一个通用的
SafeRunnable或SafeCallable包装器，内部自带 try-catch - catch 后统一做：日志落盘（带 traceId）、指标计数（如 task_failure_total）、降级返回（如缓存值或空响应）
- 特别注意
Throwable而不仅是Exception—— Error（如 OutOfMemoryError）也得被捕获并标记严重等级
善用线程池钩子：在执行前后埋点
继承 ThreadPoolExecutor，重写 afterExecute 方法：
- 该方法在每个任务执行结束后被调用，无论成功或异常
- 第二个参数
Throwable t就是任务抛出的异常（null 表示正常结束） - 在这里做统一归因：统计失败率、记录慢任务、关联上下文（如请求 ID）、触发熔断判断
