Thread.suspend()和resume()因无条件挂起且不释放锁，极易导致死锁，故自JDK 1.2起被弃用；应改用volatile boolean配合wait/notify或LockSupport实现协作式暂停。
Java里用 Thread.suspend() 和 Thread.resume() 会直接导致死锁
这两个方法在 JDK 1.2 就被标记为 @Deprecated，不是因为“过时”，而是因为它们根本无法安全使用。核心问题是：suspend() 是无条件挂起线程，不释放它已持有的任何锁；而一旦被挂起的线程正持有某个对象的监视器（比如刚进入 synchronized 块），其他线程就永远无法获取该锁——哪怕你立刻调用 resume()，只要恢复前有竞争，死锁就已发生。
常见错误现象：Thread.suspend() 后程序卡住、CPU 占用低但响应停滞、jstack 显示线程处于 WAITING (on object monitor) 却没在等待 notify；实际是它被强制停在 synchronized 内部，锁没放。
- 不要试图用
suspend()/resume()实现“暂停播放”“断点调试式控制”这类逻辑 - 它们在所有现代 JDK（8+）中仍存在，但调用时 JVM 不报错，只是埋下不可预测的并发隐患
- 即使你确认目标线程没拿锁，也无法保证它下一毫秒不会进 synchronized 或调用 native 方法（某些 native 调用内部也持锁）
替代方案：用 volatile boolean + wait/notify 或 LockSupport 实现协作式挂起
真正可控的方式，是让线程自己决定什么时候“暂停”，而不是被外部强行冻结。本质是把控制权交给线程内部，用状态变量 + 等待机制配合。
最轻量且兼容性最好的做法是 volatile boolean 配合 Object.wait()：
立即学习“Java免费学习笔记（深入）”；
public class PausableTask implements Runnable {
private final Object pauseLock = new Object();
private volatile boolean paused = false;
private volatile boolean running = true;
<pre class='brush:java;toolbar:false;'>@Override
public void run() {
while (running) {
// 执行任务逻辑
doWork();
// 检查是否需暂停
synchronized (pauseLock) {
while (paused) {
try {
pauseLock.wait(); // 主动释放锁并等待
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
return;
}
}
}
}
}
public void pause() {
paused = true;
}
public void resume() {
synchronized (pauseLock) {
paused = false;
pauseLock.notifyAll();
}
}
public void stop() {
running = false;
synchronized (pauseLock) {
pauseLock.notifyAll();
}
}
private void doWork() { /* ... */ }}
-
volatile保证paused变量修改对所有线程可见，避免指令重排序 -
wait()必须在synchronized块内调用，且会自动释放锁，这是安全挂起的关键 - 不能用
Thread.sleep()替代wait()，因为它不释放锁，起不到协作效果 - 如果需要更细粒度控制（比如只暂停某段计算），可把
while (paused)检查点嵌入到循环体内，而非只放在每轮末尾
为什么 LockSupport.park() 比 wait() 更适合底层调度
如果你在写线程池、协程封装或高性能调度器，LockSupport.park() 是比 wait() 更底层、更灵活的选择。它不依赖 synchronized，也不抛 InterruptedException（只响应 Thread.interrupt()），且能绑定许可（permit）实现无竞争唤醒。
但注意：park() 不自动释放任何锁，所以它本身不解决 suspend 的死锁问题——必须和协作式状态检查一起用：
private volatile boolean paused = false;
private final Thread owner;
<p>// 在 run() 中：
while (running) {
doWork();
if (paused) {
LockSupport.park(this); // 挂起，但不持锁
if (Thread.currentThread().isInterrupted()) break;
}
}</p><p>// 外部调用：
public void pause() {
paused = true;
}
public void resume() {
paused = false;
LockSupport.unpark(targetThread); // 注意：必须指定线程对象
}-
LockSupport是java.util.concurrent的基石，ReentrantLock、ForkJoinPool都基于它 -
park()不抛异常，但Thread.interrupted()会清中断状态，需小心判断 - 容易踩的坑：
unpark()提前调用（即先 unpark 后 park），会导致下次 park 直接返回——必须靠paused这类状态变量兜底，不能只信 permit - 别用
park(null)，调试时无法定位阻塞点；传入this或有意义对象便于 jstack 识别
JDK 9+ 的 Thread.stop() 同样被废弃，但原因不同
Thread.stop() 被弃用，不是因为死锁，而是因为它会**强行终止线程并释放所有锁**，造成对象状态不一致。比如线程正在执行 balance -= amount; balance += interest;，stop 发生在中间，账户余额就永久损坏。
这和 suspend/resume 的“不释放锁”形成镜像风险：一个锁不放，一个锁乱放。两者都被废弃，是因为它们都绕过了 Java 的同步契约，把并发安全交给了不可控的外部干预。
- 没有“安全强制终止线程”的 API，只有“协作式中断”：设置
interrupt()+ 线程内定期检查Thread.interrupted() - 所有 I/O、
wait()、park()等阻塞调用都会响应中断，但纯计算循环必须手动加检查点 - 别依赖
isAlive()判断线程是否“真停了”——它可能刚退出但还没完成资源清理，要用join()或 CountDownLatch 等显式同步
线程控制从来不是“按个暂停键”那么简单。关键不在怎么挂起，而在挂起时谁负责维护状态一致性——这个责任，只能由线程自己承担。
