产品经理新视线

本文原作者：Ted Neward 地址：http://www.ibm.com/developerworks/java/library/j-5things4.html

本文指导并发编程初学者(像我这样的) = =通过并发 Collections 进行多线程编程~

简介： 编写能够良好执行，防止应用程序受损的多线程代码是很艰巨的任务 — 这也是为什么我们需要 java.util.concurrent 的原因。Ted Neward 会向您说明并发 Collections 类，比如 CopyOnWriteArrayList，BlockingQueue，还有 ConcurrentMap，如何针对您的并发编程需求改进标准 Collections 类。

Concurrent Collections 是 Java™ 5 的巨大附加产品，但是在关于注释和泛型的争执中很多 Java 开发人员忽视了它们。此外（或者更老实地说），许多开发人员避免使用这个数据包，因为他们认为它一定很复杂，就像它所要解决的问题一样。

事实上，java.util.concurrent 包含许多类，能够有效解决普通的并发问题，无需复杂工序。阅读本文，了解 java.util.concurrent 类，比如    CopyOnWriteArrayList 和 BlockingQueue 如何帮助您解决多线程编程的棘手问题。

1. TimeUnit

尽管本质上 不是 Collections 类，但 java.util.concurrent.TimeUnit 枚举让代码更易读懂。使用 TimeUnit 将使用您的方法或 API 的开发人员从毫秒的 “暴政” 中解放出来。

TimeUnit 包括所有时间单位，从 MILLISECONDS 和 MICROSECONDS 到 DAYS 和 HOURS，这就意味着它能够处理一个开发人员所需的几乎所有的时间范围类型。同时，因为在列举上声明了转换方法，在时间加快时，将 HOURS 转换回 MILLISECONDS 甚至变得更容易。

2. CopyOnWriteArrayList

创建数组的全新副本是过于昂贵的操作，无论是从时间上，还是从内存开销上，因此在通常使用中很少考虑；开发人员往往求助于使用同步的 ArrayList。然而，这也是一个成本较高的选择，因为每当您跨集合内容进行迭代时，您就不得不同步所有操作，包括读和写，以此保证一致性。

这又让成本结构回到这样一个场景：需多读者都在读取 ArrayList，但是几乎没人会去修改它。

CopyOnWriteArrayList 是个巧妙的小宝贝 ，能解决这一问题。它的 Javadoc 将 CopyOnWriteArrayList 定义为一个 “ArrayList 的线程安全变体，在这个变体中所有易变操作（添加，设置等）可以通过复制全新的数组来实现”。

集合从内部将它的内容复制到一个没有修改的新数组，这样读者访问数组内容时就不会产生同步成本（因为他们从来不是在易变数据上操作）。

本质上讲，CopyOnWriteArrayList 很适合处理 ArrayList 经常让我们失败的这种场景：读取频繁，但很少有写操作的集合，例如 JavaBean 事件的 Listeners。

(Copy on write 也是操作系统内存模型中一个非常常用和经典的策略,  类似的策略如Load on calling ：为了防止程序启动时的加载开销，典型的 懒汉型的单例模式就是这样的~不过有时候需要Load on Startup ，比如启动的类依赖于很多其他的类时，或者为了确保资源的可用性，以免当调用的时候才报错（=  = 阿里的webx的启动就先要加载一堆Service对象的~）)。

3. BlockingQueue

BlockingQueue 接口表示它是一个 Queue，意思是它的项以先入先出（FIFO）顺序存储。在特定顺序插入的项以相同的顺序检索 — 但是需要附加保证，从空队列检索一个项的任何尝试都会阻塞调用线程，直到这个项准备好被检索。同理，想要将一个项插入到满队列的尝试也会导致阻塞调用线程，直到队列的存储空间可用。

BlockingQueue 干净利落地解决了如何将一个线程收集的项“传递”给另一线程用于处理的问题，无需考虑同步问题。Java Tutorial 的 Guarded Blocks 试用版就是一个很好的例子。它构建一个单插槽绑定的缓存，当新的项可用，而且插槽也准备好接受新的项时，使用手动同步和 wait()/notifyAll() 在线程之间发信。

