Java系列笔记(6) - 并发（上）

目录

1，基本概念

2，volatile

3，atom

4，ThreadLocal

5，CountDownLatch和CyclicBarrier

6，信号量

7，Condition

8，Exchanger

 

在Java中，JVM、并发、容器、IO/NIO是我认为最重要的知识点，本章将介绍其中的并发，这也是从“会Java”到精通Java所必须经历的一步。本章承接上一张《Java系列笔记(5) - 线程》，其中介绍了Java线程的相关知识，是本章介绍内容的基础，如果对于线程不熟悉的，可以先阅读以下这篇博客了解一下。

在上一篇博客《线程》中，我们讲到了Java的内存模型，事实上，Java内存模型的建立，是围绕着一个原则来进行的：在保证线程间合作的基础上，避免线程的不良影响。而这一原则，也是本章所介绍的并发机制的最终目的。

本文大量参考了系列文章《深入浅出Java Concurrency，http://www.blogjava.net/xylz/archive/2010/07/08/325587.html》，这是一系列十分优秀也十分明晰的文章，我在学习java并发过程中，对这个系列的文章读了很多遍，这个系列的文章作者写的很容易理解而且很详尽，想要进一步理解java并发的同学，可以仔细去拜读一下《深入浅出Java Concurrency》这一系列文章。

在原来的计划中，锁和Condition等概念是放在一起的，不过限于篇幅问题，拆成两个部分，上部分是本文，讲解基本的并发概念、CountDownLatch，原子类、信号量等类，下部分集中讲锁和并发异常。

本文在编写过程中，参考、引用和总结了《深入浅出Java Concurrency》的内容以及其他Java并发书籍博客的内容，篇幅有限，所以可能总结的不到位，敬请指正。

 

1，基本概念

---

Java并发的重要性毋庸置疑，Java并发的设计目的在于3个方面：

简单，意味着程序员尽可能少的操作底层或者实现起来要比较容易；

高效，意味着耗用资源要少，程序处理速度要快；

线程安全，意味着在多线程下能保证数据的正确性。

在Java并发中，有几个常见概念，需要在讲述并发之前进行解释：

 

临界资源和临界区

临界资源是一般是一种内存资源，一个时刻只允许一个进程（在java中，是线程）访问，一个线程正在使用临界资源的时候，另一个线程不能使用。临界资源是非可剥夺性资源，即使是操作系统（或JVM）也无法阻止这种资源的独享行为。

临界区是一种进程中范文临界资源的那段程序代码，注意，是程序代码，不是内存资源了，这就是临界资源与临界区的区别。我们规定临界区的使用原则（也即同步机制应遵循的准则）十六字诀：“空闲让进，忙则等待，有限等待，让权等待”–strling。让我们分别来解释一下：

（1）空闲让进：临界资源空闲时一定要让进程进入，不发生“互斥礼让”行为。

（2）忙则等待：临界资源正在使用时外面的进程等待。

（3）有限等待：进程等待进入临界区的时间是有限的，不会发生“饿死”的情况。

（4）让权等待：进程等待进入临界区是应该放弃CPU的使用。

并发

狭义的只就Java而言，Java多线程在访问同一资源时，出现竞争的问题，叫做并发问题，Java并发模型是围绕着在并发过程中如何处理原子性、可见性、有序性这3个特征来设计的。

 

线程安全

如果一个操作序列，不考虑耗时和资源消耗，在单线程执行和多线程执行的情况下，最终得到的结果永远是相同的，则这个操作序列叫做线程安全的。

如果存在不相同的概率，则就是非线程安全的。

 

原子性（Atomicity）

如果一个操作时不可分割的，那就是一个原子操作，也叫这个操作具有原子性。相反的，一个操作时可以分割的（如a++，它实际上是a=a+1），则就是非原子操作；原子操作是线程安全的，非原子操作都是非线程安全的，但是我们可以通过同步技术（lock）或同步数据模型（Concurrent容器等）把非原子操作序列变成线程安全的原子操作。

事实上，java并发主要研究的就是3个方面的问题：

1，怎么更好的使用原子操作；

2，怎么把非原子操作变得线程安全；

