AQS（AbstractQueuedSynchronizer）的实现原理

锁是用来控制多个线程访问共享资源的方式，一般来说，一个锁能够防止多个线程同时访问共享资源（但是有些锁可以允许多个线程并发的访问共享资源，比如读写锁）。

在Lock接口出现之前，Java程序是靠synchronized关键字实现锁功能的，而Java SE 5之后，并发包中新增了Lock接口（以及相关实现类）用来实现锁功能，它提供了与synchronized关键字类似的同步功能，只是在使用时需要显式地获取和释放锁。虽然它缺少了（通过synchronized块或者方法所提供的）隐式获取释放锁的便捷性，但是却拥有了锁获取与释放的可操作性、可中断的获取锁以及超时获取锁等多种synchronized关键字所不具备的同步特性。
使用synchronized关键字将会隐式地获取锁，但是它将锁的获取和释放固化了，也就是先获取再释放。当然，这种方式简化了同步的管理，可是扩展性没有显示的锁获取和释放来的好。例如，针对一个场景，手把手进行锁获取和释放，先获得锁A，然后再获取锁B，当锁B获得后，释放锁A同时获取锁C，当锁C获得后，再释放B同时获取锁D，以此类推。这种场景下，synchronized关键字就不那么容易实现了，而使用Lock却容易许多。

Lock的使用方式

?

1 2 3 4 5 6 7

Lock lock = new ReentrantLock(); lock.lock(); try { 。。。。。。 } finally {      lock.unlock(); }

在finally块中释放锁，目的是保证在获取到锁之后，最终能够被释放。
不要将获取锁的过程写在try块中，因为如果在获取锁（自定义锁的实现）时发生了异常，异常抛出的同时，也会导致锁无故释放。

Lock接口提供的新特性

