目 录 [ - ]

1. 进程和线程
2. 线程对象
3. 同步
4. 活跃度
5. 保护块（Guarded Blocks）
6. 不可变对象
7. 高级并发对象

（本部分原文链接，译文链接，译者：bjsuo，校对：郑旭东）
在并发编程中，有两个基本的执行单元：进程和线程。在java语言中，并发编程最关心的是线程，然而，进程也是非常重要的。

即使在只有单一的执行核心的计算机系统中，也有许多活动的进程和线程。因此，在任何给定的时刻，只有一个线程在实际执行。处理器的处理时间是通过操作系统的时间片在进程和线程中共享的。

现在具有多处理器或有多个执行内核的多处理器的计算机系统越来越普遍，这大大增强了系统并发执行的进程和线程的吞吐量–但在不没有多个处理器或执行内核的简单的系统中，并发任然是可能的。

进程

进程具有一个独立的执行环境。通常情况下，进程拥有一个完整的、私有的基本运行资源集合。特别地，每个进程都有自己的内存空间。

进程往往被看作是程序或应用的代名词，然而，用户看到的一个单独的应用程序实际上可能是一组相互协作的进程集合。为了便于进程之间的通信，大多数操作系统都支持进程间通信（IPC），如pipes 和sockets。IPC不仅支持同一系统上的通信，也支持不同的系统。

Java虚拟机的大多数实现是单进程的。Java应用可以使用的ProcessBuilder对象创建额外的进程，多进程应用超出了本课的范围。

线程

线程有时也被称为轻量级的进程。进程和线程都提供了一个执行环境，但创建一个新的线程比创建一个新的进程需要的资源要少。

线程是在进程中存在的 — 每个进程最少有一个线程。线程共享进程的资源，包括内存和打开的文件。这样提高了效率，但潜在的问题就是线程间的通信。

多线程的执行是Java平台的一个基本特征。每个应用都至少有一个线程 – 或几个，如果算上“系统”线程的话，比如内存管理和信号处理等。但是从程序员的角度来看，启动的只有一个线程，叫主线程。这个线程有能力创建额外的线程，我们将在下一节演示。

（本部分原文链接，译文链接，译者：郑旭东）
在Java中，每个线程都是Thread类的实例。并发应用中一般有两种不同的线程创建策略。

1. public class HelloRunnable implements Runnable {
3.     public void run() {
4.         System.out.println("Hello from a thread!");
5.     }
7.     public static void main(String args[]) {
8.         (new Thread(new HelloRunnable())).start();
9.     }
11. }

1. public class HelloThread extends Thread {
3.     public void run() {
4.         System.out.println("Hello from a thread!");
5.     }
7.     public static void main(String args[]) {
8.         (new HelloThread()).start();
9.     }
11. }

1. public class SleepMessages {
2.     public static void main(String args[])
3.         throws InterruptedException {
4.         String importantInfo[] = {
5.             "Mares eat oats",
6.             "Does eat oats",
7.             "Little lambs eat ivy",
8.             "A kid will eat ivy too"
9.         };
11.         for (int i = 0;
12.              i < importantInfo.length;
13.              i++) {
14.             //Pause for 4 seconds
15.             Thread.sleep(4000);
16.             //Print a message
17.             System.out.println(importantInfo[i]);
18.         }
19.     }
20. }

1. for (int i = 0; i < importantInfo.length; i++) {
2.     // Pause for 4 seconds
3.     try {
4.        Thread.sleep(4000);
5.     } catch (InterruptedException e) {
6.        // We've been interrupted: no more messages.
7.       return;
8.  }
9.  // Print a message
10.  System.out.println(importantInfo[i]);
11. }

1. for (int i = 0; i < inputs.length; i++) {
2.     heavyCrunch(inputs[i]);
3.     if (Thread.interrupted()) {
4.         // We've been interrupted: no more crunching.
5.         return;
6.     }
7. }

1. if (Thread.interrupted()){
2.    throw new InterruptedException();
3. }

1. t.join();

