文章转载自：https://blog.csdn.net/Luxia_24/article/details/52403033（为了简化阅读难度，本文只挑选了大部分内容进行转载，并对代码进行了注释，更加详细的内容可以参考原文）
Lock锁机制的实现原理
Lock锁机制存在于Java语言层面，可以通过编程进行控制。
Lock机制加锁过程
主要通过3个方法：
1、Sync.nonfairTryAcquire()方法
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) { //判断锁是否被占用
if (compareAndSetState(0, acquires)) { //CAS更新状态
setExclusiveOwnerThread(current); //占用锁
return true;
}
}
//锁已经被占用，则判断占用的是不是当前线程。（重入的实现）
//如果是当前线程，则通过setState使状态量加1
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
//如果不是当前线程，则直接返回false。
return false;
} 其中getState()返回的是一个volatile的int型变量：
/**
* The synchronization state.
*/
private volatile int state;volatile确保了state的可见性，消除了指令重排序。
该方法的功能是，判断当前锁是否被占用（getState方法返回的状态是否等于0），如果没被占用，则通过CAS将状态设置为1，表示占用。如果被占用，则继续判断是不是本线程在占用，是则重入，状态加1，每次线程重入该锁都会+1，每次unlock都会-1，但为0时释放锁。否则返回false。
2、 AbstractQueuedSynchronizer.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)) { //通过CAS将该节点设置为tail节点
pred.next = node;
return node; //返回新的尾节点，并退出该方法
}
}
//入队不成功，调用enq(node)方法继续尝试
enq(node);
return node;
} 其中参数mode是独占锁还是共享锁，默认为null，独占锁。追加到队尾的动作分两步：
如果当前队尾已经存在(tail!=null)，则使用CAS把当前线程更新为Tail。
如果当前Tail为null或则线程调用CAS设置队尾失败，则通过enq方法继续设置Tail
enq(node)方法源码如下：
private Node enq(final Node node) {
for (;;) { //死循环，知道将node入队成功
Node t = tail;
if (t == null) { // Must initialize
Node h = new Node(); // Dummy header 无用的头节点
h.next = node;
node.prev = h;
if (compareAndSetHead(h)) { //调用CAS将自己设置为第一个有效节点
tail = node;
return h;
}
}
else {
node.prev = t;
if (compareAndSetTail(t, node)) { //继续尝试将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代表无状态
3、AbstractQueuedSynchronizer.acquireQueued
acquireQueued的主要作用是把已经追加到队列的线程节点（addWaiter方法返回值）进行阻塞，但阻塞前又通过tryAccquire重试是否能获得锁，如果重试成功能则无需阻塞，直接返回。
final boolean acquireQueued(final Node node, int arg) {
try {
boolean interrupted = false;
for (;;) {
final Node p = node.predecessor();
if (p == head && tryAcquire(arg)) {
setHead(node);
p.next = null; // help GC
return interrupted;
}
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
interrupted = true;
}
} catch (RuntimeException ex) {
cancelAcquire(node);
throw ex;
}
} 仔细看看这个方法是个无限循环，感觉如果p == head && tryAcquire(arg)条件不满足循环将永远无法结束，当然不会出现死循环，奥秘在于第12行的parkAndCheckInterrupt会把当前线程挂起，从而阻塞住线程的调用栈。
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
} 如前面所述，LockSupport.park最终把线程交给系统（Linux）内核进行阻塞。当然也不是马上把请求不到锁的线程进行阻塞，还要检查该线程的状态，比如如果该线程处于Cancel状态则没有必要.
Lock解锁原理
请求锁不成功的线程会被挂起在acquireQueued方法的第12行，12行以后的代码必须等线程被解锁锁才能执行，假如被阻塞的线程得到解锁，则执行第13行，即设置interrupted = true，之后又进入无限循环。
从无限循环的代码可以看出，并不是得到解锁的线程一定能获得锁，必须在第6行中调用tryAccquire重新竞争，因为锁是非公平的，有可能被新加入的线程获得，从而导致刚被唤醒的线程再次被阻塞，这个细节充分体现了“非公平”的精髓。通过之后将要介绍的解锁机制会看到，第一个被解锁的线程就是Head，因此p == head的判断基本都会成功。
解锁代码相对简单，主要体现在AbstractQueuedSynchronizer.release和Sync.tryRelease方法中：
AbstractQueuedSynchronizer.release
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h); //唤醒第一个线程
return true;
}
return false;
} Sync.tryRelease
protected final boolean tryRelease(int releases) {
int c = getState() - releases; //解一层锁
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null); //释放线程
}
setState(c); //更新状态
return free;
} tryRelease与tryAcquire语义相同，把如何释放的逻辑延迟到子类中。
tryRelease语义很明确：如果线程多次锁定，则进行多次释放，直至status==0则真正释放锁，所谓释放锁即设置status为0，因为无竞争所以没有使用CAS。
release的语义在于：如果可以释放锁，则唤醒队列第一个线程（Head）
Lock锁机制总结
AbstractQueuedSynchronizer通过构造一个基于阻塞的CLH队列容纳所有的阻塞线程，而对该队列的操作均通过Lock-Free（CAS）操作，但对已经获得锁的线程而言，ReentrantLock实现了偏向锁的功能。
synchronized锁机制实现原理
synchronized锁机制存在于JVM层面，它在字节码中的体现是monitorenter和monitorexit指令。
synchronized的底层也是一个基于CAS操作的等待队列，但JVM实现的更精细，把等待队列分为ContentionList和EntryList，目的是为了降低线程的出列速度；当然也实现了偏向锁，从数据结构来说二者设计没有本质区别。但synchronized还实现了自旋锁，并针对不同的系统和硬件体系进行了优化，而Lock则完全依靠系统阻塞挂起等待线程。
对比
当然Lock比synchronized更适合在应用层扩展，可以继承AbstractQueuedSynchronizer定义各种实现，比如实现读写锁（ReadWriteLock），公平或不公平锁；同时，Lock对应的Condition也比wait/notify要方便的多、灵活的多。