Lock接口是Jdk 5之后Java所提供的用于显式的获取和释放锁的接口，接口的定义如下：
public interface Lock { void lock(); void lockInterruptibly() throws InterruptedException; boolean tryLock(); boolean tryLock(long time, TimeUnit unit) throws InterruptedException; void unlock(); Condition newCondition(); }它的实现类有常用的ReentrantLock、ReentrantReadWriteLock等，如下所示：
Lock接口相对于sychronized关键字来实现线程同步的优势在于：
尝试非阻塞的获取锁：当前线程尝试获取锁，如果这一时刻没有被其他的线程获取到，那么该线程可以成功获取并持有锁能被中断的获取锁：获取到锁的线程能够响应中断，当获取到锁的线程被中断时，中断异常将会被抛出，同时锁将会被释放超时获取锁：在指定的截止时间之前获取锁，如果截止时间到了仍然没有获取到锁，则返回Lock接口中定义的关于锁的获取的释放的方法如下所示：
lock()：获取锁lockInterruptibly()：可中断地获取锁，在获取锁的过程中可响应中断tryLock()：尝试非阻塞的获取锁，调用该方法后立即返回。如果能够获取到锁，返回true；否则返回falsetryLock(long time, TimeUnit unit)：超时的获取锁，当前线程会在以下三种情况下返回： 当前线程在超时时间内获取到了锁当前线程在超时时间内被中断超时时间结束，返回false unlock()：释放锁Condition newCondition：获取等待通知组件，该组件和当前线程绑定，当前线程只有获取到了锁，才能调用该组件的wait()方法，而调用后，当前线程将释放锁队列同步器（AbstractQueuedSychronizer，AQS）是一个阻塞式锁和相关的同步器工具的框架。Lock锁通过在锁的实现中聚合同步器，利用同步器来实现锁的语义。其他同步组件的基本框架，例如Semaphore、CountDownLatch、CyclicBarrier等也是依赖于AQS实现的。
AQS通过在类中定义一些和同步相关的抽象方法来作为父类使用，其他子类通过继承它并实现其中的抽象方法来实现自定义同步组件。子类通常作为自定义同步组件的静态内部类实现，用户在使用同步组件时不会接触到具体的子类，组件中的方法的实现会代理到子类上。
AQS中使用了state来表示资源的状态（独占模式和共享模式），子类使用如下的方法来维护state，进而来控制如何获取和使用锁：
getState()：获取state状态setState()：设置state状态compareAndSetState()：通过CAS机制来设置state状态独占模式表示只有一个线程可以访问资源。共享模式表示资源允许被多个线程访问。
它的定义如下：
public abstract class AbstractQueuedSynchronizer extends AbstractOwnableSynchronizer implements java.io.Serializable { // 队列的head和tail节点，同步状态state都被volatile修饰，保证修改的可见性 private transient volatile Node head; private transient volatile Node tail; private volatile int state; ...... }类中定义的抽象方法大致上分为三类：独占式获取与释放同步状态、共享式获取与释放同步状态和查询同步队列中的等待线程情况 ，例如：
protected boolean tryAcquire(int arg)：独占式获取同步状态，首先查询当前状态并判断同步状态是否符合预期，然后再通过CAS设置同步状态protected boolean tryRelease(int arg)：独占式释放同步状态，等待获取同步状态的线程将有机会获取同步状态protected int tryAcquireShared(int arg)：共享式获取同步状态，返回大于等于0的值，表示获取成功；否则，获取失败protected boolean tryReleaseShared(int arg)：共享式释放同步状态protected boolean isHeldExclusively()：当前同步器是否在独占模式下被线程占用子类中需要实现上述的方法。如果子类中实现了上述的方法，那么就可以使用它们来获取和释放锁，例如：
获取锁
// 如果获取锁失败 if(!tryAcquire(arg)){ // 入队，可以选择阻塞当前线程 }释放锁
// 如果释放锁成功 if(tryRelease(arg)){ // 让阻塞线程恢复运行 }AQS要实现的功能目标是：
阻塞版本获取锁额acquire方法和非阻塞版本的尝试获取锁的tryAcquire方法获取锁超时机制通过打断取消机制独占机制与共享机制条件不满足时的等待机制AQS的设计思想也是非常直观的，它获取锁时会不断的自旋，直到state值为0表示可以获取锁，如下所示：
while(state 状态不允许获取) { if(队列中还没有此线程) { 入队并阻塞 } } 当前线程出队释放锁时会唤醒等待队列中的其他线程，如下所示：
if(state 状态允许了) { 恢复阻塞的线程(s) }核心在于如何原子性的维护state、如何控制阻塞和唤醒线程，以及如何维护线程的等待队列。
state使用volatile关键字修饰，并且配合CAS机制来保证其修改时的原子性；state使用了32bit的int型数据来维护同步状态
AQS使用了park和unpark来控制线程的阻塞和唤醒，可以先park后unpark，当前相反的操作也是可以的，而且park线程还可以被打断
等待队列采用了不支持优先级的FIFO队列，并借鉴了单向无锁的CLH队列
CLH（Craig, Landin, and Hagersten ）队列拥有head和tail两个指针节点，它们都使用volatile修饰，每个节点有state维护节点状态。如下所示：
CLH锁是一种自旋锁，它的优点是快速、无阻塞。入队了出队的操作示意如下所示：
// 入队 do { // 原来的 tail Node prev = tail; // 用 cas 在原来 tail 的基础上改为 node } while(tail.compareAndSet(prev, node)) // 出队 // prev 是上一个节点 while((Node prev=node.prev).state != 唤醒状态) { } // 设置头节点 head = node;CLH锁即Craig, Landin, and Hagersten (CLH) locks。CLH锁是一个自旋锁。能确保无饥饿性。提供先来先服务的公平性。它也是一种基于链表的可扩展、高性能、公平的自旋锁，申请线程仅仅在本地变量上自旋，它不断轮询前驱的状态，假设发现前驱释放了锁就结束自旋。
前面讲到，AQS通过在类中定义一些和同步相关的抽象方法来作为父类使用，其他子类通过继承它并实现其中的抽象方法来实现自定义同步器。因此，我们可以通过实现上述的方法来自定义一个同步器，完成锁的获取的释放。
首先，自定义同步器要继承AbstractQueuedSychronizer类，然后重写其中的tryAcquire()和tryRelease()来时间锁的获取和释放，这里我们以非公平锁的模式进行说明。
final class MySync extends AbstractQueuedSychronizer｛ @Override protected boolean tryAcquire(int acquires){ // 获取锁的逻辑 } @Override protected boolean tryRelease(int acquires){ // 释放锁的逻辑 } @Override protected boolean isHeldExclusively(){ // } }那么tryAcquire方法的实现逻辑如何实现呢？首先需要判断传入的acquires是否为1，即判断当前的锁是否已经被其他线程占用。如果已经被占用，那么直接返回false；否则，通过cas机制来设置state，并且设置当前线程为锁的占有线程，最后返回true。整体的实现逻辑如下所示：
@Override protected boolean tryAcquire(int acquires){ if(acquires == 1){ if(compareAndSetState(0, 1)){ setExclusiveOwnerThread(Thread.currentThread()); return true; } } return false; }知道了获取锁的逻辑，那么释放锁的逻辑就简单了。首先判断传入的acquires是否为1来判断是否持锁线程是否要释放锁、如果不等于1，直接返回false；否则进入释放锁的逻辑。释放锁的逻辑中，首先判断state是否为0，如果为0抛IllegalMonitorStateException异常；否则，先将锁的持有线程置为null，然后修改state值为0，表示锁将被释放，最后返回true。整体的实现逻辑如下：
@Override protected boolean tryRelease(int acquires) { if(acquires == 1) { if(getState() == 0) { throw new IllegalMonitorStateException(); } setExclusiveOwnerThread(null); setState(0); return true; } return false; }isHeldExclusively()只需要判断state的值是否为1，如果为1，表示当前线程为持锁线程，否则表示锁还没有被获取。
@Override protected boolean isHeldExclusively() { return getState() == 1; }自定义同步器完成后，就可以使用它自定义锁，锁中方法的实现直接代理到同步器上即可。
前面通过自定义的同步器知道了，如何通过继承AQS并实现其中的方法来自定同步器，进而实现同步组件的定制。下面来看一下JDK中Lock接口的实现类中自定义同步器的实现逻辑。RnentrantLock的类继承图如下所示：
ReentrantLock中的静态内部类Sync继承了AQS，作为ReentrantLock的同步器使用，Sync又有两个子类分别实现公平模型个非公平模式。Sync的源码实现如下：
abstract static class Sync extends AbstractQueuedSynchronizer { private static final long serialVersionUID = -5179523762034025860L; // 抽象的加锁方法 abstract void lock(); // 非公平锁的获取 final boolean nonfairTryAcquire(int acquires) { // 获取当前的线程 final Thread current = Thread.currentThread(); // 获取同步状态值 int c = getState(); // 如果同步状态为0，那么当前线程可以获取锁 if (c == 0) { if (compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } } // 如果当前线程已经获取到了锁，那么执行锁重入机制 else if (current == getExclusiveOwnerThread()) { // 同步状态值加1 int nextc = c + acquires; if (nextc < 0) // overflow throw new Error("Maximum lock count exceeded"); setState(nextc); return true; } return false; } // 锁的释放，和前面自定义同步器中锁的释放逻辑一致 protected final boolean tryRelease(int releases) { int c = getState() - releases; if (Thread.currentThread() != getExclusiveOwnerThread()) throw new IllegalMonitorStateException(); boolean free = false; // 如果c值为0，表示当前线程释放锁 if (c == 0) { free = true; setExclusiveOwnerThread(null); } // 否则，只是当前线程重入计数减1 setState(c); return free; } protected final boolean isHeldExclusively() { // 判断持锁线程是否是当前线程 return getExclusiveOwnerThread() == Thread.currentThread(); } final ConditionObject newCondition() { return new ConditionObject(); } final Thread getOwner() { return getState() == 0 ? null : getExclusiveOwnerThread(); } final int getHoldCount() { return isHeldExclusively() ? getState() : 0; } final boolean isLocked() { return getState() != 0; } private void readObject(java.io.ObjectInputStream s) throws java.io.IOException, ClassNotFoundException { s.defaultReadObject(); setState(0); // reset to unlocked state } }公平锁和非公平锁只有两处不同：
非公平锁在调用 lock 后，首先就会调用 CAS 进行一次抢锁，如果这个时候恰巧锁没有被占用，那么直接就获取到锁返回了非公平锁在 CAS 失败后，和公平锁一样都会进入到 tryAcquire 方法，在 tryAcquire 方法中，如果发现锁这个时候被释放了（state == 0），非公平锁会直接 CAS 抢锁，但是公平锁会判断等待队列是否有线程处于等待状态，如果有则不去抢锁，乖乖排到后面。公平锁和非公平锁就这两点区别，如果这两次 CAS 都不成功，那么后面非公平锁和公平锁是一样的，都要进入到阻塞队列等待唤醒。相对来说，非公平锁会有更好的性能，因为它的吞吐量比较大。当然，非公平锁让获取锁的时间变得更加不确定，可能会导致在阻塞队列中的线程长期处于饥饿状态。
下面以非公平锁为例说明ReentrantLock中锁的获取和释放的源码实现。非公平锁对应的类NonfairSync源码实现如下：
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); } }首先，从ReentrantLock的无参构造方法中可以看出，ReentrantLock默认使用的是非公平锁，当然也可以通过另一个构造方法显式使用公平锁。
public ReentrantLock() { sync = new NonfairSync(); } public ReentrantLock(boolean fair) { sync = fair ? new FairSync() : new NonfairSync(); }假设，此时Thread-0持有锁并且没有其他的线程竞争锁，也没有当前线程进行锁重入，所以state值为1，如下所示：
如果此时有新的线程Thread-1也要来竞争锁，那么它会使用CAS尝试将state值由0改为1。但是此时锁已经被Thread-0持有，state值为1，所以执行失败。
final void lock() { // 尝试使用CAS将state从0修改为1，仅尝试一次，成功则获得独占锁 if (compareAndSetState(0, 1)) setExclusiveOwnerThread(Thread.currentThread()); else // 失败 acquire(1); }然后会进入到tryAcquire逻辑再次尝试获取锁，但此时state仍为1，依然获取失败。
public final void acquire(int arg) { if (!tryAcquire(arg) && // 当 tryAcquire 返回为 false 时, 先调用 addWaiter, 接着 acquireQueued acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); }其中tryAcquire实现如下：
protected final boolean tryAcquire(int acquires) { return nonfairTryAcquire(acquires); } // 非公平模式下尝试获取锁 final boolean nonfairTryAcquire(int acquires) { // 首先获取当前线程 final Thread current = Thread.currentThread(); // 获取state的值 int c = getState(); // 如果此时state为0，表示没有持锁线程存在 if (c == 0) { // 使用cas尝试将0修改为1 // 此时，如果多个线程同时进入，CAS操作会确保，只有一个线程修改成功 if (compareAndSetState(0, acquires)) { // 并且设置当前线程为持锁线程，独占模式 setExclusiveOwnerThread(current); // 返回true return true; } } // 如果当前线程就是持锁线程，执行锁重入 else if (current == getExclusiveOwnerThread()) { // 计数器加1 int nextc = c + acquires; if (nextc < 0) // overflow throw new Error("Maximum lock count exceeded"); // volatile写，保证内存可见性 setState(nextc); return true; } // 如果锁已经被其他的线程持有，竞争失败，返回调用处 return false; }tryAcquire执行失败后，Thread-1不再尝试获取锁，而且直接进入等待队列，等待被唤醒。此时，接着进入到addWaiter逻辑，构造等待队列（Node队列），如下所示：
Node节点上的数字表示waitStatus状态，0为默认正常状态；Node是懒惰创建的；第一个Node为哨兵节点。
private Node addWaiter(Node mode) { // 将当前线程关联到一个Node对象上，模式为独占模式 Node node = new Node(Thread.currentThread(), mode); // 如果此时tail不为null，说明等待队列中已有线程等待 Node pred = tail; // 使用cas尝试将node放入等待队列尾部 if (pred != null) { // 双向链表的插入操作 node.prev = pred; if (compareAndSetTail(pred, node)) { pred.next = node; return node; } } // 尝试将node加入到AQS enq(node); return node; } private Node enq(final Node node) { // 死循环，知道满足条件才返回 for (;;) { Node t = tail; // 如果还没有，那么设置head为哨兵节点，状态为0 if (t == null) { // Must initialize if (compareAndSetHead(new Node())) tail = head; } else { // cas 尝试将node加入AQS队列尾部 node.prev = t; if (compareAndSetTail(t, node)) { t.next = node; return t; } } } }当前线程进入acquireQueued逻辑：
acquireQueued会在一个死循环中不断尝试获得锁，失败后进入 park 阻塞如果自己是紧邻着 head（排第二位），那么再次tryAcquire尝试获取锁，当然这时 state 仍为 1，失败 final boolean acquireQueued(final Node node, int arg) { boolean failed = true; try { boolean interrupted = false; for (;;) { final Node p = node.predecessor(); // 其前驱是头节点，并且再次调用tryAcquire成功获取锁 if (p == head && tryAcquire(arg)) { // 获取成功将自己作为头节点 setHead(node); // help GC p.next = null; // 返回中断标记 false failed = false; // 成功获取锁，返回 return interrupted; } //没有得到锁时： //shouldParkAfterFailedAcquire方法：返回是否需要阻塞当前线程 //parkAndCheckInterrupt方法：阻塞当前线程，当线程再次唤醒时，返回是否被中断 if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) // 修改中断标志位 interrupted = true; } } finally { if (failed) //获取锁失败，则将此线程对应的node的waitStatus改为CANCEL cancelAcquire(node); } }进入shouldParkAfterFailedAcquire逻辑，将前驱 node，即 head 的 waitStatus 改为 -1，返回 false
shouldParkAfterFailedAcquire执行完毕回到acquireQueued，再次 tryAcquire尝试获取锁，当然这时state 仍为 1，失败
当再次进入shouldParkAfterFailedAcquire时，这时因为其前驱 node 的 waitStatus 已经是 -1，这次返回true
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) { // 获取上一个节点的状态 int ws = pred.waitStatus; // 前驱节点的waitStatus是SIGNAL，前驱节点释放锁后会唤醒后继节点 if (ws == Node.SIGNAL) { // 上一个节点都在阻塞, 那么自己也阻塞好了 return true; } // > 0 表示取消状态 if (ws > 0) { // 上一个节点取消, 那么重构删除前面所有取消的节点, 返回到外层循环重试 do { node.prev = pred = pred.prev; } while (pred.waitStatus > 0); pred.next = node; } else { // 这次还没有阻塞 // 但下次如果重试不成功, 则需要阻塞，这时需要设置上一个节点状态为 Node.SIGNAL compareAndSetWaitStatus(pred, ws, Node.SIGNAL); } return false; } // 阻塞当前线程 private final boolean parkAndCheckInterrupt() { LockSupport.park(this); return Thread.interrupted(); } 进入parkAndCheckInterrupt， Thread-1 park（灰色表示）再次有多个线程经历上述过程竞争失败，如下所示：
Thread-0 释放锁，进入tryRelease流程，如果成功：设置 exclusiveOwnerThread 为 null，state = 0
// 解锁实现 public void unlock() { sync.release(1); } public final boolean release(int arg) { // 尝试释放锁 if (tryRelease(arg)) { // 队列头节点 unpark Node h = head; if ( // 队列不为 null h != null && // waitStatus == Node.SIGNAL 才需要 unpark h.waitStatus != 0 ) { // unpark AQS 中等待的线程, 进入 unparkSuccessor(h); } return true; } return false; } // 只有持锁线程才能释放锁 protected final boolean tryRelease(int releases) { // state-- int c = getState() - releases; if (Thread.currentThread() != getExclusiveOwnerThread()) throw new IllegalMonitorStateException(); boolean free = false; // 支持锁重入, 只有 state 减为 0, 才释放成功 if (c == 0) { free = true; setExclusiveOwnerThread(null); } setState(c); return free; }当前队列不为 null，并且 head 的 waitStatus = -1，进入unparkSuccessor 流程，找到队列中离 head 最近的一个 Node（没取消的），unpark 恢复其运行，本例中即Thread-1回到Thread-1的acquireQueued流程
如果加锁成功（没有竞争），会设置
exclusiveOwnerThread为Thread-1，state = 1head指向刚刚Thread-1所在的Node，该Node清空Thread原本的head因为从链表断开，而可被垃圾回收如果这时候有其它线程来竞争（非公平的体现），例如这时有Thread-4来了
private void unparkSuccessor(Node node) { // 如果状态为 Node.SIGNAL 尝试重置状态为 0 // 不成功也可以 int ws = node.waitStatus; if (ws < 0) { compareAndSetWaitStatus(node, ws, 0); } // 找到需要 unpark 的节点, 但本节点从 AQS 队列中脱离, 是由唤醒节点完成的 Node s = node.next; // 不考虑已取消的节点, 从 AQS 队列从后至前找到队列最前面需要 unpark 的节点 if (s == null || s.waitStatus > 0) { s = null; for (Node t = tail; t != null && t != node; t = t.prev) if (t.waitStatus <= 0) s = t; } if (s != null) LockSupport.unpark(s.thread); }如果不巧又被Thread-4抢占
Thread-4被设置为exclusiveOwnerThread，state = 1Thread-1 再次进入acquireQueued流程，获取锁失败，重新进入park阻塞由前面nonfairTryAcquire和tryRelease方法的源码可知，ReentrantLock支持可重入是通过以下三个步骤实现的：
首先，持锁线程必须是当前想再次获取锁的线程修改state的值，执行一次重入操作值加1当前线程释放锁时，如果state值大于1，表示有锁重入发生，将state值减1；直到state减为0，锁的持锁线程设置为null，锁才算被释放成功如果在不可打断模式下执行打断操作，那么被打断的线程仍会在AQS队列中，一直要等到线程获得锁之后才能知道自己已经被打断了。
private final boolean parkAndCheckInterrupt() { LockSupport.park(this); return Thread.interrupted(); }parkAndCheckInterrupt内部调用的而是LockSupport工具类中的park方法，最后调用Thread类的静态方法interrupted获取线程的中断标志位。
而且从acquireQueue的实现逻辑可知，即时被打断的线程仍然要获得锁：
public final void acquire(int arg) { if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); } static void selfInterrupt() { // 重新产生一次中断 Thread.currentThread().interrupt(); } final boolean acquireQueued(final Node node, int arg) { boolean failed = true; try { boolean interrupted = false; for (;;) { final Node p = node.predecessor(); if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; failed = false; // 还是需要获得锁后, 才能返回打断状态 return interrupted; } if ( shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt() ) { // 如果是因为 interrupt 被唤醒, 返回打断状态为 true interrupted = true; } } } finally { if (failed) cancelAcquire(node); } }在不可打断模式中，如果线程在park等待的过程中被中断，那么线程会抛出异常，而不再进入尝试获取锁的for循环中。
public final void acquireInterruptibly(int arg) throws InterruptedException { if (Thread.interrupted()) throw new InterruptedException(); // 如果没有获得到锁,进入doAcquireInterruptibly if (!tryAcquire(arg)) doAcquireInterruptibly(arg); } // 可打断的获取锁流程 private void doAcquireInterruptibly(int arg) throws InterruptedException { final Node node = addWaiter(Node.EXCLUSIVE); boolean failed = true; try { for (;;) { final Node p = node.predecessor(); if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; // help GC failed = false; return; } if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) { // 在 park 过程中如果被 interrupt 会进入此 // 这时候抛出异常, 而不会再次进入 for (;;) throw new InterruptedException(); } } } finally { if (failed) cancelAcquire(node); } }相比于默认的非公平锁，公平锁的锁获取操作中只是多了一步操作，它会在加入到同步队列前先判断当前节点是否有前驱节点，如果有方法返回true，表示有线程比当前线程更早的请求获取锁。因此，只有等到前面的线程获取并释放锁之后，该线程才能去尝试获取锁。
protected final boolean tryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { // 判断是否有前驱节点 // 如果没有前驱节点，并且成功使用CAS将state从0修改为1，将锁的持有线程置为当前线程 if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); // 返回true，表示获取锁成功 return true; } } // 否则判断是否执行锁重入逻辑 else if (current == getExclusiveOwnerThread()) { int nextc = c + acquires; if (nextc < 0) throw new Error("Maximum lock count exceeded"); setState(nextc); return true; } // 如果既没有获取到锁，而且也不执行锁重入，表示锁获取失败 return false; }通常来说，非公平锁的线程切换开销更小。因此，ReentrantLock中默认使用的是非公平锁