1. public class SimpleThreads {
3.     // Display a message, preceded by
4.     // the name of the current thread
5.     static void threadMessage(String message) {
6.         String threadName =
7.             Thread.currentThread().getName();
8.         System.out.format("%s: %s%n",
9.                           threadName,
10.                           message);
11.     }
13.     private static class MessageLoop
14.         implements Runnable {
15.         public void run() {
16.             String importantInfo[] = {
17.                 "Mares eat oats",
18.                 "Does eat oats",
19.                 "Little lambs eat ivy",
20.                 "A kid will eat ivy too"
21.             };
22.             try {
23.                 for (int i = 0;
24.                      i < importantInfo.length;
25.                      i++) {
26.                     // Pause for 4 seconds
27.                     Thread.sleep(4000);
28.                     // Print a message
29.                     threadMessage(importantInfo[i]);
30.                 }
31.             } catch (InterruptedException e) {
32.                 threadMessage("I wasn't done!");
33.             }
34.         }
35.     }
37.     public static void main(String args[])
38.         throws InterruptedException {
40.         // Delay, in milliseconds before
41.         // we interrupt MessageLoop
42.         // thread (default one hour).
43.         long patience = 1000 * 60 * 60;
45.         // If command line argument
46.         // present, gives patience
47.         // in seconds.
48.         if (args.length > 0) {
49.             try {
50.                 patience = Long.parseLong(args[0]) * 1000;
51.             } catch (NumberFormatException e) {
52.                 System.err.println("Argument must be an integer.");
53.                 System.exit(1);
54.             }
55.         }
57.         threadMessage("Starting MessageLoop thread");
58.         long startTime = System.currentTimeMillis();
59.         Thread t = new Thread(new MessageLoop());
60.         t.start();
62.         threadMessage("Waiting for MessageLoop thread to finish");
63.         // loop until MessageLoop
64.         // thread exits
65.         while (t.isAlive()) {
66.             threadMessage("Still waiting...");
67.             // Wait maximum of 1 second
68.             // for MessageLoop thread
69.             // to finish.
70.             t.join(1000);
71.             if (((System.currentTimeMillis() - startTime) > patience)
72.                   && t.isAlive()) {
73.                 threadMessage("Tired of waiting!");
74.                 t.interrupt();
75.                 // Shouldn't be long now
76.                 // -- wait indefinitely
77.                 t.join();
78.             }
79.         }
80.         threadMessage("Finally!");
81.     }
82. }

（本部分原文链接，译文链接，译者：蘑菇街-小宝，Greenster，李任  校对：丁一，郑旭东，李任）
线程间的通信主要是通过共享域和引用相同的对象。这种通信方式非常高效，不过可能会引发两种错误：线程干扰和内存一致性错误。防止这些错误发生的方法是同步。

不过，同步会引起线程竞争，当两个或多个线程试图同时访问相同的资源，随之就导致Java运行时环境执行其中一个或多个线程比原先慢很多，甚至执行被挂起，这就出现了线程竞争。线程饥饿和活锁都属于线程竞争的范畴。关于线程竞争的更多信息可参考活跃度一节。

本节内容包括以下这些主题：

• 线程干扰讨论了当多个线程访问共享数据时错误是怎么发生的。
• 内存一致性错误讨论了不一致的共享内存视图导致的错误。
• 同步方法讨论了 一种能有效防止线程干扰和内存一致性错误的常见做法。
• 内部锁和同步讨论了更通用的同步方法，以及同步是如何基于内部锁实现的。
• 原子访问讨论了不能被其他线程干扰的操作的总体思路。

1.  线程干扰

下面这个简单的Counter类：

Counter类被设计成：每次调用increment()方法，c的值加1；每次调用decrement()方法，c的值减1。如果当同一个Counter对象被多个线程引用，线程间的干扰可能会使结果同我们预期的不一致。

当两个运行在不同的线程中却作用在相同的数据上的操作交替执行时，就发生了线程干扰。这意味着这两个操作都由多个步骤组成，而步骤间的顺序产生了重叠。

Counter类实例的操作会交替执行，这看起来似乎不太可能，因为c上的这两个操作都是单一而简单的语句。然而，即使一个简单的语句也会被虚拟机转换成多个步骤。我们不去深究虚拟机内部的详细执行步骤——理解c++这个单一的语句会被分解成3个步骤就足够了：

• 获取当前c的值；
• 对获取到的值加1；
• 把递增后的值写回到c；

语句c–也可以按同样的方式分解，除了第二步的操作是递减而不是递增。

假设线程A调用increment()的同时线程B调用decrement().如果c的初始值为0，线程A和B之间的交替执行顺序可能是下面这样：

