java线程停止需协作式中断：interrupt()仅设标志，线程须主动检查isinterrupted()或捕获interruptedexception并响应；禁用已废弃的stop()和suspend()方法。
Java 中线程不能被强制停止，interrupt() 只是设置一个中断标志，真正停止靠线程自己检查并响应。关键在于“协作”——不是命令线程停，而是通知它“该考虑退出了”，由线程在安全点决定如何收尾。
中断异常的正确捕获与处理
当线程在 sleep()、wait()、join() 等阻塞方法中被 interrupt() 调用时，会立即抛出 InterruptedException，同时中断状态被自动清除（设为 false）。
常见错误是只 catch 了异常却没做任何响应，导致线程继续运行，中断信号丢失。
- 在 catch 块中，如需保留中断语义（比如让上层代码感知中断），应手动调用 Thread.currentThread().interrupt() 恢复中断状态
- 如果当前方法就是线程的主逻辑终点（例如 run() 方法里无后续任务），可直接 return 或 break 退出循环
- 避免空 catch：写成 catch (InterruptedException e) { } 是危险的，等于忽略中断请求
非阻塞场景下的中断检测
线程大部分时间在执行计算或 I/O（非阻塞）时，不会自动响应 interrupt()，必须主动轮询中断状态。
推荐使用 this.isInterrupted()（实例方法），它返回当前线程中断状态且不改变标志位，适合循环条件判断。
- 示例：while (!this.isInterrupted() && !shouldStop) { /* 执行任务 */ }
- 避免用 Thread.interrupted()（静态方法）作循环条件，因为它每次调用都会清空中断标志，可能导致第二次检查永远为 false
- 若业务逻辑较长，应在关键节点（如每次循环迭代末尾）插入中断检查，防止响应延迟过久
结合标志位与中断的混合方案
纯中断机制对复杂业务不够直观；纯 volatile 标志又无法及时唤醒阻塞线程。两者结合更健壮。
- 定义 volatile boolean stopRequested = false，提供 public void stop() { stopRequested = true; } 方法供外部调用
- 在线程 run() 中，循环条件写成 while (!stopRequested && !Thread.currentThread().isInterrupted())
- 遇到阻塞调用（如 sleep）时，捕获 InterruptedException 后优先检查 stopRequested，再决定是恢复中断还是直接退出
- 退出前执行 cleanup()（关闭流、释放锁、提交事务等），确保资源不泄露
为什么 stop()、suspend() 绝对禁用
这些方法已被 JDK 明确废弃，不是“不推荐”，而是“不可用”。
- stop() 会立即终止线程并释放所有已持锁，可能让共享对象处于中间状态（如只更新了字段 A，B 还没改），引发数据错乱
- suspend() 不释放锁但挂起线程，极易造成死锁——其他线程等待它持有的锁，而它又不再运行
- 现代 JVM 不再支持这些操作，编译或运行时可能直接报错
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
