死磕Java并发:J.U.C之重入锁:ReentrantLock
ReentrantLock,可重入锁,是一种递归无阻塞的同步机制。它可以等同于synchronized的使用,但是ReentrantLock提供了比synchronized更强大、灵活的锁机制,可以减少死锁发生的概率。
API介绍如下:
一个可重入的互斥锁定 Lock,它具有与使用 synchronized 方法和语句所访问的隐式监视器锁定相同的一些基本行为和语义,但功能更强大。
ReentrantLock 将由最近成功获得锁定,并且还没有释放该锁定的线程所拥有。当锁定没有被另一个线程所拥有时,调用 lock 的线程将成功获取该锁定并返回。如果当前线程已经拥有该锁定,此方法将立即返回。可以使用 isHeldByCurrentThread() 和 getHoldCount() 方法来检查此情况是否发生。
ReentrantLock还提供了公平锁也非公平锁的选择,构造方法接受一个可选的公平参数(默认非公平锁),当设置为true时,表示公平锁,否则为非公平锁。公平锁与非公平锁的区别在于公平锁的锁获取是有顺序的。但是公平锁的效率往往没有非公平锁的效率高,在许多线程访问的情况下,公平锁表现出较低的吞吐量。
1、获取锁
我们一般都是这么使用ReentrantLock获取锁的:
lock方法:
public void lock() {
sync.lock();
}
Sync为ReentrantLock里面的一个内部类,它继承AQS(AbstractQueuedSynchronizer),它有两个子类:公平锁FairSync和非公平锁NonfairSync。
ReentrantLock里面大部分的功能都是委托给Sync来实现的,同时Sync内部定义了lock()抽象方法由其子类去实现,默认实现了nonfairTryAcquire(int acquires)方法,可以看出它是非公平锁的默认实现方式。下面我们看非公平锁的lock()方法:
final void lock() {
//尝试获取锁
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
//获取失败,调用AQS的acquire(int arg)方法
acquire(1);
}
首先会第一次尝试快速获取锁,如果获取失败,则调用acquire(int arg)方法,该方法定义在AQS中,如下:
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
这个方法首先调用tryAcquire(int arg)方法,在AQS中讲述过,tryAcquire(int arg)需要自定义同步组件提供实现,非公平锁实现如下:
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
final boolean nonfairTryAcquire(int acquires) {
//当前线程
final Thread current = Thread.currentThread();
//获取同步状态
int c = getState();
//state == 0,表示没有该锁处于空闲状态
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;
}
return false;
}
该方法主要逻辑:首先判断同步状态state == 0 ?,如果是表示该锁还没有被线程持有,直接通过CAS获取同步状态,如果成功返回true。如果state != 0,则判断当前线程是否为获取锁的线程,如果是则获取锁,成功返回true。成功获取锁的线程再次获取锁,这是增加了同步状态state。
2、释放锁
获取同步锁后,使用完毕则需要释放锁,ReentrantLock提供了unlock释放锁:
public void unlock() {
sync.release(1);
}
unlock内部使用Sync的release(int arg)释放锁,release(int arg)是在AQS中定义的:
public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h);
return true;
}
return false;
}
与获取同步状态的acquire(int arg)方法相似,释放同步状态的tryRelease(int arg)同样是需要自定义同步组件自己实现:
protected final boolean tryRelease(int releases) {
//减掉releases
int c = getState() - releases;
//如果释放的不是持有锁的线程,抛出异常
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
//state == 0 表示已经释放完全了,其他线程可以获取同步状态了
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}
只有当同步状态彻底释放后该方法才会返回true。当state == 0 时,则将锁持有线程设置为null,free= true,表示释放成功。
3、公平锁与非公平锁
公平锁与非公平锁的区别在于获取锁的时候是否按照FIFO的顺序来。释放锁不存在公平性和非公平性,上面以非公平锁为例,下面我们来看看公平锁的tryAcquire(int arg):
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()) {
int nextc = c + acquires;
if (nextc < 0)
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}
比较非公平锁和公平锁获取同步状态的过程,会发现两者唯一的区别就在于公平锁在获取同步状态时多了一个限制条件:hasQueuedPredecessors(),定义如下:
public final boolean hasQueuedPredecessors() {
Node t = tail; //尾节点
Node h = head; //头节点
Node s;
//头节点 != 尾节点
//同步队列第一个节点不为null
//当前线程是同步队列第一个节点
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
比较非公平锁和公平锁获取同步状态的过程,会发现两者唯一的区别就在于公平锁在获取同步状态时多了一个限制条件:hasQueuedPredecessors(),定义如下:
public final boolean hasQueuedPredecessors() {
Node t = tail; //尾节点
Node h = head; //头节点
Node s;
//头节点 != 尾节点
//同步队列第一个节点不为null
//当前线程是同步队列第一个节点
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
该方法主要做一件事情:主要是判断当前线程是否位于CLH同步队列中的第一个。如果是则返回true,否则返回false。
4、ReentrantLock与synchronized的区别
前面提到ReentrantLock提供了比synchronized更加灵活和强大的锁机制,那么它的灵活和强大之处在哪里呢?他们之间又有什么相异之处呢?
首先他们肯定具有相同的功能和内存语义。
与synchronized相比,ReentrantLock提供了更多,更加全面的功能,具备更强的扩展性。例如:时间锁等候,可中断锁等候,锁投票。
ReentrantLock还提供了条件Condition,对线程的等待、唤醒操作更加详细和灵活,所以在多个条件变量和高度竞争锁的地方,ReentrantLock更加适合(以后会阐述Condition)。
ReentrantLock提供了可轮询的锁请求。它会尝试着去获取锁,如果成功则继续,否则可以等到下次运行时处理,而synchronized则一旦进入锁请求要么成功要么阻塞,所以相比synchronized而言,ReentrantLock会不容易产生死锁些。
ReentrantLock支持更加灵活的同步代码块,但是使用synchronized时,只能在同一个synchronized块结构中获取和释放。注:ReentrantLock的锁释放一定要在finally中处理,否则可能会产生严重的后果。
ReentrantLock支持中断处理,且性能较synchronized会好些。
- END -
热文:
Intellij IDEA神器那些让人爱不释手的14种小技巧,统统告诉你!
一文告诉你,Intellij IDEA神器隐藏的11种实用小技巧!
往期推荐:
死磕Java系列:
深入分析ThreadLocal
深入分析synchronized的实现原理
深入分析volatile的实现原理
Java内存模型之happens-before
Java内存模型之重排序
Java内存模型之分析volatile
Java内存模型之总结
J.U.C之AQS简介
J.U.C之AQS:CLH同步队列
……
Spring系列:
Spring Cloud Zuul中使用Swagger汇总API接口文档
Spring Cloud Config Server迁移节点或容器化带来的问题
Spring Cloud Config对特殊字符加密的处理
Spring Boot使用@Async实现异步调用:使用Future以及定义超时
Spring Cloud构建微服务架构:分布式配置中心(加密解密)
Spring Boot快速开发利器:Spring Boot CLI
……
可关注我的公众号
深入交流、更多福利
扫码加入我的知识星球
点击“阅读原文”,看本号其他精彩内容
死磕Java并发:J.U.C之重入锁:ReentrantLock相关推荐
- 死磕Java并发:J.U.C之并发工具类:CountDownLatch
作者:chenssy 来源:Java技术驿站 在上篇博客中介绍了Java四大并发工具一直的CyclicBarrier,今天要介绍的CountDownLatch与CyclicBarrier有点儿相似. ...
- 死磕Java并发:J.U.C之阻塞队列:ArrayBlockingQueue
作者:chenssy 来源:Java技术驿站 ArrayBlockingQueue,一个由数组实现的有界阻塞队列.该队列采用FIFO的原则对元素进行排序添加的. ArrayBlockingQueue为 ...
- 死磕Java并发:J.U.C之Java并发容器:ConcurrentLinkedQueue
作者:chenssy 来源:Java技术驿站 要实现一个线程安全的队列有两种方式:阻塞和非阻塞.阻塞队列无非就是锁的应用,而非阻塞则是CAS算法的应用.下面我们就开始一个非阻塞算法的研究:Coucur ...
- 死磕Java并发:J.U.C之并发工具类:Exchanger
作者:chenssy 来源:Java技术驿站 前面三篇博客分别介绍了CyclicBarrier.CountDownLatch.Semaphore,现在介绍并发工具类中的最后一个Exchange.Exc ...
- 死磕Java并发:J.U.C之Condition
作者:chenssy 来源:http://cmsblogs.com/?p=2222 在没有Lock之前,我们使用synchronized来控制同步,配合Object的wait().notify()系列 ...
- 死磕Java并发:J.U.C之读写锁:ReentrantReadWriteLock
作者:chenssy 来源:http://cmsblogs.com/?p=2213 重入锁ReentrantLock是排他锁,排他锁在同一时刻仅有一个线程可以进行访问,但是在大多数场景下,大部分时间都 ...
- 死磕Java并发:J.U.C之AQS:CLH同步队列
本文转载自公号:Java技术驿站 在上篇文章"死磕Java并发:J.U.C之AQS简介"中提到了AQS内部维护着一个FIFO队列,该队列就是CLH同步队列. CLH同步队列是一个F ...
- 死磕Java并发:J.U.C之AQS简介
本文转载自公众号: Java技术驿站 Java的内置锁一直都是备受争议的,在JDK 1.6之前,synchronized这个重量级锁其性能一直都是较为低下,虽然在1.6后,进行大量的锁优化策略(死磕J ...
- 【死磕Java并发】-----J.U.C之AQS:CLH同步队列
原文出处:https://www.cmsblogs.com/category/1391296887813967872 『chenssy』 在上篇博客[死磕Java并发]-----J.U.C之AQS:A ...
- 死磕Java并发:J.U.C之并发工具类:Semaphore
作者:chenssy 来源:Java技术栈公众号 信号量Semaphore是一个控制访问多个共享资源的计数器,和CountDownLatch一样,其本质上是一个"共享锁". Sem ...
最新文章
- watch netstat
- 用100行python代码发现语音识别文本错误词,并将结果和正确词一一对应
- SQL Server 清空或删除所有数据库表中的数据
- tms320c2000 c语言伪指令,TMS320F240XDSP汇编及C语言多功能控制应用(附光盘)
- TensorFlow 教程 --进阶指南--3.5线程和队列
- 95-130-348-源码-source-kafka相关-Handover
- codeforces 848B Rooter's Song 思维题
- php中adodb中文手册,[转载]ADODB中文手册(4)
- 网吧服务器维护工具,某某网吧专用维护工具(网吧维护管理助手)V5.1 最新版
- 读取日志时发生乱码的解决方法
- mysql数据库性能监控工具MONyog实战
- 基于opengl的2d机器人双人格斗游戏
- kali制作钓鱼网站
- [C++] [OpenGL] 基于GLFW+GLAD的OpenGL简单程序
- 50欧姆系统的由来的小故事
- 2.9 zio入门——递归和ZIO
- latex 的“对号”的几种表示
- SparkSQL in中使用子查询耗时高如何优化
- 北京市社保定点医疗机构查询【2021年1月】
- 开源堡垒机JumpServer远程命令执行漏洞复现
热门文章
- linux shell 打印当前行号
- 各类攻击 单一协议 pcap数据包 下载网站
- 使用FindFirstFile,FindNextFile遍历一个文件夹
- JAVA 继承基本类、抽象类、接口
- ICA--独立成分分析(Independent Component Analysis)
- (七)Amazon Lightsail 部署LAMP应用程序之清除已安装服务
- 使用 shell 脚本对 Linux 系统和进程资源进行监控
- php+实现群发微信模板消息_php实现发送微信模板消息的方法,php信模板消息_PHP教程...
- java中路径中参数化_Azure数据工厂:参数化文件夹和文件路径
- Problem 59 GCC密切相关的一些环境变量?