上一篇博文中我大致讲解了一下lock锁与sychronized的区别及它们各自的应用优劣，那么是什么造成它们各自应用上的偏向呢，这当然取决于它们的底层实现，所以今天我们就先来看一下lock锁的底层原理吧，因为lock锁的底层实现这块内容比较多，所以sychronized我会再写一篇博文和大家分享~
Lock锁通过Java编写，与JVM实现无关。
在J.U.C.locks包中有很多lock的实现类，常用的有重入锁ReentrantLock，读写锁ReadWriteLock，它们的实现都依赖于都依赖java.util.concurrent.AbstractQueuedSynchronizer类，它们的实现过程相差不多，首先我们来看一下ReentrantLock是怎样实现的。
经过观察ReentrantLock把所有Lock接口的操作都委派到一个Sync类上，该类继承了AbstractQueuedSynchronizer：
static abstract class Sync extends AbstractQueuedSynchronizer
Sync又有两个子类：
//公平锁与非公平锁
final static class NonfairSync extends Sync
final static class FairSync extends Sync 我们来通过源码看一下ReentrantLock的调用过程，首先来看一下它的构造方法：
public ReentrantLock() {
sync = new NonfairSync();
}
很简单，次构造方法是对非公平锁构造器的引用，这也说明了ReentrantLock默认是非公平锁的，再来看一下非公平锁：
static final class NonfairSync extends Sync {
private static final long serialVersionUID = 7316153563782823691L;
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
} NonfairSync是一个静态内部类，ReentrantLock.lock函数中，会调用到NonfairSync.lock方法，首先会通过CAS方法，尝试将当前的AQS中的state字段改成从0改成1，如果修改成功的话，说明原来的状态是0，并没有线程占用锁，而且成功的获取了锁，只需要调用setExclusiveOwnerThread函将当前线程设置成持有锁的线程即可。否则，CAS操作失败之后，和普通锁一样，调用acquire(1)
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
} 了解了这些，我们再来看一下Reentrant.lock()方法的调用过程：
上面我们讲了tryAcquire()方法，接下来我们在看一下addWaiter的实现：
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode);
// Try the fast path of enq; backup to full enq on failure
Node pred = tail;
if (pred != null) {
node.prev = pred;
if (compareAndSetTail(pred, node)) {
pred.next = node;
return node;
}
}
enq(node);
return node;
}
addWaiter方法负责把当前无法获得锁的线程包装为一个Node添加到队尾，其中参数mode是独占锁还是共享锁，默认为null，独占锁。追加到队尾的动作分两步：
1）如果当前队尾已经存在(tail!=null)，则使用CAS把当前线程更新为Tail
2）如果当前Tail为null或则线程调用CAS设置队尾失败，则通过enq方法继续设置Tail
下面是enq方法：
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { // Must initialize
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
该方法就是循环调用CAS，即使有高并发的场景，无限循环将会最终成功把当前线程追加到队尾（或设置队头）。总而言之，addWaiter的目的就是通过CAS把当前线程追加到队尾，并返回包装后的Node实例。把线程包装为Node对象的主要原因，除了用Node构造供虚拟队列外，还用Node包装了各种线程状态，这些状态被精心设计为一些数字值：
- SIGNAL(-1) ：线程的后继线程正/已被阻塞，当该线程release或cancel时要重新这个后继线程(unpark)
- CANCELLED(1)：因为超时或中断，该线程已经被取消
- CONDITION(-2)：表明该线程被处于条件队列，就是因为调用了Condition.await而被阻塞
- PROPAGATE(-3)：传播共享锁
- 0：0代表无状态
简单说来，AbstractQueuedSynchronizer会把所有的请求线程构成一个CLH队列，当一个线程执行完毕（lock.unlock()）时会激活自己的后继节点，但正在执行的线程并不在队列中，而那些等待执行的线程全部处于阻塞状态，经过调查线程的显式阻塞是通过调用LockSupport.park()完成，而LockSupport.park()则调用sun.misc.Unsafe.park()本地方法，再进一步，HotSpot在Linux中中通过调用pthread_mutex_lock函数把线程交给系统内核进行阻塞。
CLH队列实现加锁的过程示意图如下：
与synchronized相同的是，这也是一个虚拟队列，不存在队列实例，仅存在节点之间的前后关系。令人疑惑的是为什么采用CLH队列呢？原生的CLH队列是用于自旋锁，但Doug Lea把其改造为阻塞锁。当有线程竞争锁时，该线程会首先尝试获得锁，这对于那些已经在队列中排队的线程来说显得不公平，这也是非公平锁的由来，与synchronized实现类似，这样会极大提高吞吐量。如果已经存在Running线程，则新的竞争线程会被追加到队尾，具体是采用基于CAS的Lock-Free算法，因为线程并发对Tail调用CAS可能会导致其他线程CAS失败，解决办法是循环CAS直至成功。
至此我们已经从源码的角度对Lock锁的实现依次进行了分析，希望大家都能对Lock锁有更深的了解，这样我们不仅可以在面试中应对自如，而且对我们在日常学习中解决高并发问题也会有很大的帮助~