必须废弃 Thread.stop()，因其强制终止线程会破坏锁状态、跳过 finally、泄漏资源并导致原子性失效；应使用 volatile 标志位配合 interrupt() 实现协作式安全退出。

别用 Thread.stop()，这是 Java 多线程里一条铁律。它不是“暂停”，而是“断电式强杀”——不等锁释放、不走 finally、不写完数据，直接让线程从任意位置消失。这种终止方式早在 JDK 1.2 就被标记为 deprecated，至今未恢复，原因非常明确：它破坏程序状态的确定性。

stop() 为什么必须废弃

它的危险性不是理论推测，而是可复现的系统级风险：

• 强制释放所有已持锁，其他线程拿到锁时看到的是半更新对象（比如账户余额减了但未记账）
• 跳过 finally 块，文件流、数据库连接、网络 Socket 极大概率泄漏
• 抛出 ThreadDeath（一种 Error），默认不被捕获，错误可能静默传播
• 破坏原子操作语义，例如重入锁计数未归零，导致后续线程永远无法获取该锁

用 volatile 标志位实现协作式退出

核心是“线程自己决定何时停”，而不是被外部强行掐断。标志位必须声明为 volatile，确保修改对所有线程立即可见：

• 在 run() 中用 while(flag) 包裹主逻辑，定期检查
• 主线程调用 setFlag(false) 发出停止信号
• 若线程处于阻塞状态（如 sleep、wait、join），需配合 interrupt() 唤醒并捕获 InterruptedException

处理阻塞场景不能只靠标志位

单纯轮询 volatile 变量在线程长时间阻塞时无效。此时要结合中断机制：

• 在 catch InterruptedException 后主动退出循环，或重设中断状态
• 对支持中断的阻塞方法（如 BlockingQueue.take()、Thread.sleep()），中断会提前唤醒并抛异常
• 自定义阻塞逻辑中，应定期调用 Thread.interrupted() 检查中断状态

实际编码中的关键细节

安全终止不只是加个 flag，还要注意这些实践要点：

• 标志位变量建议用 private volatile boolean running = true，避免被意外修改
• 避免在 synchronized 块内长时间执行，否则标志位检查被延迟，响应不及时
• 资源清理代码统一放在 finally 或显式关闭逻辑中，不要依赖 stop() 的“自动释放”
• 测试时模拟高并发+随机中断时机，验证状态一致性与资源释放完整性