不能直接调用 Thread.stop()，因其会立即终止线程导致资源未释放、状态不一致、死锁或数据损坏，且自Java 1.2起已被弃用；应使用 volatile boolean 标志位配合中断机制协作退出。
为什么不能直接调用 Thread.stop()
因为 Thread.stop() 会立即终止线程，不给它清理资源的机会，可能造成对象处于不一致状态、锁未释放、IO 流未关闭等问题。JDK 自 Java 1.2 起就已标记为 @Deprecated，实际调用会抛出 java.lang.UnsupportedOperationException（在某些 JVM 实现中）或引发难以复现的死锁和数据损坏。
推荐方式：用 volatile boolean 标志位协作退出
这是最常用、最可控的协作式终止方案。核心是让线程自己定期检查一个共享的、可被外部修改的标志位，决定是否继续运行。
-
volatile确保标志位的修改对所有线程可见，避免因 CPU 缓存导致子线程永远读不到新值 - 标志位应定义为
private volatile boolean running = true;，外部通过shutdown()方法设为false - 线程主逻辑必须在循环中检查该标志，且不能把耗时阻塞操作（如
Thread.sleep()、queue.take()）放在检查之外
public class WorkerThread extends Thread {
private volatile boolean running = true;
public void shutdown() {
running = false;
}
@Override
public void run() {
while (running) {
try {
// 执行任务
doWork();
Thread.sleep(100); // 模拟周期性工作
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
break;
}
}
cleanup(); // 正常退出前清理
}
private void doWork() { /* ... */ }
private void cleanup() { /* 关闭资源等 */ }}
遇到阻塞调用（如 Object.wait()、BlockingQueue.take()）怎么办
单纯靠标志位无法唤醒正在阻塞的线程。此时必须配合线程中断机制：
- 调用
thread.interrupt()可打断大多数阻塞方法，触发InterruptedException - 捕获
InterruptedException后，**必须恢复中断状态**（Thread.currentThread().interrupt()），否则上层代码可能误判“未被中断” - 若使用
BlockingQueue，优先选poll(timeout, unit)而非take()，以便定期检查标志位
例如：queue.poll(1, TimeUnit.SECONDS) 在超时后返回 null，此时可安全检查 running 并退出。
不要忽略 Thread.interrupted() 和 isInterrupted() 的区别
这两个方法都用于检测中断状态，但行为不同：
-
Thread.interrupted()是静态方法，**会清除当前线程的中断状态**，适合在循环开头做“一次性响应” -
thread.isInterrupted()是实例方法，**只读不改**，适合多次判断或与标志位组合使用 - 在
run()中频繁轮询时，用isInterrupted()更稳妥；若明确只响应一次中断（如优雅关闭），可用interrupted()
常见错误是只调用 interrupted() 却没处理后续逻辑，导致中断信号丢失；或者在 catch (InterruptedException) 后忘记恢复中断状态。
线程终止真正的难点不在语法，而在于“何时检查”“检查什么”“检查后做什么”。
finally 块或清理逻辑，比停不下来更危险。