尽管 Guarded Blocks 教程中的代码有效，但是它耗时久，混乱，而且也并非完全直观。退回到 Java 平台较早的时候，没错，Java 开发人员不得不纠缠于这种代码；但现在是 2010 年 — 情况难道没有改善？

清单 1 显示了 Guarded Blocks 代码的重写版，其中我使用了一个 ArrayBlockingQueue，而不是手写的 Drop。

import java.util.*;
import java.util.concurrent.*;

class Producer
    implements Runnable
{
    private BlockingQueue drop;
    List messages = Arrays.asList(
        "Mares eat oats",
        "Does eat oats",
        "Little lambs eat ivy",
        "Wouldn't you eat ivy too?");

    public Producer(BlockingQueue d) { this.drop = d; }

    public void run()
    {
        try
        {
            for (String s : messages)
                drop.put(s);
            drop.put("DONE");
        }
        catch (InterruptedException intEx)
        {
            System.out.println("Interrupted! " +
                "Last one out, turn out the lights!");
        }
    }
}

class Consumer
    implements Runnable
{
    private BlockingQueue drop;
    public Consumer(BlockingQueue d) { this.drop = d; }

    public void run()
    {
        try
        {
            String msg = null;
            while (!((msg = drop.take()).equals("DONE")))
                System.out.println(msg);
        }
        catch (InterruptedException intEx)
        {
            System.out.println("Interrupted! " +
                "Last one out, turn out the lights!");
        }
    }
}

public class ABQApp
{
    public static void main(String[] args)
    {
        BlockingQueue drop = new ArrayBlockingQueue(1, true);
        (new Thread(new Producer(drop))).start();
        (new Thread(new Consumer(drop))).start();
    }
}

ArrayBlockingQueue 还体现了“公平” — 意思是它为读取器和编写器提供线程先入先出访问。这种替代方法是一个更有效，但又冒穷尽部分线程风险的政策。（即，允许一些读取器在其他读取器锁定时运行效率更高，但是您可能会有读取器线程的流持续不断的风险，导致编写器无法进行工作。）

BlockingQueue 还支持接收时间参数的方法，时间参数表明线程在返回信号故障以插入或者检索有关项之前需要阻塞的时间。这么做会避免非绑定的等待，这对一个生产系统是致命的，因为一个非绑定的等待会很容易导致需要重启的系统挂起。

4. ConcurrentMap

Map 有一个微妙的并发 bug，这个 bug 将许多不知情的 Java 开发人员引入歧途。ConcurrentMap 是最容易的解决方案。

当一个 Map 被从多个线程访问时，通常使用 containsKey() 或者 get() 来查看给定键是否在存储键/值对之前出现。但是即使有一个同步的 Map，线程还是可以在这个过程中潜入，然后夺取对 Map 的控制权。问题是，在对 put() 的调用中，锁在 get() 开始时获取，然后在可以再次获取锁之前释放。它的结果是个竞争条件：这是两个线程之间的竞争，结果也会因谁先运行而不同。

如果两个线程几乎同时调用一个方法，两者都会进行测试，调用 put，在处理中丢失第一线程的值。幸运的是，ConcurrentMap 接口支持许多附加方法，它们设计用于在一个锁下进行两个任务：putIfAbsent()，例如，首先进行测试，然后仅当键没有存储在 Map 中时进行 put。

5. SynchronousQueues

根据 Javadoc，SynchronousQueue 是个有趣的东西：

这是一个阻塞队列，其中，每个插入操作必须等待另一个线程的对应移除操作，反之亦然。一个同步队列不具有任何内部容量，甚至不具有 1 的容量。

本质上讲，SynchronousQueue 是之前提过的 BlockingQueue 的又一实现。它给我们提供了在线程之间交换单一元素的极轻量级方法，使用 ArrayBlockingQueue 使用的阻塞语义。在清单 2 中，我重写了1的代码，使用 SynchronousQueue 替代 ArrayBlockingQueue：

清单 2. SynchronousQueue

import java.util.*;
import java.util.concurrent.*;