3，怎么提高原子操作和非原子操作的效率并减少资源消耗。

 

可见性（Visibility）

一个变量被多个线程共享，如果一个线程修改了这个变量的值，其它线程能够立即得知这个修改，则我们称这个修改具有可见性。

（可参考上一章《Java系列笔记(5)-线程》中的Java线程内存模型部分），Java线程内存模型的设计，是每个线程拥有一份自己的工作内存，当变量修改之后，将新值同步到主内存。但是对于普通变量而言，这种同步，并不能保证及时性，所以可能出现工作内存以及更改，主内存尚未同步的情况。

Java中，最简单的方法是使用volatile实现强制同步，它的实现方式是保证了变量在修改后立即同步到主内存，且每次使用该变量前，都先从主内存刷新该值。

另外，可以采用synchronized或final关键字实现可见性；

synchronized的实现原理在于，一个变量如果要执行unlock操作，必须先把改变量同步到主内存中（执行store和write）。因此一个变量如果被synchronized实现强制同步，则即使不用volatile，也可以实现强制可见性。

final的实现原理在于，一个变量被final修饰，则其值（或引用地址）不可以再被修改，所以其它线程如果能看到，也只是能看到这个变量的这个唯一值（对于对象而言，是唯一引用）。

需要注意，一个操作被保证了可见性，并不一定能保证原子性，比如：

volatile int a;
a++;

在上面这段代码中，a是满足可见性的，但是a++仍然不是原子性操作。当有多个线程执行a++时，仍然存在并发问题。

 

有序性（Ordering）

Java线程的有序性，表现为两个方面：

在一个线程内部观察，所有操作都是有序的，所有指令按照“串行（as-if-serial，字面意思是“像排了序一样”，as-if-serial的真正含义是不管怎么重排序，一个单线程程序的执行结果都必须相同）” 的方式执行。

 

在线程间观察，也就是从某个线程观察另一个线程，则所有其他线程都可以交叉并行执行，是正序的，唯一例外的是被同步方法、同步块、volatile等字段修饰的强制同步的代码，需要在线程间保持有序。

 

注：关于指令重排序、as-if-serial、happens-before等，可以参考上一章《Java系列笔记(5)-线程》，也可以参考网上的众多资料，这里不再叙述。

 

JUC

java.util.concurrent包，这个包是从JDK1.5开始引入的，在此之前，这个包独立存在着，它是由Doug Lea开发的，名字叫backport-util-concurrent，在1.5开始引入java，命名路径为java.util.concurrent，其中的基本实现方式，也有所改变。主要包括以下类：（来源于：深入浅出Java Concurreny（http://www.blogjava.net/xylz/archive/2010/06/30/324915.html））

 

JNI

Java native interface，java本地方法接口，由于Java本身是与平台无关的，所以在性能等方面有可能存在影响（虽然随着java的发展，这种情况很少），为了解决这种问题，使用C/C++编写了JNI接口，在java中可以直接调用这些代码的产生的机器码，从而避免严重影响性能的代码段。关于JNI，可以参考这篇文章：http://www.cnblogs.com/mandroid/archive/2011/06/15/2081093.html

 

CAS

CAS，compare and swap，比较和替换（也有人直接理解为compare and set，其实是一样的）。CAS是一种乐观锁做法，而且整个JUC的实现都是基于CAS机制的。

如果直接用synchronized加锁，这是一种悲观锁做法，所谓悲观锁，就是悲观的认为线程是绝对不安全的，必须保证在swap值之前，没有任何其它线程操作当前值。synchronized是一种独占锁，性能受限于这种悲观策略。这一点将在后面详述。

而CAS是一种乐观锁机制，所谓乐观锁，就是相信在compare 和swap之间，被其它线程影响的可能性不大，只要compare校验通过，就可以进行swap。

在Java中，compareAndSet的基本代码如下：

1 public final boolean compareAndSet(int expect, int update) {
2   return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
3 }

 

从代码中看，java的compareAndSet使用使用JNI中的unsafe接口来实现的，这是因为，现代CPU基本都提供了特殊的指令，能够做到自动更新共享数据的同时，检测其它线程的干扰，也就是说，CPU本身提供了compareAndSet功能。所以才能提供JNI的CAS接口。

