Effective Java 第三版——81. 优先使用并发实用程序替代wait和notify

Tips
书中的源代码地址：https://github.com/jbloch/effective-java-3e-source-code
注意，书中的有些代码里方法是基于Java 9 API中的，因此JDK 最好下载 JDK 9以上的版本。

81. 优先使用并发实用程序替代wait和notify

本书的初版专门用一个条目来介绍正确使用wait和notify方法[Bloch01，Item 50]。 它的建议仍然有效，并在本条目末尾进行了总结，但这个建议远不如之前那么重要了。 这是由于没有太多理由再使用wait和notify了。 从Java 5开始，该平台提供了更高级别的并发实用程序，能够执行之前必须在wait和notify时手动编写代码的各类操做。 鉴于正确使用wait和notify的困难，应该使用更高级别的并发实用程序。

java.util.concurrent包中的高级实用程序分为三类：Executor Framework，在条目 80中简要介绍了它；并发集合（concurrent collections） 和同步器（synchronizers）。 本条目简要介绍后二者。

并发集合是标准集合接口（如List，Queue和Map）的高性能并发实现。 为了提供高并发性，这些实如今内部管理本身的同步（条目 79）。 所以，不可能从并发集合中排除并发活动; 锁定它只会使程序变慢。

由于不能排除并发集合上的并发活动，因此也不能以原子方式组合对它们的方法调用。 所以，并发集合接口配备了依赖于状态的修改操做，这些操做将几个基本操做组合成单个原子操做。 事实证实，这些操做对并发集合很是有用，它们使用默认方法（条目 21）添加到Java 8中相应的集合接口中。