class Producer
    implements Runnable
{
    private BlockingQueue drop;
    List messages = Arrays.asList(
        "Mares eat oats",
        "Does eat oats",
        "Little lambs eat ivy",
        "Wouldn't you eat ivy too?");

    public Producer(BlockingQueue d) { this.drop = d; }

    public void run()
    {
        try
        {
            for (String s : messages)
                drop.put(s);
            drop.put("DONE");
        }
        catch (InterruptedException intEx)
        {
            System.out.println("Interrupted! " +
                "Last one out, turn out the lights!");
        }
    }
}

class Consumer
    implements Runnable
{
    private BlockingQueue drop;
    public Consumer(BlockingQueue d) { this.drop = d; }

    public void run()
    {
        try
        {
            String msg = null;
            while (!((msg = drop.take()).equals("DONE")))
                System.out.println(msg);
        }
        catch (InterruptedException intEx)
        {
            System.out.println("Interrupted! " +
                "Last one out, turn out the lights!");
        }
    }
}

public class SynQApp
{
    public static void main(String[] args)
    {
        BlockingQueue drop = new SynchronousQueue();
        (new Thread(new Producer(drop))).start();
        (new Thread(new Consumer(drop))).start();
    }
}

实现代码看起来几乎相同，但是应用程序有额外获益：SynchronousQueue 允许在队列进行一个插入，只要有一个线程等着使用它。

在实践中，SynchronousQueue 类似于 Ada 和 CSP 等语言中可用的 “会合通道”。这些通道有时在其他环境中也称为 “连接”，这样的环境包括 .NET .

结束语

当 Java 运行时知识库提供便利、预置的并发性时，为什么还要苦苦挣扎，试图将并发性导入到您的 Collections 类？本系列的下一篇文章将会进一步探讨 java.util.concurrent 名称空间的内容。

本文参考资料：

• “Java theory and practice: Concurrent collections classes” (Brian Goetz, developerWorks, July 2003): Learn how Doug Lea’s util.concurrent package revitalizes standard collection types List and Map.
• “Spice up collections with generics and concurrency” (John Zukowski, developerWorks, April 2008): Introduces changes to the Java Collections Framework in Java 6.
• Package java.util.concurrent, Java platform SE 6: Learn more about the utility classes discussed in this article.
• Guarded Blocks: The most common idiom for coordinating threads.
• “Introduction to the Collections Framework” (MageLang Institute, Sun Developer Network, 1999): This old but good tutorial is a complete introduction to the Java Collections Framework prior to concurrent collections.
• “The Collections Framework“: Read the Java Collections Framework and API documentation from Sun Microsystems.
• The Joins Concurrency Library: Microsoft® Research put out this library implementing the joins concept as a synchronization mechanism; the associated research paper (in PDF) is a good source for learning about the theory behind joins.
• The developerWorks Java technology zone: Hundreds of articles about every aspect of Java programming.

我们在写Java程序的时候，何时需要进行并发控制，关键在于判断这段程序或这个类是否是线程安全的。

当多个线程访问一个类时，如果不用考虑这些线程在运行时环境下的调度和交替执行，并且不需要额外的同步，这个类的行为仍然是正确的，那么称这个类是线程安全的。我们设计类就是要在有潜在并发问题存在情况下，设计线程安全的类。线程安全的类可以通过以下手段来满足：

• 不跨线程共享变量
• 使状态变量为不可变的

(就是通常所说的无状态)

• 在任何访问状态变量的时候使用同步。
• 每个共享的可变变量都需要由唯一一个确定的锁保护。

满足线程安全的一些思路

1）从源头避免并发问题

很多开发者一想到有并发的可能就通过底层技术来解决问题，其实往往可以通过上层的架构设计和业务分析来避免并发场景。比如我们需要用多线程或分布式 集群来计算一堆客户的相关统计值，由于客户的统计值是共享数据，因此会有并发潜在可能。但从业务上我们可以分析出客户与客户之间数据是不共享的，因此可以 设计一个规则来保证一个客户的计算工作和数据访问只会被一个线程或一台工作机完成，而不是把一个客户的计算工作分配给多个线程去完成。这种规则很容易设 计。当你从源头就避免了并发问题的可能，下面的工作就完全可以不用担心线程安全问题。

