Thread.stop() 被弃用是因为它强行注入 ThreadDeath 异常，破坏锁状态与对象一致性，导致中间态暴露和逻辑损坏；安全停止应依赖 volatile 标志与 interrupt() 协作退出。

Thread.stop() 被标记为 @Deprecated 不是因为它“不好用”，而是因为它会在任意字节码指令点强行注入 ThreadDeath 异常，直接破坏 JVM 对锁状态和对象一致性的基本保障。

Thread.stop() 会强制释放所有已持有的监视器锁

调用 stop() 后，JVM 不等待线程退出临界区，而是让 ThreadDeath 沿调用栈向上抛出，并在每一层自动释放 synchronized 块或方法所持有的监视器锁。这意味着：

• 线程可能刚执行完 balance -= 500，还没来得及执行 targetBalance += 500 就被终止
• 此时它持有的账户锁被强制释放，其他线程立刻能拿到锁并读到中间态的 balance
• 结果就是 A 账户扣了钱、B 账户没到账——对象处于逻辑上“损坏”（damaged）状态

ThreadDeath 异常无法被安全捕获和修复

虽然理论上可以在 catch (ThreadDeath) 中做清理，但实际不可行：

• ThreadDeath 是 Error 子类，普通 catch (Exception) 根本捕不到
• 即使显式 catch (ThreadDeath)，该异常可能在 finally 块里再次抛出，导致清理代码反复失败
• 你无法预判它会在哪个 synchronized 块内发生，也就无法提前设计原子边界

替代方案必须由线程自身协作退出

安全停止依赖线程主动检查退出信号，而非外部强杀：

• 用 volatile boolean running = true 控制循环条件，每次迭代前检查
• 若线程阻塞在 wait()、join() 或 sleep()，需配合 interrupt() 并捕获 InterruptedException
• 关键资源释放必须放在 finally 块中，且不能依赖 stop() 触发

真正危险的不是“线程停不下来”，而是它停下来的那一刻，可能正把一个半更新的对象暴露给整个并发世界——这种损坏不会立刻报错，而是在几小时甚至几天后某个偶然的读操作中悄然爆发。