• 线程A：获取c；
• 线程B：获取c；
• 线程A：对获取的值加1，结果为1；
• 线程B：对获取的值减1，结果为-1；
• 线程A：结果写回到c,c现在是1；
• 线程B：结果写回到c,c现在是-1；

线程A的结果因为被线程B覆盖而丢失了。这个交替执行的结果只是其中一种可能性。在不同的环境下，可能是线程B的结果丢失了，也可能是不会出任何问题。由于结果是不可预知的，所以线程干扰的bug很难检测和修复。

2.  内存一致性错误

当不同的线程对相同的数据产生不一致的视图时会发生内存一致性错误。内存一致性错误的原因比较复杂，也超出了本教程的范围。不过幸运的是，一个程序员并不需要对这些原因有详细的了解。所需要的是避免它们的策略。

避免内存一致性错误的关键是理解happens-before关系。这种关系只是确保一个特定语句的写内存操作对另外一个特定的语句可见。要说明这个问题，请参考下面的例子。假设定义和初始化了一个简单int字段：

这个counter字段被A，B两个线程共享。假设线程A对counter执行递增:

然后，很快的，线程B输出counter:

如果这两个语句已经在同一个线程中被执行过，那么输出的值应该是“1”。不过如果这两个语句在不同的线程中分开执行，那输出的值很可能是“0”， 因为无法保证线程A对counter的改动对线程B是可见的——除非我们在这两个语句之间已经建立了happens-before关系。

有许多操作会建立happens-before关系。其中一个是同步，我们将在下面的章节中看到。
我们已经见过两个建立happens-before关系的操作。

当一条语句调用Thread.start方法时，和该语句有happens-before关系的每一条语句，跟新线程执行的每一条语句同样有happens-before关系。创建新线程之前的代码的执行结果对线新线程是可见的。

当一个线程终止并且当导致另一个线程中Thread.join返回时，被终止的线程执行的所有语句和在join返回成功之后的所有语句间有happens-before关系。线程中代码的执行结果对执行join操作的线程是可见的。

要查看建立happens-before关系的操作列表，请参阅java.util.concurrent包的摘要页面。

3.  同步方法

Java编程语言提供两种同步方式：同步方法和同步语句。相对较复杂的同步语句将在下一节中介绍。本节主要关注同步方法。

要让一个方法成为同步方法，只需要在方法声明中加上synchronized关键字：

如果count是SynchronizedCounter类的实例，那么让这些方法成为同步方法有两个作用:
首先，相同对象上的同步方法的两次调用，它们要交替执行是不可能的。 当一个线程正在执行对象的同步方法时，所有其他调用该对象同步方法的线程会被阻塞（挂起执行）,直到第一个线程处理完该对象。

其次，当一个同步方法退出时，它会自动跟该对象同步方法的任意后续调用建立起一种happens-before关系。这确保对象状态的改变对所有线程是可见的。

注意构造方法不能是同步的——构造方法加synchronized关键字会报语法错误。同步的构造方法没有意义，因为当这个对象被创建的时候，只有创建对象的线程能访问它。

警告：当创建的对象会被多个线程共享时必须非常小心，对象的引用不要过早“暴露”出去。比如，假设你要维护一个叫instances的List，它包含类的每一个实例对象。你可能会尝试在构造方法中加这样一行：

不过其他线程就能够在对象构造完成之前使用instances访问对象。

同步(synchronized)方法使用一种简单的策略来防止线程干扰和内存一致性错误：如果一个对象对多个线程可见，对象域上的所有读写操作 都是通过synchronized方法来完成的。（一个重要的例外：final域，在对象被创建后不可修改,能被非synchronized方法安全的读 取）。synchronized同步策略很有效，不过会引起活跃度问题，我们将在本节后面看到。

4.  内部锁与同步

同步机制的建立是基于其内部一个叫内部锁或者监视锁的实体。（在Java API规范中通常被称为监视器。）内部锁在同步机制中起到两方面的作用：对一个对象的排他性访问；建立一种happens-before关系，而这种关系正是可见性问题的关键所在。

每个对象都有一个与之关联的内部锁。通常当一个线程需要排他性的访问一个对象的域时，首先需要请求该对象的内部锁，当访问结束时释放内部锁。在线 程获得内部锁到释放内部锁的这段时间里，我们说线程拥有这个内部锁。那么当一个线程拥有一个内部锁时，其他线程将无法获得该内部锁。其他线程如果去尝试获 得该内部锁，则会被阻塞。

