Java并发基石——所谓“阻塞”：Object Monitor和AQS（3）

====================================
（接上文《Java并发基石——所谓“阻塞”：Object Monitor和AQS（2）》）

• 使用AQS实现的Mutex

现在我们来看看在AbstractQueuedSynchronizer官方文档中（实际上就是JDK源代码上的注释说明）给出的另一个示例性代码Mutex。这是一个使用AQS实现互斥锁的例子，完全可以用在正式环境下。以下代码片段中，英文注释信息是示例中自带的，中文信息是笔者加上的详细功能说明：

// ........省略掉import区域的信息
/**
 * 这是一个java AbstractQueuedSynchronizer中自带的Mutex互斥锁的实现，实际上就是基于AQS的独占机制实现。本文将详细讲解它的工作过程。
 * @author Doug Lea
 */
class Mutex implements Lock, Serializable {
  // Our internal helper class
  private static class Sync extends AbstractQueuedSynchronizer {
    /**
     * Reports whether in locked state<br>
     * isHeldExclusively该方被重写，这个方法用于向当前线程反馈，是否AQS正处于独占操作状态下。<br>
     * 当AQS目前state状态为1时，就说明当前AQS队列正处于独占操作状态。
     */
    protected boolean isHeldExclusively() {
      return getState() == 1;
    }
    /**
     * Acquires the lock if state is zero<br>
     * tryAcquire也在示例中被重写，当前线程试图获取AQS独占操作权时，该方法将被调用。
     * */
    public boolean tryAcquire(int acquires) {
      assert acquires == 1;// Otherwise unused
      /*
       * 在上篇文章中已经介绍过compareAndSetState这个方法非常重要，多线程下状态的线程安全性主要也在这里体现
       * ——因为在多线程抢占执行compareAndSetState这句代码时，只有一个线程能够执行成功
       * 放在这个示例代码段落中，具体的工作特点是：比较当前AQS的state状态，如果为0，则设置为state状态为1，并返回true；
       * 其它情况下放弃对state的设定操作，并返回false。
       * */
      if (compareAndSetState(0, 1)) {
        // 如果成功设置当前AQS的state状态为1，则说明当前线程获得了AQS的独占操作权
        // 那么通过setExclusiveOwnerThread方法，设定AQS的独占操作线程为当前线程
        setExclusiveOwnerThread(Thread.currentThread());
        return true;
      }
      return false;
    }
    
    /**
     * Releases the lock by setting state to zero
     * tryRelease在示例中被重写，当前线程释放AQS队列的独占操作权，该方法被调用
     * */
    protected boolean tryRelease(int releases) {
      assert releases == 1; // Otherwise unused
      // 如果调用该方法时，发现state状态不为1，就抛出异常
      // 这是为什么呢？这是因为，至少有一个线程在没有获得独占操作权的情况下，就调用了释放操作权的操作。
      if (getState() == 0) {
        throw new IllegalMonitorStateException();
      }
      
      // 通过setExclusiveOwnerThread方法，设定AQS的独占操作线程为null
      // 并且设定state状态为0
      setExclusiveOwnerThread(null);
      setState(0);
      return true;
    }

    // Provides a Condition
    // 关于java中的java.util.concurrent.locks.Condition接口，请参见后文介绍
    Condition newCondition() {
      return new ConditionObject();
    }
  }

  // The sync object does all the hard work. We just forward to it.
  private final Sync sync = new Sync();

  // 该方法进行加锁处理，实际上就是调用AQS的acquire方法。这里的参数1，会出现在tryAcquire方法中
  // 一旦加锁成功（获取操作权的操作成功），其它试图加锁（试图获取操作权）但又没有成功的线程，则进入阻塞状态。
  public void lock() {
    sync.acquire(1); 
  }
  // acquireInterruptibly方法和acquire方法的区别，在上文中已经有了说明
  public void lockInterruptibly() throws InterruptedException {
    sync.acquireInterruptibly(1);
  }
  // 尝试加锁（尝试获取独占操作权），如果成功了（也就是说state因为当前线程的这个操作被置为1），则返回true；
  // 如果加锁操作没有成功，则返回false，这时当前线程还可以继续动作。
  public boolean tryLock() {
    return sync.tryAcquire(1); 
  }
  // 在一段持续的时间内，尝试加锁（尝试获取独占操作权），如果成功则返回true；
  // 如果加锁操作没有成功，则返回false，这是当前线程还可以继续动作。
  public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException {
    return sync.tryAcquireNanos(1, unit.toNanos(timeout));
  }
  // 解除独占状态，AQS将在执行过程中调用Mutex.Sync中的tryRelease方法。
  public void unlock() {
    sync.release(1); 
  }
  public Condition newCondition() {
    return sync.newCondition();
  }
  // 查询当前AQS队列是否已经被某个线程独占。
  // 实际上就是调用isHeldExclusively方法，看状态是否为1，为1就是说明被独占了
  public boolean isLocked() {
    return sync.isHeldExclusively(); 
  }
  // 查询AQS中是否有任何线程正在等待获取。当AQS中的head != tail时，说明AQS中有等待队列
  public boolean hasQueuedThreads() {
    return sync.hasQueuedThreads(); 
  }
}

