上一篇
va中可通过
Thread.sleep()、
yield()、
join()或
wait()方法暂停线程，具体选择取决于场景需求
Java中，线程的暂停是一个常见需求，通常用于控制任务执行节奏、协调多线程协作或响应外部事件,以下是几种实现线程暂停的核心方法及其详细解析：
| 方法名称 | 所属类/接口 | 作用机制 | 典型应用场景 | 注意事项 |
|---|---|---|---|---|
Thread.sleep() |
java.lang.Thread |
使当前线程进入阻塞状态指定时间（毫秒级），到期自动唤醒并回到就绪队列 | 定时延迟、模拟加载动画 | 可能抛出InterruptedException；唤醒后需重新竞争CPU资源 |
Thread.yield() |
java.lang.Thread |
提示调度器愿意让出CPU使用权，但仅建议性操作，不保证立即切换 | 优化性能、礼让式调度 | 实际效果依赖JVM实现和系统负载；无法精确控制暂停时长 |
Object.wait() |
java.lang.Object |
在同步块内调用时释放锁并进入等待集，必须由其他线程通过notify()/notifyAll()唤醒 |
线程间通信、条件触发逻辑 | 必须在synchronized块中使用；单独使用会导致永久挂起 |
Condition.await() |
java.util.concurrent.locks |
配合显式锁实现更灵活的等待/通知机制，支持超时预设 | 高级并发控制、复杂同步场景 | 需手动管理锁的获取与释放；避免忘记解锁导致死锁 |
volatile变量控制 |
通过共享变量的状态变化驱动线程行为 | 轻量级标志位管理 | 依赖主内存可见性保障；适用于简单开关型控制 |
实现方式详解
Thread.sleep(long millis)
这是最直接的方式,强制当前线程休眠指定毫秒数。
try {
Thread.sleep(1000); // 暂停1秒
} catch (InterruptedException e) {
// 处理中断异常
}
- 特点：简单易用，适合固定时长的暂停需求，但存在两个关键问题：①若线程在睡眠期间被其他线程调用
interrupt()，会提前抛出InterruptedException；②苏醒后仍需与其他就绪线程竞争CPU资源,无法保证立即执行。 - 适用场景：如倒计时器、节流阀等需要精确计时的场景。
Thread.yield()
该方法向JVM提议当前线程自愿放弃CPU时间片：“我暂时让一下别的线程先执行”。
- 它只是暗示性的提示,最终是否切换取决于操作系统调度策略；
- 在低负载环境下可能完全无效；
- 常用于调试或性能调优时的微观让步。
示例代码：for (int i = 0; i < 5; i++) { System.out.println("Before yield"); Thread.yield(); // 可能切换至其他线程 System.out.println("After yield"); }由于其不确定性,生产环境中慎用此方法进行关键流程控制。
Object.wait()系列方法
当需要在满足特定条件前阻塞线程时,应采用这种经典模式：
synchronized (obj) {
while (!conditionMet) {
obj.wait(); // 释放锁并等待唤醒
}
// 恢复执行
}
配套的唤醒操作有两种形式：
obj.notifyOne()：随机选择一个等待线程激活；obj.notifyAll()：唤醒所有等待同一监视器的线程。
特别注意：- 必须先获得对象的监视器锁才能调用
wait()； - 必须在循环中检查条件而非单次判断，防止虚假唤醒（spurious wakeup）；
- 与
sleep不同，wait不会自动超时,需自行设计退出策略。
Lock+Condition替代方案
Java 5引入的显式锁框架提供了更强大的控制能力：
Lock lock = new ReentrantLock();
Condition condition = lock.newCondition();
// 等待方
lock.lock();
try {
condition.await(); // 可传入超时参数实现备选方案
} finally {
lock.unlock();
}
// 唤醒方
lock.lock();
try {
condition.signalAll();
} finally {
lock.unlock();
}
相比内置锁的优势包括：
- 支持公平性策略设置；
- 可插拔式的多种Condition实现；
- 避免语言层面的synchronized限制。
但同时也增加了编码复杂度,需严格遵循锁释放规范。
Volatile标志位控制
对于简单的启停需求,可以使用具有内存屏障特性的volatile变量：
private volatile boolean running = true;
public void stopRunning() {
running = false; // 写操作立即对其他线程可见
}
public void run() {
while (running) {
// 执行任务...
}
}
这种方式的优点在于轻量化和低开销，但由于缺乏原子性保证，不适合复杂状态管理，当暂停逻辑涉及多个步骤时,建议改用原子类或其他并发工具。
过时方法警示
早期JDK曾提供过suspend()/resume()配对方法,但这些API存在严重缺陷：
- 如果持有外部锁时被悬挂,恢复后永远无法重新获取该锁；
- 无法正常处理finally块中的资源清理；
- 容易导致死锁和数据不一致。
因此官方已明确标记为废弃（deprecated）,现代开发中应完全避免使用。
实践建议
- 优先选择标准库工具：尽可能使用
sleep,wait/notify,Lock+Condition这些经过充分验证的机制； - 处理好中断异常：特别是I/O密集型操作，应当捕获
InterruptedException并安全终止； - 避免忙等待：不要使用空循环不断检查状态,这会极大浪费CPU资源；
- 文档化线程生命周期：明确每个线程何时应该停止,防止幽灵进程残留；
- 测试边界条件：重点验证中断发生时的响应行为是否符合预期。
FAQs
Q1: 为什么不应该使用stop()方法来暂停线程？
A: 因为stop()会强行终止线程，可能导致以下问题：①未释放锁造成死锁；②数据结构处于不一致状态；③文件句柄等资源未正确关闭，它无法给线程机会进行清理工作，极易引发难以调试的程序错误，自Java 1.2起该方法已被标记为废弃。
Q2: 如何在多线程环境中安全地实现暂停/恢复功能？
A: 推荐采用双重确认机制：结合volatile布尔标志和wait/notify机制，例如设置paused变量控制运行状态，在等待期间调用wait()释放CPU资源，恢复时通过notifyAll()唤醒，同时确保所有临界区的访问都在同步块内完成