当线程释放一个内部锁时，该操作和对该锁的后续请求间将建立happens-before关系。

5.  同步方法中的锁

当线程调用一个同步方法时，它会自动请求该方法所在对象的内部锁。当方法返回结束时则自动释放该内部锁，即使退出是由于发生了未捕获的异常，内部锁也会被释放。

你可能会问调用一个静态的同步方法会如何，由于静态方法是和类（而不是对象）相关的，所以线程会请求类对象(Class Object)的内部锁。因此用来控制类的静态域访问的锁不同于控制对象访问的锁。

6.  同步块

另外一种同步的方法是使用同步块。和同步方法不同，同步块必须指定所请求的是哪个对象的内部锁：

在上面的例子中，addName方法需要使lastName和nameCount的更改保持同步，而且要避免同步调用该对象的其他方法。（在同步代码中调用其他方法会产生Liveness一节所描述的问题。）如果不使用同步块，那么必须要定义一个额外的非同步方法，而这个方法仅仅是用来调用nameList.add。

使用同步块对于更细粒度的同步很有帮助。例如类MsLunch有两个实例域c1和c2，他们并不会同时使用（译者注：即c1和c2是彼此无关的两 个域），所有对这两个域的更新都需要同步，但是完全不需要防止c1的修改和c2的修改相互之间干扰（这样做只会产生不必要的阻塞而降低了并发性）。这种情 况下不必使用同步方法，可以使用和this对象相关的锁。这里我们创建了两个“锁”对象（译者注：起到加锁效果的普通对象lock1和lock2）。

使用这种方法时要特别小心，需要十分确定c1和c2是彼此无关的域。

7.  可重入同步

还记得吗，一个线程不能获得其他线程所拥有的锁。但是它可以获得自己已经拥有的锁。允许一个线程多次获得同一个锁实现了可重入同步。这里描述了一 种同步代码的场景，直接的或间接地，调用了一个也拥有同步代码的方法，且两边的代码使用的是同一把锁。如果没有这种可重入的同步机制，同步代码则需要采取 许多额外的预防措施以防止线程阻塞自己。

8.  原子访问

在编程过程中，原子操作是指所有操作都同时发生。原子操作不能被中途打断：要么全做，要么不做。原子操作在完成前不会有看得见的副作用。

我们发现像c++这样的增量表达式，并没有描述原子操作。即使是非常简单的表达式也能够定义成能被分解为其他操作的复杂操作。然而，有些操作你可以定义为原子的：

• 对引用变量和大部分基本类型变量（除long和double之外）的读写是原子的。
• 对所有声明为volatile的变量（包括long和double变量）的读写是原子的。

原子操作不会交错，于是可以放心使用，不必担心线程干扰。然而，这并不能完全消除原子操作上的同步，因为内存一致性错误仍可能发生。使用 volatile变量可以降低内存一致性错误的风险，因为对volatile变量的任意写操作，对于后续在该变量上的读操作建立了happens- before关系。这意味着volatile变量的修改对于其他线程总是可见的。更重要的是，这同时也意味着当一个线程读取一个volatile变量时， 它不仅能看到该变量最新的修改，而且也能看到致使该改变发生的代码的副效应。

使用简单的原子变量访问比通过同步代码来访问更高效，但是需要程序员更加谨慎以避免内存一致性错误。至于这额外的付出是否值得，得看应用的大小和复杂度。

java.util.concurrent包中的一些类提供了一些不依赖同步机制的原子方法。我们将在高级并发对象这一节中讨论它们。

（本部分原文地址，译文地址，译者：李任，郑旭东 校对：蘑菇街-小宝）
一个并发应用程序能及时执行的能力称为活跃性。本节将介绍最常见的活跃性问题：死锁（deadlock），以及另外两个活跃性问题：饥饿（starvation）和活锁（livelock）。

1.  死锁

死锁描述了这样一种情景，两个或多个线程永久阻塞，互相等待对方释放资源。下面是一个例子。

Alphone和Gaston是朋友，都很讲究礼节。礼节有一个严格的规矩，当你向一个朋友鞠躬时，你必须保持鞠躬的姿势，直到你的朋友有机会回鞠给你。不幸的是，这个规矩没有算上两个朋友相互同时鞠躬的可能。

下面的应用例子，DeadLock，模拟了这个可能性。

