前言：
对于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将节点放入同步队列中才能获取资源执行内容。
这次看了下队列的构成，接下来就去学下锁的类型。
386
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