有了JNI的CAS接口，基于该接口的JUC就能获得更高性能。

在 Intel 处理器中，比较并交换通过指令cmpxchg实现。比较是否和给定的数值一致，如果一致则修改，不一致则不修改。

 

AQS

AbstractQueuedSynchronizer，简称AQS，是J.U.C最复杂的一个类。这个类是CountDownLatch/FutureTask /ReentrantLock/RenntrantReadWriteLock/Semaphore的基础，是Lock和Executor实现的前提。参考：（http://www.blogjava.net/xylz/archive/2010/07/06/325390.html）

非阻塞算法

任何一个线程的失败或挂起不应该影响其他线程的失败或挂起的算法叫做非阻塞算法。现代CPU能够提供非阻塞功能，它可以在自动更新共享数据的同时，检查其它线程的干扰。

 

2，volatile

---

正如前面所述，java中volatile字段的作用是保证并发过程中某个变量的可见性。而volatile保证可见性的方法如下：

1，Java内存模型不会对volatile指令进行重排序，从而保证对volatile变量的执行顺序，永远是按照其出现顺序执行的。重排序的依据是happens-before法则，happens-before法则共8条，其中有一条与volatile相关，就是：“对volatile字段的写入操作happens-before于每一个后续的同一个字段的读操作”。

注：happens-before法则：http://www.blogjava.net/xylz/archive/2010/07/03/325168.html

2，volatile变量不会被缓存在寄存器中（只有拥有线程可见）或者其他对CPU不可见的地方，每次总是从主存中读取volatile变量的结果。

不过需要注意的是：volatile字段只能保证可见性，不能保证原子性，也不能保证线程安全。

 

volatile的工作原理

下面这段话摘自《深入理解Java虚拟机》：

　　“观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现，加入volatile关键字时，会多出一个lock前缀指令”

　　lock前缀指令实际上相当于一个内存屏障（也成内存栅栏），内存屏障会提供3个功能：

　　1）它确保指令重排序时不会把其后面的指令排到内存屏障之前的位置，也不会把前面的指令排到内存屏障的后面；即在执行到内存屏障这句指令时，在它前面的操作已经全部完成；

　　2）它会强制将对缓存的修改操作立即写入主存；

　　3）如果是写操作，它会导致其他CPU中对应的缓存行无效。

上面的说法解释了volatile的工作原理的起源。不过，建议大家复习一下本系列文章第3章JVM内存分配和第5章线程的内容，来理解下面的解释。与前面这两章中宏观的讲解内存分配和线程内存模型相区别，下面的部分专注于解析java内存模型和volatile的工作原理，但也能更好的理解以前的知识：

注：下面的图参考了：http://www.cnblogs.com/aigongsi/archive/2012/04/01/2429166.html，其中描述了内存模型的6种操作，比上一章中介绍的8种操作少了lock、unlock 2 种，这6种操作都是原子性的。

 

在上图中，如果是普通变量：

1，变量值从主内存（在堆中）load到本地内存（在当前线程的栈桢中）；

2，之后，线程就不再和该变量在主内存中的值由任何关系，而是直接操作在副本变量上（这样速度很快），这时，如果主存中的count或本地内存中的副本发生任何变化，都不会影响到对方，也正是这个原因导致并发情况下出现数据不一致；

3，在修改完的某个时刻（线程退出之前），自动把本地内存中的变量副本值回写到对象在堆中的对应变量。

 

这6步操作中：

read和load是将主存变量加载到当前本地内存；

use和assign是执行线程代码，改变副本值，可以多次执行；

store和write是用本地内存回写到主存；

 

如果是volatile修饰的变量：

volatile仍然在执行一个从主存加载到工作内存，并且将变更的值写回主存的操作，但是：

1，volatile保证每次读取该变量前，都判断当前值是否已经失效（即是否已经与主存不一致），如果已经失效，则从主存load最新的变量；

2，volatile保证每次对该变量做出修改时，都立即写入主存；

 

需要注意的是，虽然volatile保证了上面的特性，但是它只是保证了可见性，却没有保证原子性，也就是说，read-load-use-assign-store-write，这些操作序列组合起来仍然是非原子操作。举个例子：