当DeadLock运行后，两个线程极有可能阻塞，当它们尝试调用bowBack方法时。没有哪个阻塞会结束，因为每个线程都在等待另一个线程退出bow方法。

2.  饥饿和活锁

饥饿和活锁并不如死锁一般普遍，但它仍然是每个并发程序设计者可能会遇到的问题。

饥饿

饥饿是指当一个线程不能正常的访问共享资源并且不能正常执行的情况。这通常在共享资源被其他“贪心”的线程长期时发生。举个例子，假设一个对象提 供了一个同步方法，这个方法通常需要执行很长一段时间才返回。如果一个线程经常调用这个方法，那么其他需要同步的访问这个对象的线程就经常会被阻塞。

活锁

一个线程通常会有会响应其他线程的活动。如果其他线程也会响应另一个线程的活动，那么就有可能发生活锁。同死锁一样，发生活锁的线程无法继续执 行。然而线程并没有阻塞——他们在忙于响应对方无法恢复工作。这就相当于两个在走廊相遇的人：Alphonse向他自己的左边靠想让Gaston过去，而 Gaston向他的右边靠想让Alphonse过去。可见他们阻塞了对方。Alphonse向他的右边靠，而Gaston向他的左边靠，他们还是阻塞了对 方。

（本部分原文连接，译文连接，译者：Greester，校对：郑旭东）
多线程之间经常需要协同工作，最常见的方式是使用Guarded Blocks，它循环检查一个条件（通常初始值为true），直到条件发生变化才跳出循环继续执行。在使用Guarded Blocks时有以下几个步骤需要注意：假设guardedJoy()方法必须要等待另一线程为共享变量joy设值才能继续执行。那么理论上可以用一个简单的条件循环来实现，但在等待过程中guardedJoy方法不停的检查循环条件实际上是一种资源浪费。

更加高效的方法是调用Object.wait将当前线程挂起，直到有另一线程发起事件通知（尽管通知的事件不一定是当前线程等待的事件）。

注意：一定要在循环里面调用wait方法，不要想当然的认为线程唤醒后循环条件一定发生了改变。

和其他可以暂停线程执行的方法一样，wait方法会抛出InterruptedException，在上面的例子中，因为我们关心的是joy的值，所以忽略了InterruptedException。

为什么guardedJoy是synchronized方法？假设d是用来调用wait的对象，当一个线程调用d.wait，它必须要拥有d的内部锁（否则会抛出异常），获得d的内部锁的最简单方法是在一个synchronized方法里面调用wait。

当一个线程调用wait方法时，它释放锁并挂起。然后另一个线程请求并获得这个锁并调用Object.notifyAll通知所有等待该锁的线程。

当第二个线程释放这个该锁后，第一个线程再次请求该锁，从wait方法返回并继续执行。

注意：还有另外一个通知方法，notify()，它只会唤醒一个线程。但由于它并不允许指定哪一个线程被唤醒，所以一般只在大规模并发应用（即系统有大量相似任务的线程）中使用。因为对于大规模并发应用，我们其实并不关心哪一个线程被唤醒。

现在我们使用Guarded blocks创建一个生产者/消费者应用。这类应用需要在两个线程之间共享数据：生产者生产数据，消费者使用数据。两个线程通过共享对象通信。在这里，线 程协同工作的关键是：生产者发布数据之前，消费者不能够去读取数据；消费者没有读取旧数据前，生产者不能发布新数据。

在下面的例子中，数据通过Drop对象共享的一系列文本消息：

Producer是生产者线程，发送一组消息，字符串DONE表示所有消息都已经发送完成。为了模拟现实情况，生产者线程还会在消息发送时随机的暂停。

Consumer是消费者线程，读取消息并打印出来，直到读取到字符串DONE为止。消费者线程在消息读取时也会随机的暂停。

ProducerConsumerExample是主线程，它启动生产者线程和消费者线程。

注意：Drop类是用来演示Guarded Blocks如何工作的。为了避免重新发明轮子，当你尝试创建自己的共享数据对象时，请查看Java Collections Framework中已有的数据结构。如需更多信息，请参考Questions and Exercises。

（本部分原文链接，译文链接，译者：Greenster，校对：郑旭东）
一个对象如果在创建后不能被修改，那么就称为不可变对象。在并发编程中，一种被普遍认可的原则就是：尽可能的使用不可变对象来创建简单、可靠的代码。