2）无状态就是线程安全

多线程编程或者分布式编程最忌讳有状态，一有状态就不但限制了其横向扩展能力，也是产生并发问题的起源。当你设计的类是无状态的，那么它永远都是线程安全的。因此在设计阶段需要考虑如何用无状态的类来满足你的业务需求(到底如何把有状态的类变成无状态的呢？)

3）分清原子性操作和复合操作

所谓原子性，是说一个操作不会被其他线程打断，能保证其从开始到结束独享资源连续执行完这一操作。如果所有程序块都是原子性的，那么就不存在任何并 发问题。而很多看上去像是原子性的操作正式并发问题高灾区。比如所熟知的计数器（count++）和check-then-act，这些都是很容易被忽视 的，例如大家所常用的懒汉式初始化模式(单例模式中的一种形式)，以下代码就不是线程安全的：

   @NotThreadSafe
   public class LazyInitRace {
    private ExpensiveObject instance = null;
       public ExpensiveObject getInstance() {
         if (instance == null) {
           instance = new ExpensiveObject();
         }
         return instance;
      }
   }

这段代码具体问题在于没有认识到if(instance==null)和instance = new ExpensiveObject();是两条语句，放在一起就不是原子性的，就有可能当一个线程执行完if(instance==null)后会被中断， 另一个线程也去执行if(instance==null)，这次两个线程都会执行后面的instance = new ExpensiveObject();这也是这个程序所不希望发生的。(单例模式)

虽然check-then-act从表面上看很简单，但却普遍存在与我们日常的开发中，特别是在数据库存取这一块。比如我们需要在数据库里存一个客 户的统计值，当统计值不存在时初始化，当存在时就去更新。如果不把这组逻辑设计为原子性的就很有可能产生出两条这个客户的统计值。（难道transaction不能保证？）

在单机环境下处理这个问题还算容易，通过锁或者同步来把这组复合操作变为原子操作，但在分布式环境下就不适用了。一般情况下是通过在数据库端做文章，比如通过唯一性索引或者悲观锁来保障其数据一致性。当然任何方案都是有代价的，这就需要具体情况下来权衡。

另外，java1.5以后提供了一套提供原子性操作的类，有兴趣的可以研究一下它是如何在软件层面保证原子性的。

4）锁的合理使用

大家都知道可以用锁来解决并发问题，但在具体使用上还有很多讲究，比如：

• 每个共享的可变变量都需要由一个确定的锁保护。
• 一旦使用了锁，就意味着这段代码的执行就丧失了操作系统多道程序的特性，会在一定程度上影响性能
• 锁不能解决在分布式环境共享变量的并发问题

来一道面试题 ：线程有几种状态？
在Java当中，线程通常都有五种状态，创建、就绪、运行、阻塞和死亡。
第一是创建状态。在生成线程对象，并没有调用该对象的start方法，这是线程处于创建状态
第二是就绪状态。当调用了线程对象的start方法之后，该线程就进入了就绪状态，但是此时线程调度程序还没有把该线程设置为当前线程，此时处于就绪状态。在线程运行之后，从等待或者睡眠中回来之后，也会处于就绪状态
第三是运行状态。线程调度程序将处于就绪状态的线程设置为当前线程，此时线程就进入了运行状态，开始运行run函数当中的代码。
第四是阻塞状态。线程正在运行的时候，被暂停，通常是为了等待某个时间的发生（比如说某项资源就绪）之后再继续运行。sleep,suspend等方法都可以导致线程阻塞。
第五是死亡状态。如果一个线程的run方法执行结束，该线程就会死亡。对于已经死亡的线程，无法再使用start方法令其进入就绪状态。

最后附上线程的状态转移图(复习啦~其实准备找工作和考研复习的东西还是差不多的~但是就是不做题。。哈哈)：

下面这个图有点丑

下面这个图很无语

参考文章：http://blog.csdn.net/cutesource/archive/2010/08/01/5780486.aspx