ReentrantLock(重入锁)以及公平性

ReentrantLock(重入锁)以及公平性

标签(空格分隔): java NIO


如果在绝对时间上,先对锁进行获取的请求一定被先满足,那么这个锁是公平的,反之,是不公平的,也就是说等待时间最长的线程最有机会获取锁,也可以说锁的获取是有序的。ReentrantLock这个锁提供了一个构造函数,能够控制这个锁是否是公平的。

而锁的名字也是说明了这个锁具备了重复进入的可能,也就是说能够让当前线程多次的进行对锁的获取操作,这样的最大次数限制是Integer.MAX_VALUE,约21亿次左右。

具体实现

非公平:

final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
//获取当前状态
int c = getState();
if (c == 0) {//如果当前状态为初始状态
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);//设置状态
return true;
}
//不是初始状态,当前申请锁的线程就是锁的持有线程
} else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;//状态自增
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
//状态不为0(锁被占用中),当前线程不是持有线程,返回失败
//即 锁正被别的线程占用,则请求失败
return false;
}

公平:

protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
//区别在于这里多了一项判断:是否是等待队列里的第一个
//效果是:如果锁被自己的线程持有着,仍然可以重入(即'else-if')。
//但如果锁时空闲着的,则先来先得(排在队首)
if (isFirst(current) && compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
} else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}

进行lock操作时

/*ReentrantLock->NonfairSync */
final void lock() {
//如果锁空闲,直接使用,无需排队;否则进行请求
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
} /*AbstractQueuedSynchronizer */
public final void acquire(int arg) {
//注意,A&B运算,如果A==False,则不会执行B
//因此,如果tryAcquire成功,则不执行后面的“在sync队列中排队”操作
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}

上述代码,即非公平的acquire,如下图所示

ReentrantLock(重入锁)以及公平性

  • Fast:tryAcquire,非公平的获取
  • normal: 进入请求队列

    这意味着,某条线程释放完锁,也可以不经过等待队列,而通过Fast通道再次获得锁。

这种模式,可以保证进入和退出锁的吞吐量,但是sync队列中过早排队的线程会一直处于阻塞状态,造成“饥饿”场景。在非公平锁中,CPU的处理时间中,只有很少的时间花在线程调度上,大多都用在实际工作上。


非公平锁性能高于公平锁性能的原因

在恢复一个被挂起的线程与该线程真正运行之间存在着严重的延迟。

考虑如下场景:线程A释放了锁,队列中第一个线程B将从[挂起]状态向[唤醒]状态,并再次请求锁。在B未完成唤醒前,线程C也开始请求锁。

  • 公平锁:虽然锁现在是空闲的,但因为队列中还有线程B排在前面,因此C需进队列等待,状态变为[挂起]。从‘C到来’至‘B完全唤醒’之间的时间T,锁是空闲的,被浪费了。
  • 非公平锁:由于此时锁是空闲的,C直接获得锁。如果C工作执行的快,可能当释放锁之后,B尚未完全唤醒,则原本会被浪费的时间T被利用了。但如果B唤醒后C还未执行完,则B又要挂起继续等待。

因此,当持有锁的时间相对较长或者请求锁的平均时间间隔较长,应该使用公平锁。在这些情况下,插队带来的吞吐量提升(当锁处于可用状态时,线程却还处于被唤醒的过程中)可能不会出现。

上一篇:redis配置主从备份以及主备切换方案配置


下一篇:ReentrantLock(重入锁)的源码解析