wait线程阻塞

介绍

线程阻塞通常是指一个线程在执行过程中由于某种原因从运行状态转为暂停状态的过程,线程阻塞会放弃CPU的使用权, 并且等待某个条件重新从暂停状态改为就绪状态。在Java中,通常使用object.wait让线程进入阻塞状态。

使用

首先我们先看wait方法,wait方法总共有三个重载方法,分别是 wait() wait(long timeout) wait(long timeout, int nanos),其中wait方法内部是调用了wait(0),顾名思义timeout就是超时时间,那么timeout等于0是什么意思呢,查看官方API如下:
这里写图片描述
意思就是如果timeout是0,不需考虑超时时间,即线程会无限等待直到被唤醒。
下面写一个demo,代码如下:

    public static void main(String args[]) {
        Thread thread = new Thread(new Runnable() {
            @Override
            public void run() {
                System.out.println( "执行线程中");
            }
        });
        thread.setName("MyThread");
        thread.start();
        
        try{
            thread.wait();
        }catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(thread.getName() + "已经执行结束");
    }

预想的输出结果应该是

执行线程中
MyThread已经执行结束

实际上报错了

Exception in thread "main" java.lang.IllegalMonitorStateException

查看wait的API介绍有这么一句标注 The current thread must own this object’s monitor.,大意就是执行wait方法的线程必须持有线程的对象锁,使用synchronized对thread对象加锁既可,代码如下:

        try{
            synchronized (thread) {
                thread.wait();
            }
        }catch (InterruptedException e) {
            e.printStackTrace();
        }

这样一来,通过synchronize既可获取线程的对象锁,就可以达到阻塞线程的作用了,有人可能会疑惑说为什么没有调用notify方法,这是因为当线程死亡之后,相应的wait方法也会失效。

当然对于线程的阻塞,通用使用线程的join方法,代码如下:

    public static void main(String args[]) {
        Thread thread1 = new Thread(new Runnable() {
            @Override
            public void run() {
                System.out.println( "执行线程1中");
            }
        });
        thread1.setName("MyThread -- 1");
        thread1.start();

        Thread thread2 = new Thread(new Runnable() {
            @Override
            public void run() {
                System.out.println( "执行线程2中");
            }
        });
        thread2.setName("MyThread -- 2");
        thread2.start();

        try{
            thread1.join();
            thread2.join();
        }catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(thread1.getName() + " " + thread2.getName()  + "  已经执行结束");
    }

通过调用join方法,就可以让线程阻塞,我们看一下join的方法实现:

    public final synchronized void join(long var1) throws InterruptedException {
        long var3 = System.currentTimeMillis();
        long var5 = 0L;
        if (var1 < 0L) {
            throw new IllegalArgumentException("timeout value is negative");
        } else {
            if (var1 == 0L) {
                while(this.isAlive()) {
                    this.wait(0L);
                }
            } else {
                while(this.isAlive()) {
                    long var7 = var1 - var5;
                    if (var7 <= 0L) {
                        break;
                    }

                    this.wait(var7);
                    var5 = System.currentTimeMillis() - var3;
                }
            }

        }
    }

其实就是当线程还存活时,调用wait方法。需要注意的是,join方法是synchronize的,因为需要获取对象锁。

参考

Wait方法的官方API介绍

