threaddeath 是 thread.stop() 主动抛出的 error，非系统崩溃，但会破坏线程状态、跳过 finally、导致资源泄漏和锁不一致；stop() 已废弃，应改用 interrupt() + 响应式退出机制。
ThreadDeath 是个被抛出来的异常，不是系统崩溃
ThreadDeath 是 java.lang.Error 的子类，但它和 OutOfMemoryError 这类真正“出事了”的错误不同——它本质是 stop() 方法主动往目标线程里扔的一个信号。JVM 不阻止它，但也不鼓励你 catch 它，因为一旦发生，线程栈已经处于不可预测状态。
常见错误现象：ThreadDeath 出现在日志里却没堆栈、线程突然消失但没执行 finally、资源没释放（比如文件句柄泄漏）、catch (Throwable t) 里意外吞掉了它。
- 别用
try-catch捕获ThreadDeath做“优雅退出”——它不保证当前方法能执行完，finally都可能被跳过 - 如果真在日志里看到
ThreadDeath，说明代码里或依赖库中调用了Thread.stop()，得立刻定位并删掉 - 它不会触发
UncaughtExceptionHandler，所以常规异常监控工具可能完全漏报
stop() 方法为什么被废弃：不只是“不安全”，而是根本不可控
Java 1.2 就把 Thread.stop() 标为 @Deprecated，不是因为它偶尔出错，而是它的行为在任何场景下都无法推理。它不关心线程正在执行什么，直接在任意字节码指令中间插一刀。
使用场景其实只有一个：老项目里有人图省事，想强行中断一个卡死的 IO 或死循环线程。但现实是，这种“省事”换来的是更难复现的内存损坏、锁状态错乱、对象引用半更新等问题。
立即学习“Java免费学习笔记（深入）”；
-
stop()会释放目标线程已持有的所有 monitor 锁，这会导致synchronized块保护的数据结构处于中间态（比如链表指针只改了一半） - 它对
Lock（如ReentrantLock）完全无效——既不释放也不通知，造成永久死锁 - 即使线程正在执行 native 方法（如
FileInputStream.read()），stop()也会强行中断，底层资源（如 OS 文件句柄）可能无法清理
替代方案不是“换一个 API”，而是重构协作逻辑
没有 stop() 后，必须让线程自己决定何时退出。这不是加个 flag 就完事，关键在于“如何让线程及时感知并安全收尾”。
参数差异：过去传一个 Thread 对象调 stop()；现在要设计可响应的取消机制，比如 volatile boolean running、AtomicBoolean cancelled、或标准的 Thread.interrupt() + 检查点。
- 对计算密集型任务：每轮循环检查
Thread.currentThread().isInterrupted()，避免 long-running loop 无视中断 - 对阻塞 IO（如
SocketInputStream.read()）：interrupt()会触发IOException（含 "Interrupted" message），需捕获并退出 - 对
java.util.concurrent工具类（如ThreadPoolExecutor）：优先用shutdown()+awaitTermination()，而不是试图 stop 单个 worker 线程 - 别依赖
isAlive()判断是否“已停稳”——它返回 false 只代表线程 run() 返回了，不代表资源已释放完毕
容易被忽略的兼容性陷阱：第三方库可能还在用 stop()
有些老版本的工具库（尤其是 2010 年前的网络框架、序列化工具、测试 mock 库）内部悄悄调用 Thread.stop()。它们在 JDK 8 上还能跑，但在 JDK 17+ 的某些安全策略下可能直接抛 SecurityException，或者静默失败。
性能影响不大，但行为一致性彻底丧失：同一段代码，在不同 JDK 版本/启动参数下，可能有时抛 ThreadDeath，有时卡住，有时直接 crash。
- 用
jstack -l <pid></pid>查看线程 dump，留意是否有java.lang.ThreadDeath出现在 stack trace 顶部 - 启动时加
-Djdk.lang.Process.allowExit=false类似参数没用，但可以加-XX:+PrintGCDetails辅助观察线程生命周期异常波动 - 最稳妥的办法：在测试环境开启
-Xverify:all（JDK 8）或升级到 JDK 17+ 后用--illegal-access=deny，逼出隐藏的 stop() 调用
真正麻烦的从来不是写几行替代代码，而是得去翻十年没动过的依赖源码，确认那个 Thread.stop() 是不是藏在某个 finally 块里，还打着“防止线程泄漏”的旗号。
