前言:
对于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将节点放入同步队列中才能获取资源执行内容。
这次看了下队列的构成,接下来就去学下锁的类型。