在并发编程中，不可变对象特别有用。由于创建后不能被修改，所以不会出现由于线程干扰产生的错误或是内存一致性错误。

但是程序员们通常并不热衷于使用不可变对象，因为他们担心每次创建新对象的开销。实际上这种开销常常被过分高估，而且使用不可变对象所带来的一些 效率提升也抵消了这种开销。例如：使用不可变对象降低了垃圾回收所产生的额外开销，也减少了用来确保使用可变对象不出现并发错误的一些额外代码。

接下来看一个可变对象的类，然后转化为一个不可变对象的类。通过这个例子说明转化的原则以及使用不可变对象的好处。

一个同步类的例子

SynchronizedRGB是表示颜色的类，每一个对象代表一种颜色，使用三个整形数表示颜色的三基色，字符串表示颜色名称。

使用SynchronizedRGB时需要小心，避免其处于不一致的状态。例如一个线程执行了以下代码：

如果有另外一个线程在Statement 1之后、Statement 2之前调用了color.set方法，那么myColorInt的值和myColorName的值就会不匹配。为了避免出现这样的结果，必须要像下面这样把这两条语句绑定到一块执行：

这种不一致的问题只可能发生在可变对象上。

定义不可变对象的策略

以下的一些规则是创建不可变对象的简单策略。并非所有不可变类都完全遵守这些规则，不过这不是编写这些类的程序员们粗心大意造成的，很可能的是他们有充分的理由确保这些对象在创建后不会被修改。但这需要非常复杂细致的分析，并不适用于初学者。

1. 不要提供setter方法。（包括修改字段的方法和修改字段引用对象的方法）
2. 将类的所有字段定义为final、private的。
3. 不允许子类重写方法。简单的办法是将类声明为final，更好的方法是将构造函数声明为私有的，通过工厂方法创建对象。
4. 如果类的字段是对可变对象的引用，不允许修改被引用对象。

·不提供修改可变对象的方法。
·不共享可变对象的引用。当一个引用被当做参数传递给构造函数，而这个引用指向的是一个外部的可变对象时，一定不要保存这个引用。如果必须要保存，那么创建可变对象的拷贝，然后保存拷贝对象的引用。同样如果需要返回内部的可变对象时，不要返回可变对象本身，而是返回其拷贝。

将这一策略应用到SynchronizedRGB有以下几步：

1. SynchronizedRGB类有两个setter方法。第一个set方法只是简单的为字段设值（译者注：删掉即可），第二个invert方法修改为创建一个新对象，而不是在原有对象上修改。
2. 所有的字段都已经是私有的，加上final即可。
3. 将类声明为final的
4. 只有一个字段是对象引用，并且被引用的对象也是不可变对象。

经过以上这些修改后，我们得到了ImmutableRGB：

1. import java.util.concurrent.locks.Lock;
2. import java.util.concurrent.locks.ReentrantLock;
3. import java.util.Random;
5. public class Safelock {
6.     static class Friend {
7.         private final String name;
8.         private final Lock lock = new ReentrantLock();
10.         public Friend(String name) {
11.             this.name = name;
12.         }
14.         public String getName() {
15.             return this.name;
16.         }
18.         public boolean impendingBow(Friend bower) {
19.             Boolean myLock = false;
20.             Boolean yourLock = false;
21.             try {
22.                 myLock = lock.tryLock();
23.                 yourLock = bower.lock.tryLock();
24.             } finally {
25.                 if (! (myLock && yourLock)) {
26.                     if (myLock) {
27.                         lock.unlock();
28.                     }
29.                     if (yourLock) {
30.                         bower.lock.unlock();
31.                     }
32.                 }
33.             }
34.             return myLock && yourLock;
35.         }
37.         public void bow(Friend bower) {
38.             if (impendingBow(bower)) {
39.                 try {
40.                     System.out.format("%s: %s has"
41.                         + " bowed to me!%n",
42.                         this.name, bower.getName());
43.                     bower.bowBack(this);
44.                 } finally {
45.                     lock.unlock();
46.                     bower.lock.unlock();
47.                 }
48.             } else {
49.                 System.out.format("%s: %s started"
50.                     + " to bow to me, but saw that"
51.                     + " I was already bowing to"
52.                     + " him.%n",
53.                     this.name, bower.getName());
54.             }
55.         }
57.         public void bowBack(Friend bower) {
58.             System.out.format("%s: %s has" +
59.                 " bowed back to me!%n",
60.                 this.name, bower.getName());
61.         }
62. }
64.     static class BowLoop implements Runnable {
65.         private Friend bower;
66.         private Friend bowee;
68.         public BowLoop(Friend bower, Friend bowee) {
69.             this.bower = bower;
70.             this.bowee = bowee;
71.         }
73.         public void run() {
74.             Random random = new Random();
75.             for (;;) {
76.                 try {
77.                     Thread.sleep(random.nextInt(10));
78.                 } catch (InterruptedException e) {}
79.                 bowee.bow(bower);
80.             }
81.         }
82.     }
84.     public static void main(String[] args) {
85.         final Friend alphonse =
86.             new Friend("Alphonse");
87.         final Friend gaston =
88.             new Friend("Gaston");
89.         new Thread(new BowLoop(alphonse, gaston)).start();
90.         new Thread(new BowLoop(gaston, alphonse)).start();
91.     }
92. }

