ThreadDeath 是 JVM 内部强制终止线程的特殊错误，不可被 try-catch 或 UncaughtExceptionHandler 捕获；应禁用 Thread.stop()，改用 volatile 标志位、interrupt()、锁机制和 finally 清理保障安全。
ThreadDeath 是 JVM 内部抛出的特殊错误（Error 类型），由 Thread.stop() 强制终止线程时触发。它**不能也不应被常规的 try-catch 捕获或通过 UncaughtExceptionHandler 处理**——因为它的设计目的就是立即终止线程执行流，且 JVM 明确禁止应用层可靠拦截。因此，“用自定义线程工厂捕获 ThreadDeath”在语义和实践上均不可行，属于危险误区。
为什么 ThreadFactory + UncaughtExceptionHandler 对 ThreadDeath 无效
UncaughtExceptionHandler 只对未捕获的 Throwable 子类中非 ThreadDeath 的异常/错误 生效。查看 ThreadGroup.uncaughtException() 源码可知：
- JVM 在分发未捕获异常前，会显式排除
ThreadDeath（!(e instanceof ThreadDeath)）； - 即使你为线程设置了自定义 handler，JVM 也不会调用它处理 ThreadDeath；
- ThreadDeath 不是“异常”，而是线程生命周期的强制终结信号，不遵循正常异常传播链。
真正保障变量与任务安全的替代方案
放弃拦截 ThreadDeath，转而从源头杜绝其发生，并确保状态一致性：
-
彻底禁用 Thread.stop()：该方法自 JDK 1.2 起已被标记为 @Deprecated，且在现代 JDK（如 17+）中实际调用会直接抛出
UnsupportedOperationException； - 用 volatile 标志位 + interrupt() 协作退出：在任务逻辑中定期检查标志位或响应中断，主动退出循环，保证变量更新的原子性与可见性；
-
使用 synchronized 或 Lock 保护共享变量：若任务中修改全局计数器、缓存等，必须加锁或使用
AtomicInteger等线程安全类型，避免因线程突然终止导致中间态残留； - 将关键清理逻辑移至 finally 块或 try-with-resources：例如释放文件句柄、关闭连接等，确保无论是否中断都会执行。
线程池场景下的安全实践
在 Spring 或标准 ThreadPoolExecutor 中：
- 不要依赖线程工厂设置 handler 来“捕获 ThreadDeath”——它不会触发；
- 提交任务时优先用
submit(Runnable)并获取Future，后续调用get()可捕获业务异常（ExecutionException包装），但依然无法捕获 ThreadDeath； - 若需强制停止某个任务，调用
future.cancel(true)，它会尝试中断线程，此时你的run()方法应正确响应InterruptedException并退出； - 所有共享状态操作（如更新数据库记录、写入日志文件）建议封装在幂等事务或带重试机制的服务中，避免单次执行失败导致数据不一致。
ThreadDeath 不是待捕获的问题，而是需要规避的设计缺陷。真正的安全性来自协作式线程控制、状态保护机制和健壮的任务封装，而非试图拦截 JVM 底层终止信号。