共享变量当前在主存中的值为count=10;线程1和线程2都对该值进行自增操作，按如下步骤进行：

1，线程1和2都读取最新值，得到值为count=10；

2，线程1被阻塞；

3，线程2执行自增，写回count=11；

4，线程1唤醒，由于之前已经完成了读取变量的操作，所以这里直接进行自增。于是也自增到11，回写主存，最终count=11；

与我们期望的两次自增count=12冲突；

目前来说，要保证原子性，只能通过synchronized、Lock接口、Atomic*来实现。

 

说了这么多，有同学可能会问，为什么volatile这也不行那也不行，陷阱这么多，我们还要用它呢？

volatile相对于synchronized，最大的好处是某些情况下它的性能高，而且使用起来直观简便。而且，如果你的“代码本身能保证原子性”，那么用volatile是个不错的选择：

这里所说的代码本身能保证原子性，是指：

1，对变量的写操作，不依赖于当前的值（就是说，不会先读取当前值，然后在当前值的基础上进行改变，比如，不是自增，而是赋值）；

2，变量没有包含在其它变量的不变式中（这一点不是很好理解，可以参考这里：http://www.ibm.com/developerworks/cn/java/j-jtp06197.html）

 

一个最常见的volatile的应用场景是boolean的共享状态标志位，或者单例模式的双重检查锁（参考Java并发编程：volatile关键字解析，http://www.cnblogs.com/dolphin0520/p/3920373.html）

 

另外，有一个关于volatile的常见的坑就是：从上面的描述可以看出，volatile对于基本数据类型（值直接从主内存向工作内存copy）才有用。但是对于对象来说，似乎没有用，因为volatile只是保证对象引用的可见性，而对对象内部的字段，它保证不了任何事。即便是在使用ThreadLocal时，每个线程都有一份变量副本，这些副本本身也是存储在堆中的，线程栈桢中保存的仍然是基本数据类型和变量副本的引用。

所以，千万不要指望有了volatile修饰对象，对象就会像基本数据类型一样整体呈现原子性的工作了。

事实上，如果一个对象被volatile修饰，那么就表示它的引用具有了可见性。从而使得对于变量引用的任何变更，都在线程间可见。

这一点在后面将要介绍的AtomicReference中就有应用。

 

3，Atom

---

java中，可能有一些场景，操作非常简单，但是容易存在并发问题，比如i++，此时，如果依赖锁机制，可能带来性能损耗等问题，于是，如何更加简单的实现原子性操作，就成为java中需要面对的一个问题。

java中的atom操作，比如AtomicInteger,AtomicLong,AtomicBoolean,AtomicReference,AtomicIntegerArray/AtomicLongArray/AtomicReferenceArray；这些操作中旺旺提供一些原子化操作，比如incrementAndGet（相当于i++），compareAndSet（安全赋值）等，相关方法和用法就不再赘述，网上有很多类似资料，或者直接读源代码也很容易懂。

在backport-util-concurrent没有被引入java1.5并成为JUC之前，这些原子类和原子操作方法，都是使用synchronized实现的。不过JUC出现之后，这些原子操作基于JNI提供了新的实现，以AtomicInteger为例，看看它是怎么做到的：

如果是读取值，很简单，将value声明为volatile的，就可以保证在没有锁的情况下，数据是线程可见的：

1     private volatile int value;public final int get() {
2       return value;
3     }

 

那么，涉及到值变更的操作呢？以AtomicInteger实现：++i为例：

1     public final int incrementAndGet() {
2      for (;;) {
3        int current = get();
4        int next = current + 1;  
5        if (compareAndSet(current, next))  
6          return next;  
7        }
8     } 

 

在这里采用了CAS操作，每次从内存中读取数据然后将此数据和+1后的结果进行CAS操作，如果成功就返回结果，否则重试直到成功为止。

而这里的comparAndSet(current,next)就是前面介绍CAS的时候所说的依赖JNI实现的乐观锁做法：

    public final boolean compareAndSet(int expect, int update) {  
       return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
    }

 

除了基本数据类型的原子化操作以外，JUC还提供了数组的原子化、引用的原子化，以及Updater的原子化，分别为：