<think>嗯,用户这次问的是关于notify线程是否会像wait线程一样阻塞。我需要先回顾一下条件变量和线程同步的基本概念。之前的对话已经讨论了wait方法带条件的情况,现在用户可能是在进一步理解通知机制。 首先,用户可能对notify的工作方式不太清楚,或者混淆了wait和notify的行为。需要明确,调用notify的线程是否会阻塞自己,这取决于具体的实现和锁的状态。比如,在C++中,notify_one或notify_all通常是在持有锁的情况下调用的,但通知操作本身不会阻塞线程。不过,释放锁之后,其他线程才能被唤醒。 接下来,用户可能没有意识到notify和锁的关系。当线程调用notify时,它可能仍然持有互斥锁,这时候被唤醒的wait线程需要重新获取锁才能继续执行。所以,notify的线程调用notify之后,如果释放了锁,那它本身并不会阻塞,而是继续执行后续代码。 另外,用户可能担心notify会不会导致通知线程挂起,或者需要等待被通知的线程执行完毕。这时候需要解释,notify只是一个信号机制,不会阻塞调用线程。而wait线程的唤醒和继续执行则依赖于锁的获取,这可能会影响它们的执行顺序,但通知线程本身不会被阻塞。 还需要考虑用户的实际应用场景。比如,是否在多线程环境中正确使用锁和条件变量,是否存在竞态条件或死锁的风险。用户可能在实际编码中遇到问题,比如通知丢失或线程未被及时唤醒,需要确保他们在调用notify时持有正确的锁,并且条件变量的使用符合规范。 最后,总结回答时要结构清晰,分点说明,确保用户理解notify的非阻塞特性,以及正确使用条件变量的要点。同时,给出示例代码和常见误区,帮助用户巩固理解,避免常见的错误。</think>--- ### **1. 核心结论** **不会**。调用`notify`(如`notify_one`或`notify_all`)的线程**不会因发送通知而阻塞**。它的行为是**非阻塞**的——通知发出后,线程会**立即继续执行后续代码**,无需等待被唤醒的`wait`线程完成操作。 --- ### **2. 详细机制分析** #### **(1)`notify`的本质** - **仅发送信号**:`notify`的作用是**唤醒正在`wait`的线程**(一个或全部),但它本身**不涉及任何等待或阻塞逻辑**。 - **无锁释放要求**:`notify`可以在**持有锁时调用**(通常建议如此,避免竞态条件),但即使不持有锁也能调用(尽管可能导致通知丢失)。 #### **(2)`wait`与`notify`的协作流程** 以典型的生产者-消费者模型为例: | 步骤 | 生产者线程(`notify`方) | 消费者线程(`wait`方) | |------|--------------------------|------------------------| | 1 | 获取锁(`lock`) | 获取锁(`lock`) | | 2 | 修改共享数据(如填充队列) | 检查条件(如队列是否为空)| | 3 | 调用`notify_one()` | 条件不满足,调用`wait()`进入阻塞 | | 4 | **释放锁**(`unlock`) | **释放锁**并阻塞,等待唤醒 | | 5 | **继续执行后续代码** | 被唤醒后重新获取锁,检查条件 | - **关键点**:生产者调用`notify_one()`后,立即释放锁并继续执行,**不等待消费者实际被唤醒或完成消费**。 --- ### **3. 示例场景** #### **生产者线程(通知方)** ```cpp std::mutex mtx; std::condition_variable cv; std::queue<int> data_queue; void producer() { std::unique_lock<std::mutex> lock(mtx); data_queue.push(42); // 修改共享数据 cv.notify_one(); // 发送通知(非阻塞) std::cout << "通知已发送,生产者继续执行..." << std::endl; // 锁在作用域结束时自动释放 } ``` #### **消费者线程(等待方)** ```cpp void consumer() { std::unique_lock<std::mutex> lock(mtx); cv.wait(lock, [&] { return !data_queue.empty(); }); // 等待队列非空 auto data = data_queue.front(); data_queue.pop(); std::cout << "消费者收到数据: " << data << std::endl; } ``` #### **输出结果** ``` 通知已发送,生产者继续执行... 消费者收到数据: 42 ``` - 生产者发送通知后**立即输出日志**,无需等待消费者完成操作。 --- ### **4. 潜在误区** #### **误区:`notify`需要等待`wait`线程完成** - **错误理解**:认为生产者调用`notify_one()`后,必须等待消费者处理完数据才能继续执行。 - **实际情况**:生产者发送通知后**立即继续执行**,消费者的唤醒和操作是**异步**的。若生产者后续仍需操作共享数据(如继续生产),需通过锁或其他机制保证同步。 #### **误区:`notify`必须在持有锁时调用** - **允许但不强制**:`notify`可以在无锁时调用,但通常建议**在持有锁时调用**,原因如下: 1. **避免通知丢失**:若先释放锁再调用`notify`,其他线程可能在间隙中修改条件,导致被唤醒的线程重新进入等待。 2. **保证原子性**:修改共享数据与发送通知的原子性,确保被唤醒的线程看到最新的状态。 --- ### **5. `notify`与`wait`的时序关系** - **通知可能“无效”**:若没有线程在`wait`时调用`notify`,通知会被**直接丢弃**(不会累积或延迟生效)。 - **虚假唤醒**:即使没有`notify`,`wait`也可能因系统原因被唤醒,因此必须通过**循环检查条件**来容错(例如C++中的`cv.wait(lock, predicate)`)。 --- ### **6. 总结** - **`notify`线程阻塞**:通知是异步的,发送后立即继续执行。 - **`wait`线程依赖锁**:被唤醒后需重新获取锁才能继续操作共享数据。 - **正确实践**:在持有锁时调用`notify`,并确保条件检查的原子性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值