Java中stop()被废弃因会强制终止线程导致锁释放异常、资源泄漏等；应使用interrupt()配合volatile标志位或捕获InterruptedException实现协作式安全退出。
Java 中不能用 stop() 强制终止线程，因为它会无条件“掐断”正在运行的线程，不给清理机会；正确做法是用 interrupt() 配合标志位或异常处理，让线程自己决定何时、如何安全退出。
stop() 为什么被彻底废弃
它不是“暂停”或“通知”，而是直接杀死线程，带来一系列不可控后果：
- 已持有的
synchronized锁会被强制释放，其他线程可能看到对象处于中间状态，比如转账只扣了A的钱、没加B的账 -
ReentrantLock不会自动unlock()，导致锁永远无法释放，后续线程永久阻塞 -
finally块不会执行，资源（文件句柄、数据库连接、内存）可能泄漏 - 抛出的
ThreadDeath是Error类型，难以捕获和恢复，破坏程序稳定性
interrupt() 的真实作用是“发信号”，不是“下命令”
它只设置一个中断标志位，线程是否响应、何时响应、怎么响应，完全由你自己控制——这才是协作式终止的核心：
- 线程在
RUNNABLE状态时，调用interrupt()只会置位isInterrupted()，不打断执行 - 线程在
WAITING/TIMED_WAITING（如sleep()、wait()、join()）时，会立即被唤醒并抛出InterruptedException - 线程在
BLOCKED（等锁）或TERMINATED状态时，调用interrupt()仅设置标志位，无其他效果
推荐的两种安全退出方式
实际编码中，通常组合使用标志位与中断检测，兼顾及时性与可控性：
-
volatile 标志位 + 主动检查：适合计算密集型循环。定义
private static volatile boolean running = true;，在while(running)循环中定期检查，并在关键位置（如每次迭代末尾）判断Thread.currentThread().isInterrupted()，为真则break或return -
捕获 InterruptedException + 清理后退出：适合含阻塞调用的场景。把
sleep()、wait()等包在try-catch中，捕获后先执行finally或显式清理逻辑（如关闭流、释放锁），再退出run()
常见误区提醒
有些写法看似用了 interrupt()，实则无效：
- 只调用
interrupt()却不检查标志位或不处理异常 → 线程继续跑 - 在
catch(InterruptedException)中仅打印日志，没重设中断状态（Thread.currentThread().interrupt()）→ 后续代码无法感知中断 - 用普通
boolean而非volatile修饰标志位 → 主线程改了，工作线程可能永远看不到更新
