【JDK】JDK源码分析-ReentrantLock
概述
在 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 都是可重入锁。
代码分析
构造器
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,二者分别表示「公平锁」和「非公平锁」。可以看到无参构造默认是非公平锁。
常用方法
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 时,表示当前没有线程占用资源。
公平锁&非公平锁
(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)公平锁 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());
}
小结
synchronized 与 ReentrantLock 比较:
相同点:二者都是互斥锁,可重入,默认都是非公平锁。
不同点:synchronized 是语法层面实现,自动获取锁和释放锁;ReentrantLock 是 API 层面实现,手动获取锁和释放锁。
ReentrantLock 相比 synchronized 的优势:
1. 可响应中断;
2. 获取锁可设置超时;
3. 可实现公平锁;
4. 可绑定多个条件(Condition)。
JDK 1.6 以后,synchronized 与 ReentrantLock 性能基本持平,JVM 未来的性能优化也会更偏向于原生的 synchronized。因此,如何选择还要根据实际需求,性能不再是不选择 synchronized 的原因了。
相关阅读:
JDK源码分析-AbstractQueuedSynchronizer(2)
Stay hungry, stay foolish.
PS: 本文首发于微信公众号【WriteOnRead】。
【JDK】JDK源码分析-ReentrantLock的更多相关文章
- JDK Collection 源码分析(2)—— List
JDK List源码分析 List接口定义了有序集合(序列).在Collection的基础上,增加了可以通过下标索引访问,以及线性查找等功能. 整体类结构 1.AbstractList 该类作为L ...
- JDK AtomicInteger 源码分析
@(JDK)[AtomicInteger] JDK AtomicInteger 源码分析 Unsafe 实例化 Unsafe在创建实例的时候,不能仅仅通过new Unsafe()或者Unsafe.ge ...
- 设计模式(十八)——观察者模式(JDK Observable源码分析)
1 天气预报项目需求,具体要求如下: 1) 气象站可以将每天测量到的温度,湿度,气压等等以公告的形式发布出去(比如发布到自己的网站或第三方). 2) 需要设计开放型 API,便于其他第三方也能接入气象 ...
- [源码分析]ReentrantLock & AbstractQueuedSynchronizer & Condition
首先声明一点: 我在分析源码的时候, 把jdk源码复制出来进行中文的注释, 有时还进行编译调试什么的, 为了避免和jdk原生的类混淆, 我在类前面加了"My". 比如把Reentr ...
- JDK Collection 源码分析(3)—— Queue
@(JDK)[Queue] JDK Queue Queue:队列接口,对于数据的存取,提供了两种方式,一种失败会抛出异常,另一种则返回null或者false. 抛出异常的接口:add,remove ...
- JDK Collection 源码分析(1)—— Collection
JDK Collection JDK Collection作为一个最顶层的接口(root interface),JDK并不提供该接口的直接实现,而是通过更加具体的子接口(sub interface ...
- Java并发编程之ReentrantLock源码分析
ReentrantLock介绍 从JDK1.5之前,我们都是使用synchronized关键字来对代码块加锁,在JDK1.5引入了ReentrantLock锁.synchronized关键字性能比Re ...
- JDK源码分析—— ArrayBlockingQueue 和 LinkedBlockingQueue
JDK源码分析—— ArrayBlockingQueue 和 LinkedBlockingQueue 目的:本文通过分析JDK源码来对比ArrayBlockingQueue 和LinkedBlocki ...
- JDK源码分析(11)之 BlockingQueue 相关
本文将主要结合源码对 JDK 中的阻塞队列进行分析,并比较其各自的特点: 一.BlockingQueue 概述 说到阻塞队列想到的第一个应用场景可能就是生产者消费者模式了,如图所示: 根据上图所示,明 ...
随机推荐
- 跟我学SpringCloud | 第六篇:Spring Cloud Config Github配置中心
SpringCloud系列教程 | 第六篇:Spring Cloud Config Github配置中心 Springboot: 2.1.6.RELEASE SpringCloud: Greenwic ...
- html、javascript、url特殊字符的转义诠释及使用方法详解
html.javascript.url特殊字符转义在实际编程中都是有用到的,有的人对特殊字符转义的使用不是很清楚,下面就对html,javascript,url特殊字符的转义做一下说明和归纳. htm ...
- 记2017青岛ICPC
2017青岛ICPC 11月4日 早上很早到达了青岛,然后去报道,走了好久的校园,穿的很少冷得瑟瑟发抖.中午教练请吃大餐,吃完饭就去热身赛了. 开幕式的时候,教练作为教练代表讲话,感觉周围的队伍看过来 ...
- Salesforce Admin篇(二) Report
针对salesforce系统也好,针对其他的平台系统也好,对于business user的需求以及疑问,数据往往决定了答案.业务人员提出了某些疑问,管理员需要根据需求的分析转换成数据的分析及过滤从而反 ...
- git rebase VS git merge? 更优雅的 git 合并方式值得拥有
写在前面 如果你不能很好的应用 Git,那么这里为你提供一个非常棒的 Git 在线练习工具 Git Online ,你可以更直观的看到你所使用的命令会产生什么效果 另外,你在使用 Git 合并分支时只 ...
- 修改Windows10的host文件。
一.Windows10中host地址. c:\windows\system32\drivers\etc\hosts 其他系统中的位置. Windows操作系统(Windows XP/7/8/10): ...
- C# .net Ueditor实现图片上传到阿里云OSS 对象存储
在学习的时候,项目中需要实现在Ueditor编辑器中将图片上传到云储存中,老师演示的是上传到又拍云存储,既然看了一遍,直接照搬不算本事,咱们可以依葫芦画瓢自己来动手玩玩其它的云存储服务. 现在云计算产 ...
- 通过sparkstreaming分析url的数据
spark version 1.6.2 scala verson 2.10.6 此代码参考官方例子---- 自定义接收器 import java.io.BufferedReader import or ...
- 掌握简单的Makefile文件编程
Makefile描述整个程序的编译.链接规则 其中还包括了工程中用到的那些源文件及需要产生的目标文件 1)Makefile编程规则 目标(唯一):依赖(可多个) 命令... 伪目标 .PHONY:cl ...
- python 3.5学习笔记(第五章)
本章内容 1.什么是模块 2.模块的导入方法 3.搜索路径 4.重要标准库 一.什么是模块 1.模块本质上是一个以.py 结尾的python文件,包含了python对象定义和python语句. 2.模 ...