JMM之Java线程间通讯——等待通知机制及其经典范式

　　在并发编程中，实际处理涉及两个关键问题：线程之间如何通信及线程之间如何同步（这里的线程是指并发执行的活动实体）。

　　通信是指线程之间以何种机制来交换信息。在共享内存的并发模型里，线程之间共享程序的公共状态，通过写-读内存中的公共状态进行隐式通信。

　　同步是指程序中用于控制不同线程间操作发生相对顺序的机制。在共享内存并发模型里，同步是显式进行的。开发人员必须显示指定某个方法或某段代码需要在线程之间互斥执行。

　Java的并发选择采用的就是共享内存模型JMM，即隐式通讯显式同步。

　　　　

　　在如何在两个线程之间共享数据 - 池塘里洗澡的鸭子 - 博客园 (cnblogs.com)中通过案例浅析了Java线程之间如何实现共享数据的两种方式，同时通过测试结果也可以知道线程之间的执行相对顺序是随机的，需要开发人员进行有效的同步控制。Java中对多线程执行顺序控制利用等待/通知也称为阻塞/唤醒机制实现。

　　等待/通知的相关方法是任意Java对象都具备的，因为这些方法被定义在所有对象的超类java.lang.Object上：
　　　　

　　等待/通知机制，是指一个线程A调用了对象O的wait()方法进入等待状态，而另一个线程B调用了对象O的notify()或者notifyAll()方法，线程A收到通知后从对象O的wait()方法返回，进而执行后续操作。上述两个线程通过对象O来完成交互，而对象上的wait()和notify/notifyAll()的关系就如同开关信号一样，用来完成等待方和通知方之间的交互工作。

　　先看单线程使用该机制：通过实践结果看，生成一个消费一个。

　　

　　再看多线程：

　　　　

　　再执行一次：

　　　　

　　多线程每次执行的结果似乎都不一样，也不是先生产后消费。wait和notify在此多线程应用不失效了？！从通知等待机制来分析，多线程的案例中6个线程分两组分别调用了对象myQueue中的wait()和notify()，相互通讯不应该出现失效的情况，为什么还是会出现消费者线程没有等到生产者的通知已生产完毕再进行消费的情况？

　　分析源代码，通知等待机制哪里失控了？首先分析消费者线程：

　　　　

　　从源码看：消费者线程根据随机数获取消息队列中的数据。同时消息队列长度为0时wait()，除此以外都是根据随机数取数据。失控的点就在此处：如果消息队列长度不为0，比如说其长度为2，同时随机数为3，那么消费者线程取队列中的第4个数据——可想而知是没有任何元素在此处的。

　　综合上述，多线程并发如果只是有关键字synchronized，wait()，notify()等方法并不能完全保证业务逻辑的正确性即有效同步。怎么解决这个问题呢？还需要合理的业务逻辑：

　　　　

　　以上可以得出一个小经验：提炼出等待/通知的经典范式——加锁，循环和处理逻辑，该范式分为两部分，分别针对等待方（消费者）和通知方（生产者）。

　　　　等待方遵循如下原则：

　　　　　　1）获取对象的锁。
　　　　　　2）如果条件不满足，那么调用对象的wait()方法，被通知后仍要检查条件。
　　　　　　3）条件满足则执行对应的逻辑。
　　　　　　对应的伪代码如下：
　　　　　　　　synchronized(对象) {
　　　　　　　　　　while(条件不满足) {
　　　　　　　　　　　　对象.wait();
　　　　　　　　　　}

　　　　　　　　　　对应的处理逻辑

　　　　　　　　}

　　　　通知方遵循如下原则：

　　　　　　1）获得对象的锁。
　　　　　　2）改变条件。
　　　　　　3）通知所有等待在对象上的线程。
　　　　　　对应的伪代码如下：
　　　　　　　　synchronized(对象) {
　　　　　　　　　　改变条件
　　　　　　　　　　对象.notifyAll();
　　　　　　　　}