Lock接口

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public interface Lock {     //获取锁，调用该方法将会获取锁，当锁获取后，从该方法返回     void lock();     //可中断地获取锁，和lock()方法的不同之处在于该方法会响应中断，即在锁的获取过程中可以中断当前线程     void lockInterruptibly() throws InterruptedException;     //尝试非阻塞的获取锁，调用该方法后会立刻返回，如果能够获取则返回true,否则返回false     boolean tryLock();     //超时地获取锁 1、当前线程在超时时间内成功获取锁。2、当前线程在超时时间内被中断。3、超时时间结束返回false。     boolean tryLock(long time, TimeUnit unit) throws InterruptedException;     //释放锁     void unlock();     //获取等待通知组件     Condition newCondition(); }

 

?

1

Lock接口的实现

Lock接口的实现基本都是通过组合了一个队列同步器（AbstractQueuedSynchronizer）的子类来完成线程访问控制的。

队列同步器（AQS）

队列同步器AbstractQueuedSynchronizer（以下简称同步器），是用来构建锁或者其他同步组件的基础框架，它使用了一个int成员变量表示同步状态，通过内置的FIFO队列来完成资源获取线程的排队工作，并发包的作者（Doug Lea）期望它能够成为实现大部分同步需求的基础。同步器的主要使用方式是继承，子类通过继承同步器并实现它的抽象方法来管理同步状态，在抽象方法的实现过程中免不了要对同步状态进行更改，这时就需要使用同步器提供的3个方法（getState()、setState(int newState)和compareAndSetState(int expect,int update)）来进行操作，因为它们能够保证状态的改变是安全的。子类推荐被定义为自定义同步组件的静态内部类，同步器自身没有实现任何同步接口，它仅仅是定义了若干同步状态获取和释放的方法来供自定义同步组件使用，同步器既可以支持独占式地获取同步状态，也可以支持共享式地获取同步状态，这样就可以方便实现不同类型的同步组件（ReentrantLock、ReentrantReadWriteLock和CountDownLatch等）。同步器是实现锁（也可以是任意同步组件）的关键，在锁的实现中聚合同步器，利用同步器实现锁的语义。可以这样理解二者之间的关系：锁是面向使用者的，它定义了使用者与锁交互的接口（比如可以允许两个线程并行访问），隐藏了实现细节；同步器面向的是锁的实现者，它简化了锁的实现方式，屏蔽了同步状态管理、线程的排队、等待与唤醒等底层操作。锁和同步器很好地隔离了使用者和实现者所需关注的领域。

队列同步器的接口

同步器的设计是基于模板方法模式的，也就是说，使用者需要继承同步器并重写指定的方法，随后将同步器组合在自定义同步组件的实现中，并调用同步器提供的模板方法，而这些模板方法将会调用使用者重写的方法。重写同步器指定的方法时，需要使用同步器提供的如下3个方法来访问或修改同步状态。·getState()：获取当前同步状态。·setState(int newState)：设置当前同步状态。·compareAndSetState(int expect,int update)：使用CAS设置当前状态，该方法能够保证状态设置的原子性。

同步器提供的模板方法基本上分为3类：独占式获取与释放同步状态、共享式获取与释放同步状态和查询同步队列中的等待线程情况。自定义同步组件将使用同步器提供的模板方法来实现自己的同步语义。

同步队列的基本结构

同步器依赖内部的同步队列（一个FIFO双向队列）来完成同步状态的管理。同步队列中的节点（Node）用来保存"获取同步状态失败的线程"引用、等待状态以及前驱和后继节点。节点的属性类型与名称及描述：

同步器包含了两个节点类型的引用，一个指向头节点，而另一个指向尾节点。

将节点加入同步队列

当前线程获取同步状态失败时，同步器会将当前线程、等待状态等信息构造成为一个节点（Node）并将其加入同步队列，同时会”“阻塞”当前线程。

试想一下，当一个线程成功地获取了同步状态（或者锁），其他线程将无法获取到同步状态，转而被构造成为节点并加入到同步队列中，而这个加入队列的过程必须要保证线程安全。

因此，同步器提供了一个基于CAS的设置尾节点的方法：compareAndSetTail(Nodeexpect,Nodeupdate)，它需要传递当前线程“认为”的尾节点和当前节点，只有设置成功后，当前节点才正式与之前的尾节点建立关联。

释放同步状态

同步队列遵循FIFO，首节点是获取同步状态成功的节点，首节点的线程在释放同步状态时，将会“唤醒“后续节点，而后续节点将会在获取同步状态成功时将自己设置为首节点。

设置首节点是由获取同步状态成功的线程来完成的，由于只有一个线程能够成功的获取到同步状态，因此设置头节点的方法并不需要使用CAS来保证，它只需要将首节点设置成为原首节点后继节点，并断开首节点的next引用即可。

独占式同步状态获取与释放

通过调用同步器的acquire(int arg)方法可以获取同步状态。该方法对中断不敏感，也就是说，由于线程获取同步状态失败后进入同步队列中，后续对线程进行中断操作时，线程不会从同步队列中移除。

 

?

1 2 3 4 5

public final void acquire(int arg) {//**该方法是模板方法**     if (!tryAcquire(arg) &&//先通过tryAcquire获取同步状态         acquireQueued(addWaiter(Node.EXCLUSIVE), arg))//获取同步状态失败则生成节点加入同步队列         selfInterrupt(); }

独占式同步状态获取流程

主要逻辑：首先调用自定义同步器实现的tryAcquire(int arg)方法，该方法保证线程安全的获取同步状态，如果同步状态获取失败，则构造同步节点（独占式Node.EXCLUSIVE，同一时刻只能有一个线程成功获取同步状态）并通过addWaiter(Node node)方法将该节点加入到同步队列的尾部，最后调用acquireQueued(Node node,int arg)方法，使得该节点以“死循环”的方式获取同步状态。

 

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

//将节点加入到同步队列的尾部 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;//先将当前节点node的前驱指向当前tail           if (compareAndSetTail(pred, node)) {//CAS尝试将tail设置为node               //如果CAS尝试成功，就说明"设置当前节点node的前驱"与"CAS设置tail"之间没有别的线程设置tail成功               //只需要将"之前的tail"的后继节点指向node即可               pred.next = node;               return node;           }       }       enq(node);//否则，通过死循环来保证节点的正确添加       return node;   }

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

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)) {//直到CAS成功为止                 t.next = node;                 return t;//结束循环             }         }     } }

在enq(final Node node)方法中，同步器通过“死循环”来保证节点的正确添加，在“死循环”中只有通过CAS将节点设置成为尾节点之后，当前线程才能从该方法返回，否则，当前线程不断地尝试设置。可以看出，enq(final Node node)方法将并发添加节点的请求通过CAS变得“串行化”了。

”串行化“后的优点：如果通过加锁同步的方式添加节点，线程必须获取锁后才能添加节点，那么必然会导致其他线程等待加锁而阻塞，获取锁的线程释放锁后阻塞的线程又会被唤醒，而线程的阻塞和唤醒需要依赖于系统内核完成，因此程序的执行需要从用户态切换到核心态，而这样的切换是非常耗时的操作。如果我们通过”循环CAS“来添加节点的话，所有线程都不会被阻塞，而是不断失败重试，线程不需要进行锁同步，不仅消除了线程阻塞唤醒的开销而且消除了加锁解锁的时间开销。但是循环CAS也有其缺点，循环CAS通过不断尝试来添加节点，如果说CAS操作失败那么将会占用处理器资源。

注：Node类型的prev、next属性以及AbstractQueuedSynchronizer类型的head 、tail属性都设置为volatile，保证可见性。

 

节点的自旋

节点进入同步队列之后，就进入了一个自旋的过程，每个节点（或者说是线程）都在自省地观察，当条件满足，获取到了同步状态，就可以从这个自旋过程中退出，否则依旧留在这个自旋过程中。

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

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; // help GC                 failed = false;                 return interrupted;//从自旋中退出             }             if (shouldParkAfterFailedAcquire(p, node) &&//判断获取同步状态失败后是否需要阻塞                 parkAndCheckInterrupt())                 interrupted = true;         }     } finally {         if (failed)             cancelAcquire(node);     } }

 

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

/**Checks and updates status for a node that failed to acquire.  * Returns true if thread should block. This is the main signal control in all acquire loops.*/ private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {     int ws = pred.waitStatus;//获取前驱节点的等待状态     if (ws == Node.SIGNAL)//SIGNAL表示：前驱节点释放同步状态或者被取消，将会通知后继节点。因此，可以放心的阻塞当前线程，返回true。         /* This node has already set status asking a release to signal it, so it can safely park.*/         return true;     if (ws > 0) {//前驱节点被取消了，跳过前驱节点并重试         /* Predecessor was cancelled. Skip over predecessors and indicate retry. */         do {             node.prev = pred = pred.prev;         } while (pred.waitStatus > 0);         pred.next = node;     } else {         /* waitStatus must be 0 or PROPAGATE.  Indicate that we  need a signal, but don't park yet.  Caller will need to          * retry to make sure it cannot acquire before parking. */         compareAndSetWaitStatus(pred, ws, Node.SIGNAL);//设置等待状态为SIGNAL     }     return false; }

?

1 2 3 4 5 6

/** Convenience method to park and then check if interrupted  * @return {@code true} if interrupted */ private final boolean parkAndCheckInterrupt() {     LockSupport.park(this);//阻塞当前线程     return Thread.interrupted(); }

 

 

 

可以看到节点和节点之间在循环检查的过程中基本不相互通信，而是简单地判断自己的前驱是否为头节点，这样就使得节点的释
放规则符合FIFO，并且也便于对过早通知的处理（过早通知是指：前驱节点不是头节点的线程由于中断而被”唤醒“）。

当同步状态获取成功之后，当前线程从acquire(int arg)方法返回，如果对于锁这种并发组件而言，代表着当前线程获取了锁。

释放同步状态

当前线程获取同步状态并执行了相应逻辑之后，就需要释放同步状态，使得后续节点能够继续获取同步状态。通过调用同步器的release(int arg)方法可以释放同步状态，该方法在释放了同步状态之后，会"唤醒"其后继节点（进而使后继节点重新尝试获取同步状态）。

 

?

1 2 3 4 5 6 7 8 9

public final boolean release(int arg) {     if (tryRelease(arg)) {//释放同步状态         Node h = head;         if (h != null && h.waitStatus != 0)             unparkSuccessor(h);         return true;     }     return false; }

 

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

/** Wakes up node's successor, if one exists.*/ private void unparkSuccessor(Node node) {     int ws = node.waitStatus;//获取当前节点等待状态     if (ws < 0)         compareAndSetWaitStatus(node, ws, 0);//更新等待状态       /* Thread to unpark is held in successor, which is normally just the next node.  But if cancelled or apparently null,      * traverse backwards from tail to find the actual non-cancelled successor.*/     Node s = node.next;     if (s == null || s.waitStatus > 0) {//从后往前找到第一个等待状态<=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);//唤醒后继线程 }

 

总结：在获取同步状态时，同步器维护一个同步队列，获取状态失败的线程都会被加入到队列中并在队列中进行自旋；移出队列

（或停止自旋）的条件是前驱节点为头节点且成功获取了同步状态。在释放同步状态时，同步器调用tryRelease(int arg)方法释放同步状态，然后唤醒头节点的后继节点。

 

共享式同步状态获取与释放

共享式获取与独占式获取最主要的区别在于同一时刻能否有多个线程同时获取到同步状态。

以文件的读写为例，如果一个程序在对文件进行读操作，那么这一时刻对于该文件的写操作均被阻塞，而读操作能够同时进行。写操作要求对资源的独占式访问，而读操作可以是共享式访问。

调用同步器的acquireShared(int arg)方法可以共享式地获取同步状态。

 

?

1 2 3 4

public final void acquireShared(int arg) {     if (tryAcquireShared(arg) < 0)         doAcquireShared(arg); }

在acquireShared(int arg)方法中，同步器调用tryAcquireShared(int arg)方法尝试获取同步状态，tryAcquireShared(int arg)方法返回值为int类型，当返回值大于等于0时，表示能够获取到同步状态。因此，在共享式获取的自旋过程中，成功获取到同步状态并退出自旋的条件就是tryAcquireShared(int arg)方法返回值大于等于0。

在doAcquireShared(int arg)方法的自旋过程中，如果当前节点的前驱为头节点时，尝试获取同步状态，如果返回值大于等于0，表示该次获取同步状态成功并从自旋过程中退出。

释放同步状态

与独占式一样，共享式获取也需要释放同步状态，通过调用releaseShared(int arg)方法可以释放同步状态

 

?

1 2 3 4 5 6 7

public final boolean releaseShared(int arg) {     if (tryReleaseShared(arg)) {         doReleaseShared();         return true;     }     return false; }

 

该方法在释放同步状态之后，将会唤醒后续处于等待状态的节点。对于能够支持多个线程同时访问的并发组件（比Semaphore），它和独占式主要区别在于tryReleaseShared(int arg)方法必须确保同步状态（或者资源数）线程安全释放，一般是通过循环和CAS来保证的，因为释放同步状态的操作会同时来自多个线程。

独占式超时获取同步状态

通过调用同步器的doAcquireNanos(int arg,long nanosTimeout)方法可以超时获取同步状态，即在指定的时间段内获取同步状态，如果获取到同步状态则返回true，否则，返回false。该方法提供了传统Java同步操作（比如synchronized关键字）所不具备的特性。
在分析该方法的实现前，先介绍一下响应中断的同步状态获取过程。在Java 5之前，当一个线程获取不到锁而被阻塞在synchronized之外时，对该线程进行中断操作，此时该线程的中断标志位会被修改，但线程依旧会阻塞在synchronized上，等待着获取锁。在Java 5中，同步器提供了acquireInterruptibly(int arg)方法，这个方法在等待获取同步状态时，如果当前线程被中断，会立刻返回，并抛出InterruptedException。

超时获取同步状态过程可以被视作响应中断获取同步状态过程的“增强版”，doAcquireNanos(int arg,long nanosTimeout)方法在支持响应中断的基础上，增加了超时获取的特性。针对超时获取，主要需要计算出需要睡眠的时间间隔nanosTimeout，为了防止过早通知，nanosTimeout计算公式为：nanosTimeout-=now-lastTime，其中now为当前唤醒时间，lastTime为上次唤醒时间，如果nanosTimeout大于0则表示超时时间未到，需要继续”睡眠"nanosTimeout纳秒，反之，表示已经超时，该方法代码如代码清单5-9所示。

 

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

private boolean doAcquireNanos(int arg, long nanosTimeout)     throws InterruptedException {     long lastTime = System.nanoTime();     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 true;             }             if (nanosTimeout <= 0)                 return false;             if (shouldParkAfterFailedAcquire(p, node) &&//检查是否阻塞线程                 nanosTimeout > spinForTimeoutThreshold)                 LockSupport.parkNanos(this, nanosTimeout);             long now = System.nanoTime();             nanosTimeout -= now - lastTime;//重新计算还应该睡眠的时间             lastTime = now;             if (Thread.interrupted())                 throw new InterruptedException();         }     } finally {         if (failed)             cancelAcquire(node);     } }

该方法在自旋过程中，当节点的前驱节点为头节点时尝试获取同步状态，如果获取成功则从该方法返回，这个过程和独占式同步获取的过程类似，但是在同步状态获取失败的处理上有所不同。如果当前线程获取同步状态失败，则判断是否超时（nanosTimeout小于等于0表示已经超时），如果没有超时，重新计算超时间隔nanosTimeout，然后使当前线程等待nanosTimeout纳秒（当已到设置的超时时间，该线程会从LockSupport.parkNanos(Objectblocker,long nanos)方法返回）。

 

从图5-7中可以看出，独占式超时获取同步状态doAcquireNanos(int arg,long nanosTimeout)和独占式获取同步状态acquire(int args)在流程上非常相似，其主要区别在于未获取到同步状态时的处理逻辑。acquire(int args)在未获取到同步状态时，将会使当前线程一直处于等待状态，而doAcquireNanos(int arg,long nanosTimeout)会使当前线程等待nanosTimeout纳秒，如果当前线程在nanosTimeout纳秒内没有获取到同步状态，将会从等待逻辑中自动返回。

Lock接口的实现

独占锁

顾名思义，独占锁就是在同一时刻只能有一个线程获取到锁，而其他获取锁的线程只能处于同步队列中等待，只有获取锁的线程释放了锁，后继的线程才能够获取锁。

 

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67

public class Mutex implements Lock {     // 静态内部类，自定义同步器     private static class Sync extends AbstractQueuedSynchronizer {         // 是否处于占用状态         protected boolean isHeldExclusively() {             return getState() == 1;         }           // 当状态为0的时候获取锁         public boolean tryAcquire(int acquires) {             if (compareAndSetState(0, 1)) {                 setExclusiveOwnerThread(Thread.currentThread());                 return true;             }             return false;         }           // 释放锁，将状态设置为0         protected boolean tryRelease(int releases) {             if (getState() == 0)                 throw new IllegalMonitorStateException();             setExclusiveOwnerThread(null);             setState(0);             return true;         }           // 返回一个Condition，每个condition都包含了一个condition队列         Condition newCondition() {             return new ConditionObject();         }     }       // 仅需要将操作代理到Sync上即可     private final Sync sync = new Sync();           public void lock() {         sync.acquire(1);     }       public boolean tryLock() {         return sync.tryAcquire(1);     }       public void unlock() {         sync.release(1);     }       public Condition newCondition() {         return sync.newCondition();     }       public boolean isLocked() {         return sync.isHeldExclusively();     }       public boolean hasQueuedThreads() {         return sync.hasQueuedThreads();     }       public void lockInterruptibly() throws InterruptedException {         sync.acquireInterruptibly(1);     }       public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException {         return sync.tryAcquireNanos(1, unit.toNanos(timeout));     } }

 

简单生产者消费者模式

1、使用synchronized和notify/wait实现

 

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

public class SingleProduceConsumer {      static boolean empty=true;       static Object plate=new Object();//盘子      static class Consumer implements Runnable{           @Override          public void run() {               //加锁              synchronized(plate){                  //当条件不满足时，继续wait                  while(empty){                      try {                          plate.wait();                      } catch (InterruptedException e) {                           e.printStackTrace();                      }                  }                  //条件满足时，完成工作                  System.out.println("从盘子里拿一个苹果！");               }           }      }      static class Produce implements Runnable{           @Override          public void run() {               //加锁              synchronized(plate){                   //改变条件                  System.out.println("向盘子里放入一个苹果！");                  empty=false;                   plate.notifyAll();              }              }       }      public static void main(String[] args) throws InterruptedException{          Thread consumerThread=new Thread(new Consumer());          consumerThread.start();          Thread.sleep(100);         Thread produceThread=new Thread(new Produce());          produceThread.start();                  }  }

输出：

 

向盘子里放入一个苹果！
从盘子里拿一个苹果！

2、使用我们自定义的Mutex锁实现

 

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

public class MutexTest {     static boolean empty=true;        static Mutex mut=new Mutex();//互斥锁     static class Consumer implements Runnable{           @Override          public void run() {               while(true){                 //加锁                  mut.lock();                 try{                     //条件不满足，继续等待                     if(empty){                         continue;                     }                     //条件满足，完成工作                     System.out.println("从盘子里拿一个苹果！");                       break;                 }finally{                     mut.unlock();                 }             }         }      }      static class Produce implements Runnable{           @Override          public void run() {               //加锁               mut.lock();             try{                 //该变条件                 System.out.println("向盘子里放入一个苹果！");                  empty=false;               }finally{                 mut.unlock();             }          }       }      public static void main(String[] args) throws InterruptedException {         Thread consumerThread=new Thread(new Consumer());          consumerThread.start();          Thread.sleep(100);         Thread produceThread=new Thread(new Produce());          produceThread.start();        } }

输出：

 

向盘子里放入一个苹果！
从盘子里拿一个苹果！

通过我们自定义的独占锁Mutex，达到了使用synchronized和notify/wait同样的同步效果。独占锁Mutex是一个自定义同步组件，它在同一时刻只允许一个线程占有锁。Mutex中定义了一个静态内部类，该内部类继承了同步器并实现了独占式获取和释放同步状态。在tryAcquire(int acquires)方法中，如果经过CAS设置成功（同步状态设置为1），则代表获取了同步状态，而在tryRelease(int releases)方法中只是将同步状态重置为0。用户使用Mutex时并不会直接和内部同步器的实现打交道，而是调用Mutex提供的方法，在Mutex的实现中，以获取锁的lock()方法为例，只需要在方法实现中调用同步器的模板方法acquire(int args)即可，当前线程调用该方法获取同步状态失败后会被加入到同步队列中等待，这样就大大降低了实现一个可靠自定义同步组件的门槛。

可重入锁

重入锁ReentrantLock，顾名思义，就是支持重进入的锁，它表示该锁能够支持一个线程对资源的重复加锁。除此之外，该锁的还支持获取锁时的公平和非公平性选择。

回忆在同步器一节中的示例（Mutex），同时考虑如下场景：当一个线程调用Mutex的lock()方法获取锁之后，如果再次调用lock()方法，则该线程将会被自己所阻塞，原因是Mutex在实现tryAcquire(int acquires)方法时没有考虑占有锁的线程再次获取锁的场景，而在调用tryAcquire(int acquires)方法时返回了false，导致该线程被阻塞。简单地说，Mutex是一个不支持重进入的锁。而synchronized关键字隐式的支持重进入，比如一个synchronized修饰的递归方法，在方法执行时，执行线程在获取了锁之后仍能连续多次地获得该锁，而不像Mutex由于获取了锁，而在下一次获取锁时出现阻塞自己的情况。
ReentrantLock虽然没能像synchronized关键字一样支持隐式的重进入，但是在调用lock()方法时，已经获取到锁的线程，能够再次调用lock()方法获取锁而不被阻塞。

这里提到一个锁获取的公平性问题，如果在绝对时间上，先对锁进行获取的请求一定先被满足，那么这个锁是公平的，反之，是不公平的。公平的获取锁，也就是等待时间最长的线程最优先获取锁，也可以说锁获取是顺序的。ReentrantLock提供了一个构造函数，能够控制锁是否是公平的。
事实上，公平的锁机制往往没有非公平的效率高，但是，并不是任何场景都是以TPS作为唯一的指标，公平锁能够减少“饥饿”发生的概率，等待越久的请求越是能够得到优先满足。下面将着重分析ReentrantLock是如何实现重进入和公平性获取锁的特性，并通过测试来验证公平性获取锁对性能的影响。

可重入的实现

重进入是指任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞，该特性的实现需要解决以下两个问题。
1）线程再次获取锁。锁需要去识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取。
2）锁的最终释放。线程重复n次获取了锁，随后在第n次释放该锁后，其他线程能够获取到该锁。锁的最终释放要求锁对于获取进行计数自增，计数表示当前锁被重复获取的次数，而锁被释放时，计数自减，当计数等于0时表示锁已经成功释放。

ReentrantLock是通过组合自定义同步器来实现锁的获取与释放。

 

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

public class ReentrantLock implements Lock, java.io.Serializable {     private final 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();             if (c == 0) {//首次获取同步状态                 if (compareAndSetState(0, acquires)) {//只要设置成功就获取到锁                     setExclusiveOwnerThread(current);                     return true;                 }             }             else if (current == getExclusiveOwnerThread()) {//再次获取同步状态(可重入的关键)                 //如果是获取锁的线程再次请求，则将同步状态值进行增加并返回true，表示获取同步状态成功。                 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;             if (c == 0) {//当同步状态为0时，将占有线程设置为null，并返回true，表示释放成功。                 free = true;                 setExclusiveOwnerThread(null);             }             setState(c);//否则，只是减少同步状态             return free;         }         ......     } ...... }

 

公平与非公平的实现

公平性与否是针对获取锁而言的，如果一个锁是公平的，那么锁的获取顺序就应该符合请求的绝对时间顺序，也就是FIFO。

非公平

 

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14

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);//只要设置成功就获取到锁     } }

公平

 

 

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

static final class FairSync extends Sync {     private static final long serialVersionUID = -3000897897090466540L;       final void lock() {         acquire(1);     }       protected final boolean tryAcquire(int acquires) {         final Thread current = Thread.currentThread();         int c = getState();         if (c == 0) {             if (!hasQueuedPredecessors() &&//增加是否有前驱线程的判断                 compareAndSetState(0, acquires)) {                 setExclusiveOwnerThread(current);                 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;     } }

 

 

?

1 2 3 4 5 6 7

public final boolean hasQueuedPredecessors() {     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());//首节点线程不是当前线程 }

 

 

也就是说：只要同步队列非空且首节点的线程不是当前线程，线程获取同步状态将会失败。

公平锁与非公平锁的比较

公平性锁每次都是从同步队列中的第一个节点获取到锁，而非公平性锁出现了一个线程连续获取锁的情况。
非公平性锁可能使线程“饥饿”，当一个线程请求锁时，只要获取了同步状态即成功获取锁。在这个前提下，刚释放锁的线程再次获取同步状态的几率会非常大，使得其他线程只能在同步队列中等待。
为什么它又被设定成默认的实现呢？非公平性锁模式下线程上下文切换的次数少，因此其性能开销更小。公平性锁保证了锁的获取按照FIFO原则，而代价是进行大量的线程切换。非公平性锁虽然可能造成线程“饥饿”，但极少的线程切换，保证了其更大的吞吐量。

读写锁

之前提到锁（如Mutex和ReentrantLock）基本都是排他锁，这些锁在同一时刻只允许一个线程进行访问，而读写锁在同一时刻可以允许多个读线程访问，但是在写线程访问时，所有的读线程和其他写线程均被阻塞。

读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写锁，使得并发性相比一般的排他锁有了很大提升。除了保证写操作对读操作的可见性以及并发性的提升之外，读写锁能够简化读写交互场景的编程方式。

假设在程序中定义一个共享的用作缓存数据结构，它大部分时间提供读服务（例如查询和搜索），而写操作占有的时间很少，但是写操作完成之后的更新需要对后续的读服务可见。
在没有读写锁支持的（Java 5之前）时候，如果需要完成上述工作就要使用Java的等待通知机制，就是当写操作开始时，所有晚于写操作的读操作均会进入等待状态，只有写操作完成并进行通知之后，所有等待的读操作才能继续执行（写操作之间依靠synchronized关键进行同步），这样做的目的是使读操作能读取到正确的数据，不会出现脏读。改用读写锁实现上述功能，只需要在读操作时获取读锁，写操作时获取写锁即可。当写锁被获取到时，后续（非当前写操作线程）的读写操作都会被阻塞，写锁释放之后，所有操作继续执行，编程方式相对于使用等待通知机制的实现方式而言，变得简单明了。
一般情况下，读写锁的性能都会比排它锁好，因为大多数场景读是多于写的。在读多于写的情况下，读写锁能够提供比排它锁更好的并发性和吞吐量。Java并发包提供读写锁的实现是ReentrantReadWriteLock。