3. juc中的锁源码分析
　　juc中的锁分两种， 1. 可重入锁; 2. 读写锁. 两者都用到了一个通用组件 AbstractQueuedSynchronizer. 先从它说起
　　3.1 AbstractQueuedSynchronizer
　　利用了一个int来表示状态， 内部基于FIFO队列及UnSafe的CAS原语作为操纵状态的数据结构， AQS以单个 int 类型的原子变量来表示其状态，定义了4个抽象方法（ tryAcquire(int)、tryRelease(int)、tryAcquireShared(int)、tryReleaseShared(int)，前两个方法用于独占/排他模式，后两个用于共享模式 ）留给子类实现，用于自定义同步器的行为以实现特定的功能。这方面的介绍大家看一下资料2， 描述非常清楚
　　引用资料2中的一段话:
　　同步器是实现锁的关键，利用同步器将锁的语义实现，然后在锁的实现中聚合同步器。可以这样理解：锁的API是面向使用者的，它定义了与锁交互的公共行为，而每个锁需要完成特定的操作也是透过这些行为来完成的（比如：可以允许两个线程进行加锁，排除两个以上的线程），但是实现是依托给同步器来完成；同步器面向的是线程访问和资源控制，它定义了线程对资源是否能够获取以及线程的排队等操作。锁和同步器很好的隔离了二者所需要关注的领域，严格意义上讲，同步器可以适用于除了锁以外的其他同步设施上（包括锁）。
　　3.2 ReentrantLock
　　可重入锁， 支持公平和非公平策略(FairSync/NonFairSync)， 默认非公平锁， 内部Sync继承于AbstractQueuedSynchronizer.
　　两者代码区别是:
　　FairSync 代码中对于尝试加锁时(tryAcquire)多了一个判断方法， 判断等待队列中是否还有比当前线程更早的， 如果为空，或者当前线程线程是等待队列的第一个时才占有锁
if (c == 0) {
if (!hasQueuedPredecessors() && //是这里
compareAndSetState(0， acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
public final boolean hasQueuedPredecessors() {
// The correctness of this depends on head being initialized
// before tail and on head.next being accurate if the current
// thread is first in queue.
Node t = tail; // Read fields in reverse initialization order
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
　　3.3 ReentrantReadWriteLock
　　3.3.1 引子
　　可重入的读写锁， 首先我想到的是它的适用场景， 它与volatile有何区别， 又有何优势呢?
　　volatile只能保证可见性， 在1写N读的情况下， 使用它足够了. 但是如何N写N读， 如何保证数据一致性而又减少并行度的损失呢? 要看ReentrantReadWriteLock了.
　　3.3.2 源码分析:
　　读锁
public static class ReadLock implements Lock， java.io.Serializable  {
private final Sync sync;
protected ReadLock(ReentrantReadWriteLock lock) {
sync = lock.sync;
}
public void lock() {
sync.acquireShared(1);//共享锁
}
public void lockInterruptibly() throws InterruptedException {
sync.acquireSharedInterruptibly(1);
}
public  boolean tryLock() {
return sync.tryReadLock();
}
public boolean tryLock(long timeout， TimeUnit unit) throws InterruptedException {
return sync.tryAcquireSharedNanos(1， unit.toNanos(timeout));
}
public  void unlock() {
sync.releaseShared(1);
}
public Condition newCondition() {
throw new UnsupportedOperationException();
}
}
　　写锁
public static class WriteLock implements Lock， java.io.Serializable  {
private final Sync sync;
protected WriteLock(ReentrantReadWriteLock lock) {
sync = lock.sync;
}
public void lock() {
sync.acquire(1);//独占锁
}
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
public boolean tryLock( ) {
return sync.tryWriteLock();
}
public boolean tryLock(long timeout， TimeUnit unit) throws InterruptedException {
return sync.tryAcquireNanos(1， unit.toNanos(timeout));
}
public void unlock() {
sync.release(1);
}
public Condition newCondition() {
return sync.newCondition();
}
public boolean isHeldByCurrentThread() {
return sync.isHeldExclusively();
}
public int getHoldCount() {
return sync.getWriteHoldCount();
}
}
　　WriteLock是一个独占锁，这和ReentrantLock里面的实现几乎相同，都是使用了AQS的acquire/release操作。当然了在内部处理方式上与ReentrantLock还是有一点不同的。对比清单1和清单2可以看到，ReadLock获取的是共享锁，WriteLock获取的是独占锁。
　　AQS中有一个state字段（int类型，32位）用来描述有多少线程获持有锁。在独占锁的时代这个值通常是0或者1（如果是重入的是重入的次数），在共享锁的时代是持有锁的数量。在上一节中谈到，ReadWriteLock的读、写锁是相关但是又不一致的，所以需要两个数来描述读锁（共享锁）和写锁（独占锁）的数量。显然现在一个state不够用了。于是在ReentrantReadWrilteLock里面将这个字段一分为二，高位16位表示共享锁的数量，低位16位表示独占锁的数量（或者重入数量）。2^16-1=65536，所以共享锁和独占锁的数量大只能是65535。
　　3.3.3 写入锁分析:
　　持有锁线程数非0（c=getState()不为0），如果写线程数（w）为0（那么读线程数不为0）或者独占锁线程（持有锁的线程）不是当前线程返回失败，或者写入锁的数量（其实是重入数）大于65535抛出一个Error异常
　　如果当且写线程数位0（那么读线程也应该为0，因为步骤1已经处理c!=0的情况），并且当前线程需要阻塞那么返回失败；如果增加写线程数失败也返回失败
　　设置独占线程（写线程）为当前线程，返回true。
protected final boolean tryAcquire(int acquires) {
Thread current = Thread.currentThread();
int c = getState();
int w = exclusiveCount(c);
if (c != 0) {
if (w == 0 || current != getExclusiveOwnerThread())
return false;
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
}
if ((w == 0 && writerShouldBlock(current)) ||
!compareAndSetState(c， c + acquires))
return false;
setExclusiveOwnerThread(current);
return true;
}
　　3.3.4 列出读写锁几个特性:
　　重入性
　　读写锁允许读线程和写线程按照请求锁的顺序重新获取读取锁或者写入锁。当然了只有写线程释放了锁，读线程才能获取重入锁。 写线程获取写入锁后可以再次获取读取锁，但是读线程获取读取锁后却不能获取写入锁。 另外读写锁多支持65535个递归写入锁和65535个递归读取锁。
　　锁降级
　　写线程获取写入锁后可以获取读取锁，然后释放写入锁，这样从写入锁变成了读取锁，从而实现锁降级的特性。
　　锁升级
　　读取锁是不能直接升级为写入锁的。因为获取一个写入锁需要释放所有读取锁，所以如果有两个读取锁视图获取写入锁而都不释放读取锁时会发生死锁。
　　锁获取中断
　　读取锁和写入锁都支持获取锁期间被中断。这个和独占锁一致。
　　条件变量
　　写入锁提供了条件变量(Condition)的支持，这个和独占锁一致，但是读取锁却不允许获取条件变量，将得到一个UnsupportedOperationException异常。