在锁与监视器中有对wait和notify以及notifyAll进行了简单介绍
所有对象都有一个与之关联的锁与监视器
wait和notify以及notifyAll之所以是Object的方法就是因为任何一个对象都可以当做锁对象（锁对象也是一种临界资源）
而等待与唤醒本身就是指的临界资源
等待，等待什么？等待获取临界资源
唤醒，唤醒什么？唤醒等待临界资源的线程
所以说，等也好，唤醒也罢，都离不开临界资源，而那个作为锁的Object，就是临界资源
这也是为什么必须在同步方法（同步代码块）中使用wait和notify、notifyAll，因为他们必须持有临界资源（锁）的监视器，只有持有了指定锁的监视器，才能够进行相关操作，而且，必须是持有的哪个锁，才能够在这个锁（临界资源）上进行操作
这个也很容易接受与理解，因为线程的通信在Java中是针对监视器（锁、临界资源）的，在监视器上的等待与唤醒
你都没持有监视器，你还搞什么？你持有的A监视器，你在B监视器上搞什么？
原文地址:多线程协作wait、notify、notifyAll方法简介理解使用 多线程中篇（十四）
线程通信
wait与notify示例
下面的代码示例中，MessageQueue类，有内部有LinkedList，可以用于保存消息，消息为Message
MessageQueue内部个数默认10，可以通过构造函数进行手动设置
提供了生产方法set和获取方法get
如果队列已满，等待，否则生产消息，并且通知消费者获取消息
如果队列已空，等待，否则消费消息，并且通知生产者生产消息
在测试类中开辟两个线程，一个用于生产，一个用于消费（无限循环执行）
package test1;import java.util.LinkedList;/*** 消息队列MessageQueue 测试*/public class T13 {public static void main(String[] args) {final MessageQueue mq = new MessageQueue(3);
System.out.println("***************task begin***************");//创建生产者线程并启动new Thread(() -> {while (true) {
mq.set(new Message());
}
}, "producer").start();//创建消费者线程并启动new Thread(() -> {while (true) {
mq.get();
}
}, "consumer").start();
}
}/*** 消息队列*/class MessageQueue {/*** 队列最大值*/private final int max;/** 锁
* */private final byte[] lock = new byte[1];/*** final确保发布安全*/final LinkedList<Message> messageQueue = new LinkedList<>();/*** 构造函数默认队列大小为10*/public MessageQueue() {
max = 10;
}/*** 构造函数设置队列大小*/public MessageQueue(int x) {
max = x;
}public void set(Message message) {synchronized (lock) {//如果已经大于队列个数，队列满，进入等待if (messageQueue.size() > max) {try {
System.out.println(Thread.currentThread().getName() + " : queue is full ,waiting...");
lock.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}//如果队列未满，生产消息，随后通知lock上的等待线程//每一次的消息生产，都会通知消费者System.out.println(Thread.currentThread().getName() + " : add a message");
messageQueue.addLast(message);
lock.notify();
}
}public void get() {synchronized (lock) {//如果队列为空，进入等待，无法获取消息if (messageQueue.isEmpty()) {try {
System.out.println(Thread.currentThread().getName() + " : queue is empty ,waiting...");
lock.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}//队列非空时，读取消息，随后通知lock上的等待线程//每一次的消息读取，都会通知生产者System.out.println(Thread.currentThread().getName() + " : get a message");
messageQueue.removeFirst();
lock.notify();
}
}
}/*** 消息队列中存储的消息*/class Message {
}
ps：判断条件 if (messageQueue.size() > max) 所以实际队列空间为4
从以上代码示例中可以看得出来，借助于锁lock，实现了生产者和消费者之间的通信与互斥
他们都是基于这个临界资源进行管理的，这个锁就相当于调度的中心，进入了监视器之后如果条件满足，那么执行，并且会通知其他线程，如果不满足则会等待。
从这个例子中应该可以理解，锁与监视器 和 线程通信之间的关系
wait方法
有三个版本的wait方法，wait，表示在等待此锁（等待持有这个锁对象对应的监视器）
对于无参数的wait以及双参数的wait，可以查看源代码，核心为这个native方法
wait（）直接调用wait（0）；
wait(long timeout, int nanos)在参数有效性校验后调用wait(timeout)
深入看下native方法
API解释：
在其他线程调用此对象的 notify() 方法或 notifyAll() 方法，或者超过指定的时间量前，导致当前线程等待。
如前面所述，wait以及notify以及notifyAll都需要持有监视器才可以调用该方法
既然另外两个版本都是依赖底层的这个wait，所以所有版本的wait都需要持有监视器
一旦该方法调用，将会进入该监视器的等待集，并且放弃同步要求（也就是不再持有锁，将会释放锁）
一定注意：将会释放锁，将会释放锁，会释放锁......
除非遇到上面的这几种情况，否则将会线程被禁用，进入休眠状态，也就是持续等待
遇到这几种情况后，将会从对象的等待集中删除线程，并重新进行线程调度
需要注意的是从等待集中删除并不意味着立马执行，他仍旧需要与其他线程竞争，如果竞争失败，也会继续等待
如果一个线程在不止一个锁对象的等待集内，那么将只是解除当前这个锁对象等待集中解锁，在其他等待集中仍旧是锁定的，如果你在多个等待集合中，总不能一下子就从所有的等待集合中释放，对吧
如果在等待时，任何其他的线程中断了该线程，那么将会收到一个异常，InterruptedException
另外如果没有持有当前监视器，将会抛出异常，IllegalMonitorStateException
小结：
对于native方法wait，将会等待指定的时长，如果wait（0）,将会持续等待
无参数的wait（）就是持续等待
双参数版本的就是等待一定的时长
wait的虚假唤醒
在没有被通知、中断或超时的情况下，线程也可能被唤醒，这被称之为虚假唤醒 (spurious wakeup）
也就是说你没有让他醒来（通知、中断、超时），这完全是超出你意料的，自己就莫名的醒了
尽管这种事情发生的概率很小，但是还是应该注意防范
如何防范？
比如我们上面的生产者方法
public void set(Message message) {synchronized (lock) {//如果已经大于队列个数，队列满，进入等待if (messageQueue.size() > max) {try {
System.out.println(Thread.currentThread().getName() + " : queue is full ,waiting...");
lock.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}//如果队列未满，生产消息，随后通知lock上的等待线程//每一次的消息生产，都会通知消费者System.out.println(Thread.currentThread().getName() + " : add a message");
messageQueue.addLast(message);
lock.notify();
}
}
生产者方法中，我们使用if对条件进行判断
if (messageQueue.size() > max)
一旦出现虚假唤醒，那么将会从wait方法后面继续执行，也就是下面的
messageQueue.addLast(message);
lock.notify();
很显然，虚假唤醒的时候，条件很可能是仍旧不满足的，继续生产，岂不出错？
所以我们应该唤醒后再次的进行条件判断，如何进行？
可以把if条件判断换成while条件测试，这样即使唤醒了也会再次的确认是否条件满足，如果不满足那么肯定会继续进入等待，而不会继续往下执行
小结：
我们应该总是使用循环测试条件来确保条件的确满足，避免小概率发生的虚假唤醒问题
notify方法
notify也是一个本地方法，他将会唤醒在该监视器上等待的某个线程（关键词：当前监视器、某一个线程）
即使在该监视器上有多个线程正在等待，那么也是仅仅唤醒一个
而且，选择是任意的
另外还需要注意，是这边notify之后，那么立刻就有什么反应了吗？不是的！
只有当前持有监视器的线程执行结束，才有机会执行被唤醒的线程，而且被唤醒的线程仍旧需要参与竞争（如果入口集中还有线程在等待的话）
所以，如果一个1000行的方法，不管你在哪一行执行notify，终归是要方法结束后，被唤醒的线程才有机会
notify问题
notify仅仅唤醒其中一个线程，而且，这种机制是非公平的，也就是说不能够保障每个线程必然都有机会获得执行。
换个说法，比如10个小朋友等待老师发糖果，如果每次都随机选一个，可能有的小朋友一直都得不到糖果
这就会发生线程的饥饿
怎么解决？
我们还有notifyAll方法，与notify功能相同，但是差别在于将会唤醒所有等待线程，这样所有的等待集合都获得了一次重生的机会，当然，如果条件不满足可能继续进入等待集，如果没有竞争成功也会在入口集等待
通过notifyAll可以确保没有人会饿到
notifyAll方法
这也是一个本地方法，看得出来，不管等待还是通知，最终仍旧需要借助于JVM底层。通过操作系统来实现
notifyAll唤醒在此对象监视器上等待的所有线程
与notify除了唤醒线程个数区别外，无任何区别，仍旧是执行结束后，被唤醒的线程才有机会
多线程通信
借助于wait与notify可以完成线程间的通信，可以借助于wait和notifyAll完成多线程之间的通信
其实对于我们最上面的代码示例中，不仅仅虚假唤醒会出现问题，非虚假唤醒场景下也可能出现问题
在只有一个生产者和消费者时并不会出现问题，但是如果在更多线程场景下，就可能出现问题
比如，两个生产者A，和B，一个消费者C，执行一段时间后，假设此时队列已满
如果A执行时，发现已满，进入等待
然后B线程执行，仍旧是已满，进入等待
然后C线程开始执行，消费了一个消息后，调用notify，此时碰巧唤醒了线程A
线程C执行后，线程A竞争成功，进入同步区域执行，线程A生产了一个消息，然后调用notify
不巧的是，此时唤醒的是线程B，线程B醒来以后竞争成功，继续执行，于是继续往队列中添加，也就是调用addLast方法
很显然，出问题了，出现了已满但是仍旧调用addLast方法
这种场景下，问题出现在唤醒了一个线程后，其实条件仍旧不满足，比如上面的描述中，应该唤醒消费者，但是生产者却被唤醒了，而且此时条件并不满足
同样的道理，如果是队列已经空了，假设有两个消费者线程A，B，和一个生产者C
消费者A，发现空，wait
消费者B，发现空，wait
生产者C，生产一个消息，notify，唤醒A
A醒来后竞争成功，消费一个消息后，notify，唤醒了B
B醒来后竞争成功，将会继续消费消息，出现已经空了，但是仍旧会调用removeFirst方法
从结果看，跟虚假唤醒是类似的---醒来时，条件仍旧不满足
所以解决方法就是将if条件判断修改为while条件检测
从这一点也可以看得出来，我们应该总是使用while对条件进行检测，不仅可以避免虚假唤醒，也能够避免更多线程并发时的同步问题
如果我们使用了while进行条件检测
假如说有10个生产者，队列大小为5，一个消费者
碰巧刚开始是10个生产者运行，接着队列已满，10个线程都进入wait状态
碰巧接下来是消费者不断消费，持续消费了5个消息，唤醒了其中5个生产者，然后进入wait
如果接下来是这五个生产者唤醒的线程都是刚才进入wait的生产者，会发生什么？
最终所有的生产者都将进入wait状态！而那个消费者也仍旧是wait！所有的人都在wait，谁来解锁？
这其中的一个问题就是我们不知道notify将会唤醒哪个线程，有些场景将会导致消费者永远无法获得执行的机会
所以应该使用notifyAll，这样将保障消费者始终有机会执行，哪怕暂时没机会执行，他仍旧是醒着的，只要她醒着就有机会让整个车间动起来
如下图所示，将原来的MessageQueue中的重构为RefactorMessageQueue，其实仅仅修改if为while
测试方法中，队列设置为5（代码中使用>判断，所以实际是6），生产者设置为20个，可以看到很快就死锁了，并且给线程设置名称
***************task begin***************
producer0 : add a message
producer0 : add a message
producer0 : add a message
producer0 : add a message
producer0 : add a message
producer0 : add a message
producer0 : queue is full ,waiting...
producer1 : queue is full ,waiting...
producer2 : queue is full ,waiting...
producer3 : queue is full ,waiting...
producer4 : queue is full ,waiting...
producer5 : queue is full ,waiting...
producer6 : queue is full ,waiting...
producer7 : queue is full ,waiting...
producer8 : queue is full ,waiting...
producer9 : queue is full ,waiting...
producer10 : queue is full ,waiting...
producer11 : queue is full ,waiting...
producer12 : queue is full ,waiting...
producer13 : queue is full ,waiting...
producer14 : queue is full ,waiting...
producer15 : queue is full ,waiting...
producer16 : queue is full ,waiting...
producer17 : queue is full ,waiting...
producer18 : queue is full ,waiting...
producer19 : queue is full ,waiting...
consumer : get a message
consumer : get a message
consumer : get a message
consumer : get a message
consumer : get a message
consumer : get a message
consumer : queue is empty ,waiting...
producer0 : add a message
producer0 : add a message
producer0 : add a message
producer0 : add a message
producer0 : add a message
producer0 : add a message
producer0 : queue is full ,waiting...
producer6 : queue is full ,waiting...
producer11 : queue is full ,waiting...
producer10 : queue is full ,waiting...
producer9 : queue is full ,waiting...
producer8 : queue is full ,waiting...
producer7 : queue is full ,waiting...
producer5 : queue is full ,waiting...
producer4 : queue is full ,waiting...
producer3 : queue is full ,waiting...
producer2 : queue is full ,waiting...
producer1 : queue is full ,waiting...
关键部分，如下图，消费者wait后，紧接着生产者满了，然后就纷纷wait
可以通过Jconsole工具查看
这是官方提供的工具，本地安装配置过JDK后，可以命令行直接输入：jconsole即可，然后会打开一个界面窗口
命令行输入jconsole
选择进程，连接
点击线程查看
逐个查看一下每个线程的状态，你会发现，我们的20个生产者producerX（0-19）以及一个消费者consumer，全部都是：状态: [B@2368a10b上的WAITING
小结：
多线程场景下，应该总是使用while进行循环条件检测，并且总是使用notifyAll，而不是notify，以避免出现奇怪的线程问题
总结
wait、notify、notifyAll方法，都需要持有监视器才能够进行操作，而进入监视器也就是需要在synchronized方法或者代码块内，或者借助于显式锁同步的代码块内
wait的方法签名中，可以看到将会可能抛出InterruptedException，说明wait是一个可中断的方法，当其他线程对他进行中断后（调用interrupt方法）将会抛出异常，并且中断状态将会被擦除，被中断后，该线程相当于被唤醒了
鉴于notify场景下的种种问题，我们应该尽可能的使用notifyAll
作者：noteless
共同学习，写下你的评论
评论加载中...
作者其他优质文章