下面主要介绍这3类原子化操作为什么要原子化以及分别是怎么实现的。

 

数组原子化

注意，Java中Atomic*Array，并不是对整个数组对象实现原子化（也没有必要这样做），而是对数组中的某个元素实现原子化。例如，对于一个整型原子数组，其中的原子方法，都是对每个元素的：

1 public final int getAndDecrement(int i) {
2       while (true) {
3        int current = get(i);
4        int next = current - 1;
5        if (compareAndSet(i, current, next))
6             return current;
7       }
8 } 

 

引用原子化

有些同学可能会疑惑，引用的操作本身不就是原子的吗？一个对象的引用，从A切换到B，本身也不会出现非原子操作啊？这种想法本身没有什么问题，但是考虑下嘛的场景：对象a，当前执行引用a1，线程X期望将a的引用设置为a2，也就是a=a2，线程Y期望将a的引用设置为a3，也就是a=a3。

如果线程X和线程Y都不在意a到底是从哪个引用通过赋值改变过来的，也就是说，他们不在意a1->a2->a3，或者a1->a3->a2，那么就完全没有关系。

但是，如果他们在乎呢？

X要求，a必须从a1变为a2，也就是说compareAndSet(expect=a1,setValue=a2)；Y要求a必须从a1变为a3，也就是说compareAndSet（expect=a1，setValue=a3）。如果严格遵循要求，应该出现X把a的引用设置为a2后，Y线程操作失败的情况，也就是说：

X：a==a1--> a=a2;

Y：a!=a1 --> Exception；

但是如果没有原子化，那么Y会直接将a赋值为a3，从而导致出现脏数据。

 

这就是原子引用AtomicReference存在的原因。

1      public final V getAndSet(V newValue) {
2            while (true) {
3                V x = get();
4                if (compareAndSet(x, newValue))
5                    return x;
6            }
7        }

注意，AtomicReference要求引用也是volatile的。

Updater原子化

其它几个Atomic类，都是对被volatile修饰的基本数据类型的自身数据进行原子化操作，但是如果一个被volatile修饰的变量本身已经存在在类中，那要如何提供原子化操作呢？比如，一个Person，其中有个属性为age，private volatile int age；，如何对age提供原子化操作呢？

1 private AtomicIntegerFieldUpdater updater = AtomicIntegerFieldUpdater.newUpdater(Person.class, "age");  
2 updater.getAndIncrement(5);//加5岁
3 updater.compareAndSet(person, 30, 35)//如果一个人的年龄是30，设置为35。

 

4，ThreadLocal

---

对于多线程的Java程序而言，难免存在多线程竞争资源的情况。对于竞争的资源，解决的方式往往分为以时间换空间或以空间换时间两种方式。

1，后者的做法是将一份资源复制成多份，占用多份空间，但是每个线程自己访问自己的资源，从而消除竞争，这种做法是ThreadLocal的做法，它虽然消除了竞争，但它是通过数据隔离的方法实现的，所以被隔离的各份数据是无法同步的，本节就要介绍这种做法。

2，也有很多资源是无法复制成多份或者不适合复制成多份的，如打印机资源。因此以时间换空间的做法就是只有一份资源，大家按照一定的顺序串行的去访问这个资源。这种方式的主要做法，就是在资源上加锁，加锁的方法，将在后面第9节介绍。

 

示例

下面通过一个典型的ThreadLocal的应用案例作为入口，来分析ThreadLocal的原理和用法（更详细代码请参考《Java并发编程：深入剖析ThreadLocal》http://www.cnblogs.com/dolphin0520/p/3920407.html）：

设想下面的场景：

编写一个数据库连接器（或 http session管理器），要求多个线程能够连接和关闭数据库，优先考虑下面的方案：

 1     class ConnectionManager {
 2        private static Connection connect = null;
 3        public static Connection openConnection() {
 4            if(connect == null){
 5                connect = DriverManager.getConnection();
 6            }
 7            return connect;
 8        }
 9        public static void closeConnection() {
10            if(connect!=null)
11                connect.close();
12        }
13     }

