java中lock的学习笔记（二）AQS同步器_lock中waitstatus

前言：

     对于java的锁机制，可以说是长久以来一直困扰着我，经过长久的挣扎，终于决定来学习下，下面就就记录下日常学习的lock的笔记，以记录的形式来督促自己学习，毕竟有惰性，也不是学习天才，只能不断的鞭策自己，让自己学习。

在java中lock的学习笔记（一）中，提到公平锁时，先判断是否有等待的线程，但是等待的线程在哪里呢？其实是有一个队列的，并且在非公平锁实现时，如果没有抢占到锁也是进入队列中等待的，下来就来学习下这个队列。

首先看下这个队列在哪里？先看下UML图

ReentrantLock中有三个内部类Sync、FairSync和NonfairSync，FairSync和NonfairSync继承自Sync类，而Sync又继承自AbstractQueuedSynchronizer类，AbstractQueuedSynchronizer就是常听到的AQS同步器，也就时队列的所在了。接下来就来看看这个老是把我搞晕的同步器。

​​​​​​​AQS同步器的Fields

从上图看到AQS中主要的类属性head和tail节点，还有一个state状态值。这就可以看出是一个这可能是一个链表，而AQS有两个内部类Node和ConditionObject，从上图看出Node其实就是队列的节点，而ConditionObject中有firstWaiter和lastWaiter属性，说明这也是一个队列，其实这个队列中的节点也是使用的Node这个类，所以再来解读node类中的属性，Node类中的waitStatus、thread属性是公共属性，被CLH(一个FIFO(first in first out先进先出)双向队列)队列和Condition队列公共使用，而nextWaiter和Condition属性是Condition使用的，prev和next是CLH队列使用的，分别标出前节点和后节点，构成双向链表结构。看下node类如下

 /**
     * 等待队列结点类
     * AQS定义两种队列
     * CLH等待队列  独占/共享模式 双向队列  next/prev节点正常指向前驱/后继
     * 原CLH队列的一个变种,线程由原自旋机制改为阻塞机制
     * <p>
     * Condition条件队列  独占模式 单向队列  next/prev节点都为空 通过nextWaiter获取下一节点
     * 条件队列一般使用场景：阻塞队列
     * AQS定义两种模式
     * 共享、独占
     */
    static final class Node {
        /**
         * 当前结点-共享模式
         * 多个线程可以同时执行，如Semaphore/CountDownLatch
         */
        static final Node SHARED = new Node();
        /**
         * 当前结点-独占模式
         * 只有一个线程能执行，如ReentrantLock
         */
        static final Node EXCLUSIVE = null;
        /**
         * 在CLH等待队列中 等待的线程 超时/中断，不可被唤醒，不可获取锁，需要移除
         */
        static final int CANCELLED = 1;
        /**
         * 在CLH等待队列中 等待的线程 正常等待状态，可被唤醒，可获取锁
         */
        static final int SIGNAL = -1;
        /**
         * 在Condition条件队列中，当线程对Condition调用了await方法后加入创建一个node
         * 且节点状态为-2，并加入conditionObject的waiter队列中，
         * 当其他线程对Condition调用了signal()方法后，
         * 该节点会从等待队列中转移到同步队列中，加入到同步状态的获取中
         */
        static final int CONDITION = -2;
        /**
         * 在CLH等待队列中 等待的线程都是共享模式，所以等待线程都可以被传播去获取锁
         */
        static final int PROPAGATE = -3;
        /**
         * 当前节点的信号量状态 ，记录上边的(1,0,-1,-2,-3)5种状态
         * 使用CAS更改状态，volatile保证线程可见性，高并发场景下，
         * 即被一个线程修改后，状态会立马让其他线程可见。
         */
        volatile int waitStatus;
        /**
         * 前驱节点，当前节点加入到同步队列中被设置
         */
        volatile Node prev;
 
        /**
         * 后继节点
         */
        volatile Node next;
 
        /**
         * 当前节点对应记录的线程
         */
        volatile Thread thread;
 
        /**
         * 等待队列中的后继节点，如果当前节点是共享的，那么这个字段是一个SHARED常量，
         * 也就是说节点类型(独占和共享)和等待队列中的后继节点共用同一个字段。
         */
        Node nextWaiter;
 
        /**
         * Returns true if node is waiting in shared mode.
         */
        final boolean isShared() {
            return nextWaiter == SHARED;
        }
 
        /**
         * 返回前驱节点
         */
        final Node predecessor() throws NullPointerException {
            Node p = prev;
            if (p == null)
                throw new NullPointerException();
            else
                return p;
        }
 
        Node() {    // Used to establish initial head or SHARED marker
        }
 
        Node(Thread thread, Node mode) {     // Used by addWaiter
            this.nextWaiter = mode;
            this.thread = thread;
        }
 
        Node(Thread thread, int waitStatus) { // Used by Condition
            this.waitStatus = waitStatus;
            this.thread = thread;
        }
    }

