13、过早的通知

等待通知机制

在前面介绍了等待通知机制，并使用该机制实现了消费者-生产者模式。我们知道，一个因为调用wait的线程会进入等待队列，当有其他的线程通知的时候才会从等待队列中返回，线程状态会变为RUNNABLE。但是，反过来说，如果一个线程从wait方法中返回，是不是就一定意味着线程等待的条件满足了呢？答案是否定的。考虑这样的场景：比如两个人的手机铃声是一样的（音量和类型），那么当两个手机同时响的时候，就不能正确判断哪个响的手机是自己的。而且线程从wait方法返回完成可能是意外导致的。

从线程的角度分析，每次调用wait方法的前提必然是首先获得了锁，然后会因为某个等待条件去调用wait方法，调用wait方法的时候会释放锁的持有。那么，当线程重新进入的调用wait方法的代码时，等待的条件就不一定满足了，那么继续往下执行就会出现错误的结果。比如，在执行notify通知的线程调用notify方法时，等待的条件是成立的，但是当线程重新获得锁的时候等待条件却是假的。出现这种情况的根源在于从调用notify进行唤醒并释放锁，到线程重新获取锁的这个时间内，如果有其他线程修改了等待条件，这种情况就出现了。

以上的现象称为“过早的通知”，为了更好理解这种现象，看看下面的代码就知道了：

package com.ddkk.patchwork.concurrency.r0414;

import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;

/**
 * DDKK.COM 弟弟快看，程序员编程资料站 16-4-14.
 */
public class EarlySignalDemo {
   
     

    //元素列表
    private List<String> list;
    //日期格式器
    private static final DateFormat format = new SimpleDateFormat("HH:mm:ss");
    //计数器
    private AtomicLong number = new AtomicLong();

    public EarlySignalDemo() {
        list = new ArrayList<>();
    }

    //对list执行删除的元素
    public void remove() throws InterruptedException {
        synchronized (list){
            if (list.isEmpty()){
                //只要list为空，那么调用此方法的线程必须等待
                list.wait();
            }
            //如果执行到这里，说明list已经不为空了
            //这样执行元素的删除操作才不会出错
            String item = list.remove(0);
            System.out.println(Thread.currentThread().getName() + ": remove element " + item + "! "
                + format.format(new Date()));
        }
    }

    //对list执行添加操作
    public void add(){
        synchronized (list){
            //添加元素不要进行判断
            list.add(""+ number.incrementAndGet());
            System.out.println(Thread.currentThread().getName() + ": add item " + number.get()
                + " " +format.format(new Date()));
            list.notifyAll();
        }
    }

    static class AddThread implements Runnable{
        private EarlySignalDemo es;

        public AddThread(EarlySignalDemo es) {
            this.es = es;
        }

        @Override
        public void run() {
            try {
                TimeUnit.MILLISECONDS.sleep(600);
                es.add();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

    static class RemoveThread implements Runnable{
        private EarlySignalDemo es;

        public RemoveThread(EarlySignalDemo es) {
            this.es = es;
        }

        @Override
        public void run() {
            try {
                TimeUnit.MILLISECONDS.sleep(100);
                es.remove();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

    public static void main(String[] args){
        EarlySignalDemo es = new EarlySignalDemo();
        for (int i = 0; i < 3; i++){
            new Thread(new RemoveThread(es),"RemoveThread" + i).start();
        }
        new Thread(new AddThread(es),"AddThread").start();
    }
}

运行的结果如下：

程序出现了数组下标越界的错误，简单计算一下，3个RemoveThread的等待时间之和是300毫秒，而AddThread需要600毫秒之后才会执行，所以在600毫秒之前，所有的RemoveThread都因为等待条件list为空陷入等待，进入等待队列中。当执行到600毫秒的时候，唤醒全部的RemoveThread，从wait返回的RemoveThread不会重新判断list的等待条件，这样造成的后果就是三个RemoveThread同时删除list中的一个元素，自然就会出现下标越界错误了。也正是3个RemoveThread在被唤醒到重新获得锁的期间等待条件被修改了，导致出现了错误的结果。

更正的办法就是把remove方法中对list是否为空的判断改为while循环就可以了。

小结
当使用条件等待时，往往需要对等待条件进行循环测试，避免过早的通知。