Java线程挂起与恢复方法为何被弃用

Java中已被弃用的`Thread.suspend()`和`resume()`方法看似提供了线程暂停与恢复的便捷接口，实则因无条件挂起且不释放锁而极易引发不可预测的死锁，其危险性远超“过时”范畴——哪怕目标线程当前未持锁，也无法规避它在毫秒级内进入同步块或调用隐式持锁的native方法的风险；真正安全可靠的替代方案是回归协作式控制：通过`volatile boolean`状态变量配合`wait/notify`或`LockSupport.park/unpark`，将暂停决策权交还线程自身，在关键检查点主动让出执行权并释放锁，从而在根本上保障并发状态的一致性与可预测性。

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()：

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); // 注意：必须指定线程对象
}</p>

• 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 等显式同步

线程控制从来不是“按个暂停键”那么简单。关键不在怎么挂起，而在挂起时谁负责维护状态一致性——这个责任，只能由线程自己承担。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。