示例代码中的注释信息已经非常清楚了，这里就不再赘述。

• Mutex的运行使用效果

接下来我们看一下Mutex的运行效果，既然是基于AQS中的独占模式进行的实现，那么在某一个线程获得独占操作权的情况下，其它线程就不能获得操作权了——要么进入阻塞等待获得独占操作权，要么放弃抢占操作权继续执行当前线程的后续操作。

情况一：某个线程抢得了操作权，其它线程等待

public static void main(String[] args) {
  final Mutex mutex = new Mutex();
  for(int index = 0 ; index < 3 ; index++) {
    new Thread(() -> {
      try {
        mutex.lock();
      } finally {
        // 如果不调用unlock，那么独占状态将不会解除，其它线程将一直处于阻塞状态
        mutex.unlock();
      }
    } , "index" + index).start();
  } 
}

情况二：某个线程抢得了操作权，其它线程尝试抢占操作权一段时间后，放弃抢占操作权的操作

public static void main(String[] args) {
  final Mutex mutex = new Mutex();
  for(int index = 0 ; index < 3 ; index++) {
    new Thread(() -> {
      boolean isMutex = false;
      try {
        // 尝试获得独占操作权（10秒的时间内）
        if(mutex.tryLock(10, TimeUnit.SECONDS)) {
          isMutex = true;
          System.out.println("本线程尝试获取独占操作权成功");
        } else {
          System.out.println("本线程尝试获取独占操作权失败");
        }
      } catch(InterruptedException e) {
        e.printStackTrace(System.out);
      } finally {
        if(isMutex) {
          mutex.unlock();
        }
      }
    } , "index" + index).start();
  }
}

3.3、AQS代码分析

本届中我们主要分析AQS中几个关键方法，包括独占工作模式下的acquire()方法和release()方法，以及共享工作模式下的acquireShared()方法和releaseShared()方法。

3.3.1、AQS中的Node和Node构成的AQS队列

要理解AQS内部如何基于CAS原理和LockSupport工具完成工作的，就需要先把AQS中关于Node的关键定义搞清楚：

上图是对上文中AQS队列中，每一个Node节点结构图的细化说明。这个队列是一个双向的带头、尾标识的队列，在AQS队列初始化时，其中的Tail节点为null。在一个Node节点涉及到的独占模式工作效果中，主要包括了几个重要的部分：

static final class Node {
	volatile int waitStatus;
	volatile Node prev;
	volatile Node next;
	volatile Thread thread;
	// 。。。。。先省略，后续还有其它补充
}	

• next：指向当前Node节点的下一个节点，如果当前节点为尾节点，则next属性为null。

• prev：指向当前Node节点的上一个Node节点，如果当前节点为head节点，则prev属性为null。

• thread：AQS的双向队列说白了是对进程中若干Thread集合的管理，那么Node节点就需要一个属性来标识其管理的/代表的线程对象。

• waitStatus：节点等待状态，这个状态信息非常重要：包括这些状态标识：

  • 1：CANCELLED，指示当前节点所代表的线程由于等待超时或者interrupt中断信号的原因，已经取消了其在AQS队列中的抢占操作，处于这种标识状态下的节点不会再被本AQS队列继续阻塞；
  • -1：SIGNAL，指示当前节点的后续节点所代表的线程，已经被（或者很快将被）阻塞（通过parking模式），也就是说当前后续节点所代表的线程需要被执行unpark后，才能解除阻塞。
  • -2：CONDITION，指示当前对象所代表的线程，需要等待一个Condition对象的激活——在Condition队列中被阻塞。
  • -3：PROPAGATE，当节点处于“共享”模式下，该值指示共享操作权的释放信号还可以扩散到AQS队列中的其它节点上去。
  • 0：节点不处于以上任何状态。

这里我们只是介绍了waitStatus状态属性的字面含义，实际上这些字面含义只要查看java.util.concurrent.locks.AbstractQueuedSynchronizer.Node的源代码就能看到，最重要的还是这些状态如何在Node的工作过程中发挥作用。

3.3.2、独占模式下的acquire()的工作过程

有了以上小节的对Node中各个属性的基础描述作为铺垫，我们就可以首先开始分析AQS独占模式下的acquire()方法、release()工作过程。当我们调用AbstractQueuedSynchronizer.acquire(int)方法时，AQS做了什么工作呢？首先上代码——acquire(int)方法中的详细代码片段：

//......
public final void acquire(int arg) {
  // 请注意这个 Node.EXCLUSIVE 值，从源代码可以看到这个对象代表的就是一个null值
  if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
    selfInterrupt();
}
//......

acquire 方法中一共执行了三个关键方法：

• tryAcquire(int) 这个方法在上文中都已经介绍过，就是需要开发人员在使用AQS独占模式之前需要重写的方法。当这个方法返回true，就表示当前线程获得了独占操作权；从acquire方法的代码详情可以看出，如果tryAcquire(int)方法返回true，则整个方法就结束，不再进行任何处理——包括也不需要进行AQS队列的任何变动了。