1. e.execute(r);

1. (new Thread(r)).start();

1. if (当前这个任务工作量足够小)
2.     直接完成这个任务
3. else
4.     将这个任务或这部分工作分解成两个部分
5.     分别触发(invoke)这两个子任务的执行，并等待结果

1. public class ForkBlur extends RecursiveAction {
2. private int[] mSource;
3. private int mStart;
4. private int mLength;
5. private int[] mDestination;
7. // Processing window size; should be odd.
8. private int mBlurWidth = 15;
10. public ForkBlur(int[] src, int start, int length, int[] dst) {
11.     mSource = src;
12.     mStart = start;
13.     mLength = length;
14.     mDestination = dst;
15. }
17. protected void computeDirectly() {
18.     int sidePixels = (mBlurWidth - 1) / 2;
19.     for (int index = mStart; index &lt; mStart + mLength; index++) {
20.         // Calculate average.
21.         float rt = 0, gt = 0, bt = 0;
22.         for (int mi = -sidePixels; mi &lt;= sidePixels; mi++) {
23.             int mindex = Math.min(Math.max(mi + index, 0),
24.                                 mSource.length - 1);
25.             int pixel = mSource[mindex];
26.             rt += (float)((pixel &amp; 0x00ff0000) &gt;&gt; 16)
27.                   / mBlurWidth;
28.             gt += (float)((pixel &amp; 0x0000ff00) &gt;&gt;  8)
29.                   / mBlurWidth;
30.             bt += (float)((pixel &amp; 0x000000ff) &gt;&gt;  0)
31.                   / mBlurWidth;
32.         }
34.         // Reassemble destination pixel.
35.         int dpixel = (0xff000000     ) |
36.                (((int)rt) &lt;&lt; 16) |
37.                (((int)gt) &lt;&lt;  8) |
38.                (((int)bt) &lt;&lt;  0);
39.         mDestination[index] = dpixel;
40.     }
41. }

1. protected static int sThreshold = 100000;
3. protected void compute() {
4.     if (mLength &lt; sThreshold) {
5.         computeDirectly();
6.         return;
7.     }
9.     int split = mLength / 2;
11.     invokeAll(new ForkBlur(mSource, mStart, split, mDestination),
12.               new ForkBlur(mSource, mStart + split, mLength - split,
13.                            mDestination));
14. }

1. // source image pixels are in src
2. // destination image pixels are in dst
3. ForkBlur fb = new ForkBlur(src, 0, src.length, dst);

1. ForkJoinPool pool = new ForkJoinPool();

1. pool.invoke(fb);

1. class Counter {
2.     private int c = 0;
3.     public void increment() {
4.         c++;
5.     }
7.     public void decrement() {
8.         c--;
9.     }
11.     public int value() {
12.         return c;
13.     }
14. }

1. class SynchronizedCounter {
2. private int c = 0;
3. public synchronized void increment() {
4. c++;
5. }
6. public synchronized void decrement() {
7. c--;
8. }
9. public synchronized int value() {
10. return c;
11. }
12. }

1. import java.util.concurrent.atomic.AtomicInteger;
2. class AtomicCounter {
3. private AtomicInteger c = new AtomicInteger(0);
4. public void increment() {
5. c.incrementAndGet();
6. }
8. public void decrement() {
9. c.decrementAndGet();
10. }
12. public int value() {
13. return c.get();
14. }

1. int r = ThreadLocalRandom.current().nextInt(4,77);

http://www.iteye.com/magazines/131