Java中stop()方法被废弃，因其强行中断线程导致锁异常释放、资源泄漏和状态不一致；应采用volatile标志位与interrupt()协作机制，定期检查中断状态并配合finally或shutdown逻辑安全退出。
Java 中的 stop() 方法被废弃，根本原因在于它会强行中断线程执行，不给线程任何收尾机会；而优雅停止线程的核心是“协作”——用 interrupt() 发信号，配合 volatile 标志位和合理异常处理，让线程自己决定何时安全退出。
stop() 为什么必须废弃
它不是通知，而是断电式强杀：
- 线程可能正持有
synchronized锁修改账户余额，stop()会强制释放锁，导致其他线程看到半更新状态（比如只扣了 A 的钱，B 没到账） - 不会执行
finally块，数据库连接、文件流、网络 Socket 很可能泄漏 - 抛出
ThreadDeath（一种Error），默认不被捕获，错误静默传播，系统状态难以追踪 - 在重入锁（如
ReentrantLock）场景下，锁计数未归零，后续线程永远无法获取该锁
用 volatile 标志位控制运行生命周期
这是最基础也最常用的协作方式，适合主逻辑在循环中反复执行的场景：
- 定义
private volatile boolean running = true;，volatile保证修改对所有线程立即可见 -
run()中用while (running)包裹主任务体 - 提供公开的
shutdown()方法，仅设running = false - 线程会在下次循环判断时自然退出，可在循环末尾或
finally中关闭资源
interrupt() 的真实作用与正确用法
interrupt() 不是命令，而是发一个可被检查的“停止请求”：
- 线程处于
RUNNABLE状态时：只设置中断状态位（isInterrupted() == true），不打断执行 - 线程处于
SLEEPING/WAITING/JOINING状态时：立即唤醒，并抛出InterruptedException - 在
catch块中，建议调用Thread.currentThread().interrupt()重置中断状态，再break或return - 若使用
BlockingQueue.take()、Selector.select()等支持中断的 API，中断会提前返回，需主动退出循环
组合使用才是完整方案
单靠标志位无法唤醒阻塞线程，单靠 interrupt() 无法覆盖非阻塞长循环。两者结合才健壮：
- 循环体中定期检查
Thread.interrupted()（会清中断位）或isInterrupted() - 阻塞调用外层包裹标志位判断 +
try-catch InterruptedException - 退出前统一做清理：关闭流、释放锁、记录日志、上报指标
- 避免在
catch中吞掉异常却不响应中断，那等于让中断失效
