如何在Java中挂起和恢复线程_为什么suspend和resume方法会被弃用

夏婷酱_3180

发布时间：2026-03-15 03:01:14

990人浏览过

来源于php中文网

原创

Thread.suspend()和resume()因无条件挂起且不释放锁，极易导致死锁，故自JDK 1.2起被弃用；应改用volatile boolean配合wait/notify或LockSupport实现协作式暂停。

如何在java中挂起和恢复线程_为什么suspend和resume方法会被弃用

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() { /* ... */ }

}

Java注释规范Skills

当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。

下载

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 识别