接着就来说下CLH队列和condition等待队列的关系,先来看一段代码，thread1获取锁后调用conditon.await()方法，并在方法前后各打印一句话，主线程睡眠3秒后另开一个线程获得锁后调用conditon.signal()方法，也在方法前后打印一句话，代码及执行情况如下

可以看出thread1在执行了conditon.await()方法后，线程1就没有执行该方法后的代码了，也没有执行unlock解锁，thread2还是获取到了锁，并执行完了锁中的condition.signal()等内容，且释放了锁，thread1又接着执行conditon.await()之后的代码，并且此时thread1才执行了unlock解锁。那么现在就有两个问题。

第一个问题：conditon.await()和condition.signal()的作用是干什么？这和CLH队列和condition等待队列有什么关系？

第二个问题：thread1没有unlock解锁，为啥thread2还能lock锁定成功。

那么就直接来撸源码。

     public final void await() throws InterruptedException {
            //判断线程如果中断了，就抛异常
            if (Thread.interrupted())
                throw new InterruptedException();
            // 在condition等待队列中添加等待节点
            Node node = addConditionWaiter();
            // 彻底释放锁（无论重入多少次，这一次解锁，这就是为什么上图中的thread1没有执行 
            //unlock但是thread2还是能加锁的原因，因为await方法中在此处解锁了）
            int savedState = fullyRelease(node);
            int interruptMode = 0;
            // 判断如果不在同步队列中，则进入while中阻塞线程
            while (!isOnSyncQueue(node)) {
                // 不在同步队列中，则阻塞线程
                LockSupport.park(this); 
                // 在阻塞过程中发生中断
                if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                    break;
            } 
            // 从新获取锁，表示该节点已经被唤醒，并且在while等待过程中没有抛出异常，
            // 则设置interruptMode值为REINTERRUPT
            if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
                interruptMode = REINTERRUPT;
            if (node.nextWaiter != null) // clean up if cancelled
                //  从condition队列中删除该节点
                unlinkCancelledWaiters();
            // 如果interruptMode的状态不为0，则表示该线程在上面的过程中发生了中断或则抛出了
            // 异常，调用reportInterruptAfterWait方法抛出异常
            if (interruptMode != 0)
                reportInterruptAfterWait(interruptMode);
     }

从上面的代码中可以看出在执行await方法时，里面的fullyRelease方法是进行了彻底的解锁的，所以，别的线程才能去获取锁，然后进入while循环中等待，直到别的线程调用.signal()方法，将该线程的节点放入同步队列中，再接着重新获取锁，接着执行await方法后面的代码。

signal()方法又是如何唤醒条件等待队列中的节点的呢？接着看下源码。

public final void signal() {
   //判断如果锁的占有线程不是当前线程，则抛出异常
   if (!isHeldExclusively())
      throw new IllegalMonitorStateException();
   // 如果条件等待队列中有等待的节点，则进行唤醒操作
   Node first = firstWaiter;
   if (first != null)
      doSignal(first);
 }

private void doSignal(Node first) {
  do {
     // 唤醒的节点，从条件等待队列中取出（即nextWaiter设置为null，
     // 当前节点的下一个节点设置为条件等待队列的头节点）
     if ( (firstWaiter = first.nextWaiter) == null)
        lastWaiter = null;
        first.nextWaiter = null;
  } while (!transferForSignal(first) &&
           (first = firstWaiter) != null);
}
 
final boolean transferForSignal(Node node) {
   // 将当前的节点的状态值waitStatus设为0，如果设置失败，则说明该节点CANCELLED超时/中断，不可被唤醒了
   if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
       return false;
   // 将该节点加入同步队列中，并返回同步队列中的原来的tail节点p
   Node p = enq(node);
   int ws = p.waitStatus;
   // 原来的节点p的状态被取消了，或者尝试给原来的tail节点设置Node.SIGNAL失败，则原来tail的下一个节点的线程，也就是刚加入的线程节点node上的线程，解除阻塞
   if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
       // 解除线程的阻塞
       LockSupport.unpark(node.thread);
   return true;
}

从上面的代码可以看出，当调用signal方法时，node节点被从条件等待队列中移除，并加入到同步队列中，准备运行。

写了这么多，总结起来就是：同步队列的首尾节点head和tail，线程构成的节点在此队列中等待获取资源执行自己线程的程序，排队执行就行了，轮到了就该执行了，而ConditionObject的条件等待队列首尾节点firstWaiter和lastWaiter，线程构成的节点在该队列中需要被signal将节点放入同步队列中才能获取资源执行内容。

这次看了下队列的构成，接下来就去学下锁的类型。