ReentrantLock是一个可重入的互斥锁,实现了接口Lock,和synchronized相比,它们提供了相同的功能,但ReentrantLock使用更灵活,功能更强大,也更复杂。这篇文章将为你介绍ReentrantLock,以及它的实现机制。
通常,ReentrantLock按下面的方式使用:
public class ReentrantLockTest {
private final ReentrantLock lock = new ReentrantLock();//问题1:lock为什么定义为final
public void m() {
lock.lock();
try {
// method body
} finally {
lock.unlock();
}
}
}
首先需要定义一个lock,在使用时首先通过lock的lock方法加锁,然后执行临界区代码,最后在final中调用lock的unlock方法解锁(防止异常后无法解锁)。想了解锁的实现原理,可以参考上一篇:“并发编程实践四:实现正确和高效的锁”。
ReentrantLock提供了两种锁:公平锁和非公平锁,默认是非公平锁。若指定为公平锁,则所有线程尽量按照调用lock的先后次序获取锁(问题二:为什么说尽量?),否则,如果为非公平锁,则调用lock的线程和等待队列中的线程将竞争锁。公平锁更加公平,但非公平锁则具有更好的性能。
ReentrantLock是可重入的,也就是一个线程可以多次调用lock成功,但要求调用了多少次lock,就需要对应调用多少次unlock,并且该锁最多支持同一个线程发起的2147483648(锁的数量是用一个int变量保存)个递归锁,超出这个限制将会导致lock方法抛出error。
ReentrantLock除了实现Lock接口外,还提供了一些辅助的方法,如:isLocked和getQueueLength等,这些方法对检测和监视可能很有用。
下面我将对这些功能的内部实现做详细的介绍。
ReentrantLock内部使用了一个AQS的实现类,我在“并发编程实践二:AbstractQueuedSynchronizer”中对AQS的基本流程做过一个基本的介绍,并涉及到一些代码细节,不过不了解AQS也不会影响对这篇文章的理解。ReentrantLock使用了AQS的互斥模式,下面我将分别介绍非公平锁、公平锁和ReentrantLock提供的辅助功能。
你可以使用下面的方法定义一个公平锁:
private final ReentrantLock lock = new ReentrantLock(false);或者直接
private final ReentrantLock lock = new ReentrantLock();
线程首先通过ReentrantLock的lock来申请锁,ReentrantLock的lock调用NonfairSync(AQS的实现类)的lock方法。
//NonfairSync的lock
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
NonfairSync的lock方法首先尝试更改AQS的状态(这里也就是新到的线程和等待队列中的线程竞争获取锁,新到的线程可能会获得成功,导致不公平),如果更改成功则修改当前锁的owner为自己,然后返回。否则进入acquire。
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
acquire调用tryAcquire来再次尝试获取锁,如果成功,则返回,否则调用addWaiter将自己加入等待队列,最后在acquireQueued中等待唤醒和执行唤醒后的操作。从tryAcquire开始:
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {//锁空闲
if (compareAndSetState(0, acquires)) {//尝试获取锁
setExclusiveOwnerThread(current);//设置锁owner
return true;
}
}
else if (current == getExclusiveOwnerThread()) {//owner是自己
int nextc = c + acquires;
if (nextc < 0) // 溢出,由于state是一个int,因此最多只能申请2147483648次
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
tryAcquire直接调用nonfairTryAcquire,nonfairTryAcquire首先获取AQS状态,如果状态为0,则说明当前锁已经空闲,则再次尝试更改状态,如果成功,则将锁的owner设置为自己,然后返回true,失败则返回false;如果AQS状态不为0,则说明锁已经被占用,如果owner是自己,则可以再次获取锁,如果锁已经溢出,则报错,否则设置AQS状态,返回true;不符合上述情况,返回false。
tryAcquire失败后,线程进入addWaiter将自己加入等待队列。
private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode);
Node pred = tail;
if (pred != null) {//队列已经初始化
node.prev = pred;
if (compareAndSetTail(pred, node)) {//尝试
pred.next = node;
return node;
}
}
enq(node);
return node;
}
private Node enq(final Node node) {
for (;;) {
Node t = tail;
if (t == null) { //初始化队列
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
addWaiter中,如果tail不为空,则将tail通过CAS设置为当前线程节点,如果成功,则返回;否则将进入enq中循环添加节点到tail,直到成功。enq中,如果tail为空,则应该是首次使用队列,需要初始化,则将队列的head设置为一个空节点,如果成功,则将tail等于head,否则,如果失败,则说明有其它线程已经初始化了head,进入下一个循环重新开始。若队列不为空,则更改tail为当前节点,循环直到成功。
在线程将自己添加到等待队列后,线程则进入acquireQueued中。
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);
}
}
acquireQueued中首先进行一个检查,如果当前节点的前续节点为head(说明当前节点已经为队列的第一个节点),则再次调用tryAcquire尝试获取锁(这个尝试是必须的,因为其它线程可能在该线程入队列之前已经释放了锁,如果不再次尝试,可能导致线程长时间等待),成功或则更改head(节点出队列),然后返回。如果当前节点的前续节点不为head,则首先在shouldParkAfterFailedAcquire中检查并更改前续节点状态,然后在parkAndCheckInterrupt中进入阻塞睡眠。
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
int ws = pred.waitStatus;
if (ws == Node.SIGNAL)
return true;
if (ws > 0) {
do {
node.prev = pred = pred.prev;
} while (pred.waitStatus > 0);
pred.next = node;
} else {
compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
}
return false;
}
shouldParkAfterFailedAcquire中需要判断pred的waitStatus,如果为Node.SIGNAL(表示其它线程释放锁后,会唤醒pred的后续节点的线程),则返回true,线程将在parkAndCheckInterrupt中进入阻塞睡眠;否则如果ws大于0(表示pred已经被取消),则将已经取消的节点删除,并返回false(可能node已经是队列的第一个节点,返回false将导致线程在acquireQueued中再次尝试获取锁,如果获取锁失败将再次进入shouldParkAfterFailedAcquire中);否则线程将尝试将pred的值设置为Node.SIGNAL,并返回false(返回false将导致在acquireQueued中再次尝试获取锁,这一点非常重要,因为释放锁的线程只有在pred的waitStatus为Node.SIGNAL时,才会执行唤醒线程的操作,而在这里将pred的waitStatus设置为Node.SIGNAL之前,可能其它线程已经释放了锁,如果不再尝试一次获取锁,可能会导致线程长时间阻塞,因此,在pred的waitStatus设置成功后,必须要重新再尝试一次)。
当pred的waitStatus为Node.SIGNAL后,则线程在parkAndCheckInterrupt中进入阻塞睡眠。
private final boolean parkAndCheckInterrupt() {
LockSupport.park(this);
return Thread.interrupted();
}
线程进入阻塞睡眠后,就需要另一个线程在释放了锁之后将其唤醒,另一个线程会调用lock的unlock方法。
public void unlock() {
sync.release(1);
}
unlock最终调用AQS的release方法。
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
release中线程使用tryRelease释放锁,释放锁成功后将进入唤醒等待线程的流程:如果队列不为空,并且head的waitStatus不为0(表示存在后续节点的线程等待被唤醒),则调用unparkSuccessor唤醒后续节点的线程。
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())//限制其它线程进入
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
tryRelease中获取AQS的状态,并减去releases(释放锁),得到c,如果执行的线程不是锁的owner,则抛出异常(这里就限制了后面的代码只有锁的owner线程能够进入),如果c为0,则表示锁已经被释放(如果线程获取了多次锁,则需要unlock多次后锁才能释放),将锁的owner设置为空,然后设置AQS的状态到c,返回锁是否已经释放。
释放锁成功后,线程将在unparkSuccessor中唤醒等待队列中的线程。
private void unparkSuccessor(Node node) {
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0);
Node s = node.next;
if (s == null || s.waitStatus > 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);
}
unparkSuccessor中,首先将node的waitStatus设置到0(node不再需要唤醒后续节点了),然后删除掉已经取消的节点,将最终有效的节点保存到s,如果s不为空,则执行唤醒操作。
线程执行完唤醒操作后,就退出结束了,然后唤醒的线程将重新进入acquireQueued中执行。
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);
}
}
acquireQueued中,唤醒的线程的节点的前续肯定为head,线程将调用tryAcquire尝试获取锁(唤醒的线程将和新到的线程一起竞争锁),如果获取锁成功,则修改head(出队列),并退出;否则将重新进入阻塞状态(是不是很郁闷)。
到这里,整个的流程就结束了,下面我们来看看公平锁。
公平锁和非公平锁流程大致相同,只是对新到的线程的处理上不一样,非公平锁是新到的线程和等待队列中的线程一起竞争锁,但公平锁则始终保证等待最长的线程获取锁。
公平锁的定义方式为:
private final ReentrantLock lock = new ReentrantLock(true);
公平锁和非公平锁的差异在于锁的获取上,公平锁的lock方法如下:
final void lock() {
acquire(1);
}
不像非公平锁直接尝试获取锁,公平锁不尝试获取锁,直接进入acquire,这里acquire的操作和非公平锁是一致的,区别在tryAcquire上。
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()) {//owner是自己
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
tryAcquire中公平锁在锁空闲(c==0)的情况下,首先通过hasQueuedPredecessors判断是否有等待线程,如果没有,才尝试获取锁,若获取锁成功,则将自己设置为锁的owner,并返回;如果锁不空闲,如果自己是锁的owner,则可以再次获取锁,否则返回false。
因此公平锁和非公平锁的区别就在于多了hasQueuedPredecessors判断。
public final boolean hasQueuedPredecessors() {
Node t = tail;
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
hasQueuedPredecessors中,如果tail和head不同,并且head的next为空或者head的next的线程不是当前线程,则表示队列不为空。有两种情况会导致h的next为空:
1)当前线程进入hasQueuedPredecessors的同时,另一个线程已经更改了tail(在enq中),但还没有将head的next指向自己,这中情况表明队列不为空;
2)当前线程将head赋予h后,head被另一个线程移出队列,导致h的next为空,这种情况说明锁已经被占用。
如果队列不为空(hasQueuedPredecessors返回true),则tryAcquire返回false,线程将进入等待队列(后面的流程和非公平锁一致)。
由于线程的调度,非公平锁在判断的过程中可能出现:
线程A调用tryAcquire失败后,并在调用addWaiter之前,线程B释放了锁,且线程C判断到锁空闲,进入hasQueuedPredecessors返回false(等待队列为空),最终C比A先获取到锁。
由此来看,公平锁也并非绝对公平。
并且,公平锁在使用中,后来的线程总是需要进入等待队列等待,会导致效率降低,从JDK文档的描述,效率将降低很多。
这篇文章主要介绍了ReentrantLock的公平锁和非公平锁的实现流程,公平锁尽量保证获取锁的公平性,采用先来先得的原则,但由于线程的调度,会导致某些后到的线程先获取到锁;非公平锁不保证锁的获取的公平性,新到的线程将和等待队列中的线程竞争锁。公平锁具备公平性但性能差,而非公平锁不保证公平性但具有更好的性能。