这个方案中，多个线程公用ConnectionManager.openConnection()和ConnectionManager.closeConnnection()，由于没有同步控制，所以很容易出现并发问题，比如，同时创建了多个连接，或者线程1openConnection时，线程2恰好在执行closeConnection。

解决这个问题有两种方案：

1，对connectionManager中openConnection和closeConection加synchronized强制同步。这种方案解决了并发，却带来了新问题，由于synchronized导致了同一只可只有一个线程能访问被锁对象，所以其它线程只能等待。

2，去掉ConnectionManager中的static，使得每次访问Connectionmanager，都必须new一个对象，这样每个线程都用自己的独立对象，相互不影响。eg：

1     public void insert() {
2            ConnectionManager connectionManager = new ConnectionManager();
3            Connection connection = connectionManager.openConnection();
4            
5            //使用connection进行操作
6            
7            connectionManager.closeConnection();
8     }

 

这个确实解决了并发，并且也可以多线程同步执行，但是它存在严重的性能问题，每执行一次操作，就需要new一个对象然后再销毁。

ThreadLocal的引入，恰当的解决了上面的问题，ThreadLocal不是线程，它是一种变量，不过，它是线程变量的副本，它是一个泛型对象，例如，线程A创建时，初始化了一个对象user，那么ThreadLocal userLocal就是user在线程A中的一个副本，userLocal中的值在初始时与user相同，但是在线程A运行过程中，userlocal的任何变化不会同步到user上，不会影响user的值。

如果采用ThreadLocal，上面的数据库连接管理器问题的解决方案是：

 1     class ConnectionManager {
 2         private static ThreadLocal connectionHolder = new ThreadLocal() {
 3              public Connection initialValue() {
 4         return DriverManager.getConnection(DB_URL);
 5              }
 6         };
 7         public static Connection getConnection() {
 8              return connectionHolder.get();
 9         }
10        
11        public static void closeConnection() {
12            if(connectionHolder.get()!=null)
13               connectionHolder.get().close();
14        }
15     }

 

ThreadLocal的方法

ThreadLocal提供的方法很简单，主要有：

1. public T get() { }
2. public void set(T value) { }
3. public void remove() { }
4. protected T initialValue() { }

 

ThreadLocal的原理

分析ThreadLocal的源代码（分析过程参考这里：http://www.cnblogs.com/dolphin0520/p/3920407.html），可得，ThreadLocal的原理是：

1，在每个线程Thread内部有一个ThreadLocal.ThreadLocalMap类型的成员变量threadLocals，这个threadLocals就是用来存储实际的变量副本的，键值为当前ThreadLocal变量，value为变量副本（即T类型的变量）。

2，初始时，在Thread里面，threadLocals为空，当通过ThreadLocal变量调用get()方法或者set()方法，就会对Thread类中的threadLocals进行初始化，并且以当前ThreadLocal变量为键值，以ThreadLocal要保存的副本变量为value，存到threadLocals。

3，注意，一般在get之前，需要先执行set()，以保证threadlocals中有值，如果在get()之前，没有执行过set()，则ThreadLocal会自动调用setInitialValue()方法，setInitialValue()的源代码是这样的：

 1         private T setInitialValue() {
 2            T value = initialValue();
 3            Thread t = Thread.currentThread();
 4            ThreadLocalMap map = getMap(t);
 5            if (map != null)
 6                map.set(this, value);
 7            else
 8                createMap(t, value);
 9            return value;
10        }

 

它先取出当前线程的ThreadLocalMap，即threadLocals变量，然后将value set进去，所以，如果没有提前执行过set方法，initialValue()默认返回的又是null，所以可能导致运行过程中出现NPE。建议最好在声明ThreadLocal变量时，重写initialValue()方法，这样即使没有提前执行set，也能有个初始值（如前面ConnectionHolder中的代码）。

4，然后在当前线程里面，如果要使用副本变量，就可以通过get方法在threadLocals里面查找。

ThreadLocal泛型的变量类型，不能是基本数据类型，只能是类，如果一定要将基本上数据类型做泛型参数，则可以采用Integer、Long、Double等类。

 

使用ThreadLocal的步骤

1，、在多线程的类（如ThreadDemo类）中，创建一个ThreadLocal