博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
Java多线程进阶(三)—— J.U.C之locks框架:ReentrantLock
阅读量:6977 次
发布时间:2019-06-27

本文共 1182 字,大约阅读时间需要 3 分钟。

timg (2).jpeg

本文首发于一世流云的专栏:

一、ReentrantLock类简介

ReentrantLock类,实现了接口,是一种可重入独占锁,它具有与使用 synchronized 相同的一些基本行为和语义,但功能更强大。ReentrantLock内部通过内部类实现了AQS框架(AbstractQueuedSynchronizer)的API来实现独占锁的功能。

1.1 类声明

ReentrantLock类直接实现了接口:

ReentrantLock类声明

1.2 构造声明

ReentrantLock类提供了两类构造器:

ReentrantLock构造声明

ReentrantLock类的其中一个构造器提供了指定公平策略 / 非公平策略的功能,默认为非公平策略

公平策略:在多个线程争用锁的情况下,公平策略倾向于将访问权授予等待时间最长的线程。也就是说,相当于有一个线程等待队列,先进入等待队列的线程后续会先获得锁,这样按照“先来后到”的原则,对于每一个等待线程都是公平的。
非公平策略:在多个线程争用锁的情况下,能够最终获得锁的线程是随机的(由底层OS调度)。

注意:一般情况下,使用公平策略的程序在多线程访问时,总体吞吐量(即速度很慢,常常极其慢)比较低,因为此时在线程调度上面的开销比较大。

举个例子:

假设采用公平策略,线程A首先获取了锁,线程B和线程C等待获取锁,如下图:
image.png

当线程A释放锁时,线程B将经历从 挂起->唤醒 的线程调度过程,线程调度非常耗时。

在线程B的 挂起->唤醒 阶段:

  1. 如果采用非公平策略,那么线程C可以立即获取锁,线程C使用完并释放锁后,线程B可能才刚唤醒完成;此时线程B又可以去获取锁,这样线程B和线程C的效率都得到提升,系统吞吐量提升;
  2. 如果采用公平策略,线程C即使可用,也要等到线程调度完成,整个系统的吞吐量降低。

因此,当线程持有锁的时间相对较长或者线程请求锁的平均时间间隔较长时,可以考虑使用公平策略。此时线程调度产生的耗时间隔影响会较小。

1.3 使用方式

ReentrantLock的典型调用方式如下:

class X {    private final ReentrantLock lock = new ReentrantLock();    // ...    public void m() {        lock.lock(); // block until condition holds        try {            // ... method body        } finally {            lock.unlock();        }    }}

二、ReentrantLock类原理

ReentrantLock的源码非常简单,它通过内部类实现了AQS框架,Lock接口的实现仅仅是对AQS的api的简单封装,

参见AQS原理:

转载地址:http://tkypl.baihongyu.com/

你可能感兴趣的文章
linux 内核 出错-HP 方案
查看>>
Linux
查看>>
HashSet的使用
查看>>
WSFC 仲裁模型选择
查看>>
nginx安装 问题 1
查看>>
MST配置详解
查看>>
linux下用phpize给PHP动态添加扩展
查看>>
任意排列、组合终极Shell脚本
查看>>
★核心关注点_《信息系统项目管理师考试考点分析与真题详解》
查看>>
Go处理百万每分钟的请求
查看>>
你以为自己在填验证码,其实你是在给Google义务劳动
查看>>
linux实战考试题:批量创建用户和密码(不能使用循环)
查看>>
一个基于J2EE的web应用程序运行起来需要什么?
查看>>
Docker配置指南系列(二):指令集(二)
查看>>
nginx 开发一个简单的 HTTP 模块
查看>>
linux运维如何月薪过万?(收藏自用)
查看>>
DIY强大的虚拟化环境-技术可行性部分
查看>>
linxu 下安装mysql5.7.19
查看>>
SpringMVC + Hibernate-Validator 参数校验
查看>>
android开发之动画的详解 整理资料 Android开发程序小冰整理
查看>>