共计 4619 个字符,预计需要花费 12 分钟才能阅读完成。
本文首发于微信公众号【WriteOnRead】,欢送关注。
1. 概述
在 JDK 1.5 以前,锁的实现只能用 synchronized 关键字;1.5 开始提供了 ReentrantLock,它是 API 层面的锁。先看下 ReentrantLock 的类签名以及如何应用:
public class ReentrantLock implements Lock, java.io.Serializable {}
典型用法:
public void m() {lock.lock(); // block until condition holds
try {// ... method body} finally {lock.unlock()
}
}
该用法和应用 synchronized 关键字成果是一样的。既然有了 synchronized,为什么又会有 Lock 呢?相比于 synchronized,其实 ReentrantLock 的呈现并不反复,它减少了不少性能,上面先简略介绍几个概念:
- 偏心锁 & 非偏心锁
所谓锁是否偏心,简略了解就是一系列线程获取到锁的程序是否遵循「先来后到」。即,如果先申请锁的线程先获取到锁,就是偏心锁;否则就是非偏心锁。ReentrantLock 的默认实现和 synchronized 都是非偏心锁。
- 可重入锁
锁是否可重入,就是一个线程是否能够屡次获取同一个锁,若是,就是可重入锁。ReentrantLock 和 synchronized 都是可重入锁。
2. 代码剖析
2.1 结构器
ReentrantLock 有两个结构器,别离如下:
private final Sync sync;
// 结构一个 ReentrantLock 实例(非偏心锁)public ReentrantLock() {sync = new NonfairSync();
}
// 结构一个 ReentrantLock 实例(指定是否偏心)public ReentrantLock(boolean fair) {sync = fair ? new FairSync() : new NonfairSync();}
能够看到,两个结构器都是初始化一个 Sync 类型的成员变量。而且,当 boolean 值 fair 为 true 时,初始化的 sync 为 FairSync,为 false 时初始化为 NonFairSync,二者别离示意「偏心锁」和「非偏心锁」。能够看到无参结构默认是非偏心锁。
2.2 罕用办法
ReentrantLock 罕用的办法就是 Lock 接口定义的几个办法,如下:
// 获取锁(阻塞式)public void lock() {sync.lock();
}
// 获取锁(响应中断)public void lockInterruptibly() throws InterruptedException {sync.acquireInterruptibly(1);
}
// 尝试获取锁
public boolean tryLock() {return sync.nonfairTryAcquire(1);
}
// 尝试获取锁(有超时期待)public boolean tryLock(long timeout, TimeUnit unit)
throws InterruptedException {return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}
// 开释锁
public void unlock() {sync.release(1);
}
能够看到,这几个办法外部都是通过调用 Sync 类(或其子类)的办法来实现,因而先从 Sync 类动手剖析,代码如下(局部省略):
// 抽象类,继承了 AQS
abstract static class Sync extends AbstractQueuedSynchronizer {
// 获取锁的办法,由子类实现
abstract void lock();
// 非偏心锁的 tryLock 办法实现
final boolean nonfairTryAcquire(int acquires) {final Thread current = Thread.currentThread();
// 获取 AQS 的 state 变量
int c = getState();
// 若为 0,示意以后没有被其余线程占用
if (c == 0) {
// CAS 批改 state,若批改胜利,示意胜利获取资源
if (compareAndSetState(0, acquires)) {
// 将以后线程设置为 owner,到这里示意以后线程胜利获取资源
setExclusiveOwnerThread(current);
return true;
}
}
// state 不为 0,且 owner 为以后线程
// 示意以后线程曾经获取到了资源,这里示意“重入”else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
// 批改 state 值(因为以后线程曾经获取资源,不存在竞争,因而无需 CAS 操作)setState(nextc);
return true;
}
return false;
}
// 开释锁操作(对 state 做减法)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;
// 胜利开释后将 owner 设为空
setExclusiveOwnerThread(null);
}
// 批改 state 的值
// PS: 因为可能存在“重入”,因而一次开释操作后以后线程仍有可能占用资源,// 所以不会间接把 state 设为 0
setState(c);
return free;
}
// 其余办法...
final boolean isLocked() {return getState() != 0;
}
}
Sync 类继承自 AQS,其中 nonfairTryAcquire 办法是非偏心锁 tryAcquire 办法的实现。
从下面代码能够看出,锁的获取和开释是通过批改 AQS 的 state 变量来实现的。lock 办法能够看做对 state 执行“加法”操作,而 unlock 能够看做对 state 执行“减法”操作,当 state 为 0 时,示意以后没有线程占用资源。
2.3 偏心锁 & 非偏心锁
2.3.1 非偏心锁 NonFairSync
static final class NonfairSync extends Sync {final void lock() {
// CAS 尝试将 state 值批改为 1
if (compareAndSetState(0, 1))
// 若批改胜利,则将以后线程设为 owner,示意胜利获取锁
setExclusiveOwnerThread(Thread.currentThread());
// 若获取失败,则执行 AQS 的 acquire 办法(独占模式获取资源)else
acquire(1);
}
protected final boolean tryAcquire(int acquires) {return nonfairTryAcquire(acquires);
}
}
能够看到,非偏心锁的 lock 操作为:先尝试以 CAS 形式批改 state 的值,若批改胜利,则示意胜利获取到锁,将 owner 设为以后线程;否则就执行 AQS 中的 acquire 办法,具体可参考前文「JDK 源码剖析 -AbstractQueuedSynchronizer(2)」,这里不再赘述。
2.3.2 偏心锁 FairSync
static final class FairSync extends Sync {final void lock() {acquire(1);
}
// 偏心锁的 tryAcquire 实现
protected final boolean tryAcquire(int acquires) {final Thread current = Thread.currentThread();
int c = getState();
// state 为 0,示意资源未被占用
if (c == 0) {
// 若队列中有其余线程在排队期待,则返回 false,示意获取失败;// 否则,再尝试去批改 state 的值
// PS: 这里是偏心锁与非偏心锁的区别所在
if (!hasQueuedPredecessors() &&
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;
}
}
能够看到,与非偏心锁相比,偏心锁的不同之处在于减少了判断条件 hasQueuedPredecessors,即首先判断主队列中是否有其余线程在期待,当没有其余线程在排队时再去获取,否则获取失败。
hasQueuedPredecessors 在 AQS 中实现如下:
/**
* Queries whether any threads have been waiting to acquire longer
* than the current thread.
*/
public final boolean hasQueuedPredecessors() {
// The correctness of this depends on head being initialized
// before tail and on head.next being accurate if the current
// thread is first in queue.
Node t = tail; // Read fields in reverse initialization order
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
3. 小结
synchronized 与 ReentrantLock 比拟:
- 相同点:二者都是互斥锁,可重入,默认都是非偏心锁。
- 不同点:synchronized 是语法层面实现,主动获取锁和开释锁;ReentrantLock 是 API 层面实现,手动获取锁和开释锁。
ReentrantLock 相比 synchronized 的劣势:
- 可响应中断;
- 获取锁可设置超时;
- 可实现偏心锁;
- 可绑定多个条件(Condition)。
PS: JDK 1.6 当前,synchronized 与 ReentrantLock 性能根本持平,JVM 将来的性能优化也会更偏差于原生的 synchronized。因而,如何抉择还要依据理论需要,性能不再是不抉择 synchronized 的起因了。
相干浏览:
JDK 源码剖析 -Lock&Condition
JDK 源码剖析 -AbstractQueuedSynchronizer(2)