• addWaiter(Node) 方法的作用创建一个Node节点，并试图将这个节点挂载到AQS的队尾（以CAS线程安全的方式）。根据AQS的工作模式（独占或者共享）创建的节点特点是不一样的。这里我们先介绍在独占模式下创建节点的过程。

/**
 * Creates and enqueues node for current thread and given mode.
 * @param mode Node.EXCLUSIVE for exclusive, Node.SHARED for shared
 */
private Node addWaiter(Node mode) {
  // 根据源代码的，当独占模式的acquire方法调用addWaiter这个方法的时候，其传参的mode的值为null
  Node node = new Node(Thread.currentThread(), mode);
  // Try the fast path of enq; backup to full enq on failure
  // 最常见的this.tail为null的情况就是当前AQS队列中还没有节点
  Node pred = this.tail;
  if (pred != null) {
    node.prev = pred;
    // 这个CAS方法的含义是，判断当前AQS的尾部节点是pred，如果是则重新设置为当前node
    // 设定成功，则退出
    if (compareAndSetTail(pred, node)) {
      pred.next = node;
      return node;
    }
  }
  enq(node);
  return node;
}

这个addWaiter方法中的CAS操作只进行了一次，并不是如果没有成功就进入enq方法。enq方法实际上就是addWaiter方法的“无限循环”操作，也就是说不将新增的节点添加到AQS队列中决不罢休。代码如下：

/**
 * Inserts node into queue, initializing if necessary. See picture above.
 * 反正笔者是不知道picture在哪里
 * @param node the node to insert
 */
private Node enq(final Node node) {
  // 一直试图添加，直到添加到了AQS队列的头部或者尾部未知
  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;
	  }
	}
  }
}

• acquireQueued(Node , int) 通过addWaiter方法我们将一个代表线程的AQS节点进行了创建，并且加入到了AQS队列中，但是我们还没有让这个节点所代表的线程进入阻塞状态，也没有让这个节点和AQS队列的整体建立交互机制（参与独占操作权的抢占）。所以这个acquireQueued方法就是让这个新加入AQS队列的节点根据调用者的设定逻辑进入不同的阻塞状态，并且让这个节点所代表的线程参与独占权抢占。代码详情如下：

/**
 * Acquires in exclusive uninterruptible mode for thread already in
 * queue. Used by condition wait methods as well as acquire.
 * @return true：if interrupted while waiting
 */
final boolean acquireQueued(final Node node, int arg) {
  boolean failed = true;
  try {
    boolean interrupted = false;
    for (;;) {
      // 取得当前的节点的前驱节点（前置节点）
      final Node p = node.predecessor();
      // 这个if段落的代码有得一读。仔细看
      // 如果当前节点的前驱节点是头结点，那么再次试图执行tryAcquire方法。
      // 如果执行成功则当前节点为头部节点，通过if段落中的代码去掉当前的头结点信息
      if (p == head && tryAcquire(arg)) {
        setHead(node);
        p.next = null; // help GC
        failed = false;
        return interrupted;
      }
      
      // 如果当前节点前驱节点不是头部节点，或者执行tryAcquire再次失败，那么就执行到这个if块
      if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) 
        interrupted = true;
    }
  } finally {
    if (failed) 
      cancelAcquire(node);
  }
}

acquireQueued方法中如果当前节点的前驱节点是AQS队列的head节点，且再次试图执行tryAcquire方法又成功的特殊情况这里就不再进行赘述了，我们主要讲解后面的两个方法shouldParkAfterFailedAcquire和parkAndCheckInterrupt。

shouldParkAfterFailedAcquire方法是判断当前节点是否在获取独占操作权失败后进入阻塞状态；parkAndCheckInterrupt方法用于让当前节点所代表的线程进入阻塞状态，并监控其是否收到了“中断”信号。先来看一下shouldParkAfterFailedAcquire方法的代码详情：

// 参数为node：当前节点；pred：当前节点的前置节点
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
  int ws = pred.waitStatus;
  // 前置节点Node的waitStatus状态属性为SIGNAL（-1），就说明可以进行阻塞，于是返回true
  if (ws == Node.SIGNAL)
    // This node has already set status asking a release to signal it, so it can safely park.
    return true;
  // waitStatus状态属性大于0的，就只有一种叫做CANCELLED的状态
  // 文档中对于这种状态的描述也非常清楚，就是这些节点由于超时或者终止的原因不在需要进入阻塞状态。
  // 也不会再参与独占操作权的抢占操作，于是循环执行以下代码，将这些节点剔除
  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);
  }
  return false;
}

一旦shouldParkAfterFailedAcquire方法的返回值为false，则重新进入acquireQueued方法的“for ( ; ; ) 死循环”；如果返回值为true，则调用parkAndCheckInterrupt方法。parkAndCheckInterrupt方法的详情如下：

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

================================================================
（接下文）