例如，Map的putIfAbsent(key, value)方法插入键的映射（若是不存在）并返回与键关联的以前的值，若是没有则返回null。
这样能够轻松实现线程安全的规范化Map。 此方法模拟String.intern`方法的行为：

// Concurrent canonicalizing map atop ConcurrentMap - not optimal
private static final ConcurrentMap<String, String> map =
        new ConcurrentHashMap<>();

public static String intern(String s) {
    String previousValue = map.putIfAbsent(s, s);
    return previousValue == null ? s : previousValue;
}

事实上，你能够作得更好。ConcurrentHashMap针对get等检索操做进行了优化。所以，只有在get代表有必要时，才首先调用get并调用putIfAbsent方法:

// Concurrent canonicalizing map atop ConcurrentMap - faster!
public static String intern(String s) {
    String result = map.get(s);
    if (result == null) {
        result = map.putIfAbsent(s, s);
        if (result == null)
            result = s;
    }
    return result;
}

除了提供出色的并发性外，ConcurrentHashMap很是快。 在个人机器上，上面的intern方法比String.intern快6倍（但请记住，String.intern必须采用一些策略来防止在长期运行的应用程序中泄漏内存）。 并发集合使基于同步的集合在很大程度上已通过时了。 例如，使用ConcurrentHashMap优先于Collections.synchronizedMap。 简单地用并发Map替换同步Map以显着提升并发应用程序的性能。

一些集合接口使用阻塞操做进行扩展，这些操做等待（或阻塞）直到能够成功执行。 例如，BlockingQueue扩展了Queue并添加了几个方法，包括take，它从队列中删除并返回head元素，等待队列为空。 这容许阻塞队列用于工做队列（也称为生产者——消费者队列），一个或多个生产者线程将工做项入队，而且一个或多个消费者线程从哪一个队列变为可用时出队并处理项目。 正如所指望的那样，大多数ExecutorService实现（包括ThreadPoolExecutor）都使用BlockingQueue（条目 80）。

同步器是使线程可以彼此等待的对象，容许它们协调各自的活动。 最经常使用的同步器是CountDownLatch和Semaphore。 不太经常使用的是CyclicBarrier和Exchanger。 最强大的同步器是Phaser。

倒计时锁存器（CountDownLatch）是一次性使用的屏障，容许一个或多个线程等待一个或多个其余线程执行某些操做。 CountDownLatch的惟一构造方法接受一个int类型的参数，它是在容许全部等待的线程继续以前，必须在latch上调用countDown方法的次数。

在这个简单的原语上构建有用的东西很是容易。例如，假设想要构建一个简单的框架来为一个操做的并发执行计时。这个框架由一个方法组成，该方法使用一个执行器executor来执行操做，一个表示要并发执行的操做数量并发级别，以及一个表示该操做的runnable组成。全部工做线程都准备在计时器线程启动时钟以前运行操做。当最后一个工做线程准备好运行该操做时，计时器线程“发号施令（fires the starting gun）”，容许工做线程执行该操做。一旦最后一个工做线程完成该操做，计时器线程就中止计时。在wait和notify的基础上直接实现这种逻辑至少会有点麻烦，可是在CountDownLatch的基础上实现起来却很是简单:

// Simple framework for timing concurrent execution
public static long time(Executor executor, int concurrency,
            Runnable action) throws InterruptedException {
    CountDownLatch ready = new CountDownLatch(concurrency);
    CountDownLatch start = new CountDownLatch(1);
    CountDownLatch done  = new CountDownLatch(concurrency);

    for (int i = 0; i < concurrency; i++) {
        executor.execute(() -> {
            ready.countDown(); // Tell timer we're ready
            try {
                start.await(); // Wait till peers are ready
                action.run();
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            } finally {
                done.countDown();  // Tell timer we're done
            }
        });
    }
    ready.await();     // Wait for all workers to be ready
    long startNanos = System.nanoTime();
    start.countDown(); // And they're off!
    done.await();      // Wait for all workers to finish
    return System.nanoTime() - startNanos;
}

请注意，该方法使用三个倒计时锁存器。 第一个ready，由工做线程来告诉计时器线程什么时候准备就绪。 工做线程而后等待第二个锁存器，即start。 当最后一个工做线程调用ready.countDown时，计时器线程记录开始时间并调用start.countDown，容许全部工做线程继续。 而后，计时器线程等待第三个锁存器完成，直到最后一个工做线程完成运行并调用done.countDown。 一旦发生这种状况，计时器线程就会唤醒并记录结束时间。

还有一些细节值得注意。传递给time方法的executor必须容许建立至少与给定并发级别相同数量的线程，不然测试将永远不会结束。这被称为线程饥饿死锁（thread starvation deadlock）[Goetz06, 8.1.1]。若是工做线程捕捉到InterruptedException异常，它使用习惯用法thread.currentthread ().interrupt()从新断言中断，并从它的run方法返回。这容许执行程序按照它认为合适的方式处理中断。System.nanoTime用于计算活动的时间。**对于间隔计时，请始终使用System.nanoTime而不是System.currentTimeMillis。 System.nanoTime更准确，更精确，不受系统实时时钟调整的影响。最后，请注意，本例中的代码不会产生准确的计时，除非action作了至关多的工做，好比一秒钟或更长时间。准确的微基准测试是很是困难的，最好是借助诸如jmh [JMH]这样的专业框架来完成。

这个条目只涉及使用并发实用程序作一些皮毛的事情。 例如，前一个示例中的三个倒计时锁存器能够由单个CyclicBarrier或Phaser实例替换。 结果代码会更简洁，但可能更难理解。

虽然应该始终优先使用并发实用程序来等替换wait和notify方法，但你可能必须维护使用wait和notify的旧代码。 wait方法用于使线程等待某些条件。 必须在同步区域内调用它，该区域锁定调用它的对象。 下面是使用wait方法的标准习惯用法：

// The standard idiom for using the wait method
synchronized (obj) {
    while (<condition does not hold>)
        obj.wait(); // (Releases lock, and reacquires on wakeup)
    ... // Perform action appropriate to condition
}

始终要在循环中调用wait方法；永远不要在循环以外调用它。循环用于测试wait先后的条件。

若是条件已经存在，则在wait以前测试条件并跳过等待以确保活性（liveness）。 若是条件已经存在而且在线程等待以前已经调用了notify（或notifyAll）方法，则没法保证线程将从等待中唤醒。

为了确保安全，须要在等待以后再测试条件，若是条件不成立，则再次等待。若是线程在条件不成立的状况下继续执行该操做，它可能会破坏由锁保护的不变式（invariant）。当条件不成立时，如下几个缘由能够把线程唤醒：

• 另外一个线程能够得到锁并在线程调用notify和等待线程醒来之间改变了保护状态。
• 当条件不成立时，另外一个线程可能意外地或恶意地调用notify方法。类经过等待公共可访问的对象来暴露本身。公共可访问对象的同步方法中的任何wait方法都容易受到这个问题的影响。
• 通知线程在唤醒等待线程时可能过于“慷慨”。例如，即便只有一些等待线程的知足条件，通知线程也可能调用notifyAll。
• 在没有通知的状况下，等待的线程可能(不多)被唤醒。这被称为虚假的唤醒（spurious wakeup）[POSIX, 11.4.3.6.1;Java9-api]。

一个相关的问题是，为了唤醒等待的线程，是使用notify仍是notifyAll。(回想一下notify唤醒一个等待线程，假设存在这样一个线程，notifyAll唤醒全部等待线程)。有时人们会说，应该始终使用notifyAll。这是合理的、保守的建议。它老是会产生正确的结果，由于它保证唤醒全部须要被唤醒的线程。可能还会唤醒其余一些线程，但这不会影响程序的正确性。这些线程将检查它们正在等待的条件，若是发现为false，将继续等待。

做为一种优化，若是全部线程都在等待相同的条件，而且每次只有一个线程能够从条件变为true中唤醒，那么能够选择调用notify而不是notifyAll。

即便知足了这些先决条件，也可能有理由使用notifyAll来代替notify。正如将wait方法调用放在循环中能够防止公共访问对象上的意外或恶意通知同样，使用notifyAll代替notify能够防止不相关线程的意外或恶意等待。不然，这样的等待可能会“吞下”一个关键通知，让预期的接收者无限期地等待。

总之，与java.util.concurrent提供的高级语言相比，直接使用wait和notify就像在“并发汇编语言”中编程同样。在新代码中基本上不存在使用wait和notify的理由。 若是正在维护使用wait和notify的代码，请确保它始终使用标准惯用法在while循环内调用wait方法。 一般应优先使用notifyAll方法进行通知。 若是使用notify，必须很是当心以确保程序的活性。