锁
锁是用来锁东西的，让别人打不开也看不到！在线程中，用这个“锁”隐喻来说明一个线程在“操作”一个目标（如一个变量）的时候，如果变量是被锁住的，那么其他线程就对这个目标既“操作”不了（挂起）也无法看到目标的内容！对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一切底细的家伙而言，我找了个文档，作为附件，是并发作者的论文，不过你需要英文好一些才可以哦