有关Java 5.0+ 并发包的探讨-3-0

锁

锁是用来锁东西的，让别人打不开也看不到！在线程中，用这个“锁”隐喻来说明一个线程在“操作”一个目标（如一个变量）的时候，如果变量是被锁住的，那么其他线程就对这个目标既“操作”不了（挂起）也无法看到目标的内容！对Java并发包，锁的实现基本在java.util.concurrent.locks包中，说“基本”是因为，在java.util.concurrent中还有CountDownLatch(可以看成带计数器的锁)，CyclicBarrier，Semaphore（类似于信号量，但是也可以看成一个特殊的锁）。这里我们先以java.util.concurrent.locks包为主来讨论锁的问题吧。我们来看看java.util.concurrent.locks包中到底有多少“锁”，主要是这样几个接口及其实现：

Lock----------

                  |---------ReadLock //读锁

                  |------ReentrantLock  //并发锁

                  |------WriteLock //写锁

ReadWriteLock----------------

                     |-------------ReentrantReadWriteLock //并发读写锁

以上：Lock和ReadWriteLock都是接口，是锁行为的契约，其余部分都是实现，而ReadLock和WriteLock是作为ReentrantReadWriteLock的静态内部类存在，不能直接使用，也就是他们是ReentrantReadWriteLock的支持类，不是向外提供给外部程序使用的！

 

另外还发现有这样抽象类：

AbstractOwnableSynchronizer---------

                                                         |----------AbstractQueuedLongSynchronizer

                                                         |-------AbstractQueuedSynchronizer

这几个都是抽象类，但是没有明显的实现！没有实现？其实是所有的Lock在其实现时使用的基础结构，并且以来它们实现了锁的机制，只要我们先把这几个抽象类的实现逻辑搞清楚，Lock的原理就比较清楚了，理解了原理，使用Lock时就有的放矢了。

另外包中还有condition接口：

Condition------------

                             |--------- ConditionObject

这个接口和实现是干什么的？是用来实现“竞赛条件”的，提供更加细粒度的线程锁控制，也就是在某个条件下加锁等操作。

 

好了，java.util.concurrent.locks 中的基本“布局”和“结构”现在已经比较清楚了，下面我们将从AbstractOwnableSynchronizer抽象类开始讲，这是整个Lock的核心，明白其实现能让你了解如何“准确”的使用锁，而不是仅仅“知道电视机的按钮而不知道里面的原理”，毕竟我们是搞开发的，对原理更应该重视，你说是吧？

AbstractOwnableSynchronizer：

它依靠于CLH队列来实现锁的机制

     *      +------+  prev +-----+       +-----+

     * head |      | <---- |     | <---- |     |  tail

     *      +------+       +-----+       +-----+

采用的CHL模型采用下面的算法完成FIFO的入队列和出队列过程,而正是入队和出队的实现“模拟”了“锁”的效用！

对于入队列(enqueue)：采用CAS操作，每次比较尾结点是否一致，然后插入的到尾结点中。

 

do {

 

        pred = tail;

 

}while ( !compareAndSet(pred,tail,node) );

对于出队列(dequeue):由于每一个节点也缓存了一个状态，决定是否出队列，因此当不满足条件时就需要自旋等待，一旦满足条件就将头结点设置为下一个节点。

 

while (pred.status != RELEASED) ;

 

head  = node;

 

有三个核心字段：

 

private volatile int state;

 

private transient volatile Node head;

 

private transient volatile Node tail;

其中state描述的有多少个线程取得了锁，对于互斥锁来说state<=1。head/tail加上CAS()操作就构成了一个CHL的FIFO队列。下面是Node节点的属性。

 

volatile int waitStatus; 节点的等待状态，一个节点可能位于以下几种状态：

 

CANCELLED = 1： 节点操作因为超时或者对应的线程被interrupt。节点不应该不留在此状态，一旦达到此状态将从CHL队列中踢出。

SIGNAL = -1： 节点的继任节点是（或者将要成为）BLOCKED状态（例如通过LockSupport.park()操作），因此一个节点一旦被释放（解锁）或者取消就需要唤醒（LockSupport.unpack()）它的继任节点。

CONDITION = -2：表明节点对应的线程因为不满足一个条件（Condition）而被阻塞。

0： 正常状态，新生的非CONDITION节点都是此状态。

非负值标识节点不需要被通知（唤醒）。

volatile Node prev;此节点的前一个节点。节点的waitStatus依赖于前一个节点的状态。

 

volatile Node next;此节点的后一个节点。后一个节点是否被唤醒（uppark()）依赖于当前节点是否被释放。

 

volatile Thread thread;节点绑定的线程。

 

Node nextWaiter;下一个等待条件（Condition）的节点，由于Condition是独占模式，因此这里有一个简单的队列来描述Condition上的线程节点。

以上只是一个简单的描述吧，只要知道AbstractOwnableSynchronizer的核心是一个CHL队列，而AbstractOwnableSynchronizer是所有Lock的基础，在讲具体Lock的时候，我将“回溯”到AbstractOwnableSynchronizer，凡是具体Lock调用AbstractOwnableSynchronizer的方法的时候，我将具体讲一下其实现，并对应着Lock对应方法的实现，这样就能彻底搞清楚具体Lock的原理了，也就能在使用时游刃有余了。

对于那些真正需要探知Lock一切底细的家伙而言，我找了个文档，作为附件，是并发作者的论文，不过你需要英文好一些才可以哦