Java 读写锁源码分析

2024-08-27 15:45:12

前言

在实际项目中，比如我们有一个共享资源文件，我们程序会会同时并发的去读、写这个共享资源文件，那怎么能保证在高并发场景下安全、高效读写呢？OK，看了下文便知

提示：以下是本篇文章正文内容，案例仅供参考

一、技术介绍

1.ReentranReadWriteLock是什么？

ReadWriteLock提供了readLock和writeLock两种锁的操作机制，一个是读锁，一个是写锁，而它的实现类就是ReentranReadWriteLock

读锁可以在没有写锁的时候被多个线程同时持有，写锁是独占的(排他的)。这意味着每次只能有一个线程写，但可以多个线程并发地读。

理论上，读写锁比互斥锁允许对于共享数据更大程度的并发。与互斥锁相比，读写锁是否能够提高性能取决于读写数据的频率、读取和写入操作的持续时间、以及读线程和写线程之间的竞争。

二、源码分析

1.ReadLock

直接看ReadLock源码

可以看到ReadLock的lock操作实际实现对应Sync的 tryAcquireShared 方法，我们点进去看看

如果另一个线程持有写锁，则失败。
readerShouldBlock():读锁是否需要等待（公平锁原则）； r < MAX_COUNT：持有线程小于最大数；compareAndSetState(c, c + SHARED_UNIT)：设置读取锁状态；整体意思就是读线程是否应该被阻塞、并且小于最大值、并且比较设置成功
else判断里读锁数量不为0并且不为当前线程，获取计数器并且+1
最后的这行方法执行是由于线程显然不符合条件，或者CAS失败或计数饱和，使用完整版本的获取，这里面的方法可处理CAS miss 和tryAcquireShared中未处理的可重入读

2.WriteLock

再接着看WriteLock源码

exclusiveCount方法的作用是将同步变量与0xFFFF做&运算，计算结果就是写锁的数量,因此w的值的含义就是写锁的数量如果c不为0就表示锁被占用了，占用的是写锁还是读锁呢？这个时候就需要根据w的值来判断了。如果c等于0就表示此时锁还没有被任何线程占用，那就让线程直接去尝试获取锁.

如果w为0，说明写锁数量为0，而此时又因为c不等于0，说明锁被占用，但是不是写锁，那么此时锁的状态一定是读锁，既然是读锁状态，那么写锁此时来获取锁时，就肯定失败，因此当w等于0时，tryAcquire方法返回false。

如果w不为0，说明此时锁的状态时写锁，接着进行current != getExclusiveOwnerThread()判断，判断持有锁的线程是否是当前线程

如果不是当前线程，那么tryAcquire()返回false；如果是当前线程，那么就进行后面的逻辑。为什么是当前线程持有锁，就还能执行后面的逻辑呢？那是因为读写锁是可重入的。

三、单元测试

OK，不废话，接下来上简单直接的单元测试

package com.hyh.core.test;

import org.junit.Test;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantReadWriteLock;

/**
 * 可重入读写锁 TEST
 *
 * @Author: heyuhua
 * @Date: 2021/1/28 14:14
 */
public class ReentranReadWriteLockTest {

  ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock();
  Lock readLock = reentrantReadWriteLock.readLock();
  Lock writeLock = reentrantReadWriteLock.writeLock();

  @Test
  public void test() throws InterruptedException {
    ExecutorService threadPool = Executors.newFixedThreadPool(10);
    for (int i = 0; i < 5; i++) {
      threadPool.execute(() -> {
        readLock();
      });
      threadPool.execute(() -> {
        writeLock();
      });
    }
    threadPool.shutdown();
    TimeUnit.SECONDS.sleep(10);
  }

  private void readLock() {
    readLock.lock();
    try {
      System.out.println(Thread.currentThread().getName() + "-获取读锁...");
      TimeUnit.SECONDS.sleep(1);
    } catch (InterruptedException e) {
      e.printStackTrace();
    } finally {
      System.out.println(Thread.currentThread().getName() + "-释放读锁...");
      readLock.unlock();
    }
  }

  private void writeLock() {
    writeLock.lock();
    try {
      System.out.println(Thread.currentThread().getName() + "-获取写锁...");
      TimeUnit.SECONDS.sleep(1);
    } catch (InterruptedException e) {
      e.printStackTrace();
    } finally {
      System.out.println(Thread.currentThread().getName() + "-释放写锁...");
      writeLock.unlock();
    }
  }

}

这里模拟5个读和5个写的并发情况，马上看下执行结果

可以看到多个线程都可以同时获得读锁，而写锁必须等读锁释放了后才能获取，同样的读锁必须等写锁释放了后才能获取

总结

读写锁总结一句话：读读共享、写写互斥、读写互斥。

读写锁的适用场合：相比于 ReentrantLock 适用于一般场合，ReadWriteLock 适用读多写少的场景，合理使用可以进一步提高并发

作者寄语

是不是感觉很简单？更多用法请点击下方查看源码,关注我带你揭秘更多高级用法

源码地址：点此查看源码

以上就是Java 读写锁源码分析的详细内容，更多关于Java 读写锁的资料请关注我们其它相关文章！

Java编程读写锁详解

ReadWriteLock也是一个接口,提供了readLock和writeLock两种锁的操作机制,一个资源可以被多个线程同时读,或者被一个线程写,但是不能同时存在读和写线程. 基本规则: 读读不互斥读写互斥写写互斥问题: 既然读读不互斥,为何还要加读锁答: 如果只是读,是不需要加锁的,加锁本身就有性能上的损耗如果读可以不是最新数据,也不需要加锁如果读必须是最新数据,必须加读写锁读写锁相较于互斥锁的优点仅仅是允许读读的并发,除此之外并无其他. 结论: 读写锁能够保证读取数据的严格
Java 读写锁实现原理浅析

最近做的一个小项目中有这样的需求:整个项目有一份config.json保存着项目的一些配置,是存储在本地文件的一个资源,并且应用中存在读写(读>>写)更新问题.既然读写并发操作,那么就涉及到操作互斥,这里自然想到了读写锁,本文对读写锁方面的知识做个梳理. 为什么需要读写锁? 与传统锁不同的是读写锁的规则是可以共享读,但只能一个写,总结起来为:读读不互斥,读写互斥,写写互斥,而一般的独占锁是:读读互斥,读写互斥,写写互斥,而场景中往往读远远大于写,读写锁就是为了这种优化而创建出来的一种机制. 注
Java多线程编程中线程锁与读写锁的使用示例

线程锁Lock Lock 相当于当前对象的 Synchronized import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; /* * Lock lock = new ReentrantLock(); * lock.lock(); lock.unLock(); * 类似于 synchronized,但不能与synchronized 混用 */ public class L
举例说明Java多线程编程中读写锁的使用

以下示例为 java api并发库中 ReentrantReadWriteLock自带的实例,下面进行解读 class CachedData { Object data; volatile boolean cacheValid; ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(); void processCachedData() { rwl.readLock().lock();//@1 if (!cacheValid) { //
Java多线程编程之读写锁ReadWriteLock用法实例

读写锁:分为读锁和写锁,多个读锁不互斥,读锁与写锁互斥,这是由jvm自己控制的,你只要上好相应的锁即可.如果你的代码只读数据,可以很多人同时读,但不能同时写,那就上读锁:如果你的代码修改数据,只能有一个人在写,且不能同时读取,那就上写锁.总之,读的时候上读锁,写的时候上写锁! 三个线程读数据,三个线程写数据示例: 可以同时读,读的时候不能写,不能同时写,写的时候不能读. 读的时候上读锁,读完解锁:写的时候上写锁,写完解锁. 注意finally解锁. package com.ljq.test.th
Java并发编程之显示锁ReentrantLock和ReadWriteLock读写锁

在Java5.0之前,只有synchronized(内置锁)和volatile. Java5.0后引入了显示锁ReentrantLock. ReentrantLock概况 ReentrantLock是可重入的锁,它不同于内置锁, 它在每次使用都需要显示的加锁和解锁, 而且提供了更高级的特性:公平锁, 定时锁, 有条件锁, 可轮询锁, 可中断锁. 可以有效避免死锁的活跃性问题.ReentrantLock实现了 Lock接口: 复制代码代码如下: public interface Lock {
Java并发编程之重入锁与读写锁

重入锁重入锁,顾名思义,就是支持重进入的锁,它表示该锁能够支持一个线程对资源的重复加锁.重进入是指任意线程在获取到锁之后能够再次获取该锁而不会被锁阻塞,该特性的实现需要解决以下两个问题. 1.线程再次获取锁.锁需要去识别获取锁的线程是否为当前占据锁的线程,如果是,则再次成功获取. 2.锁的最终释放.线程重复n次获取了锁,随后在第n次释放该锁后,其他线程能够获取到该锁.锁的最终释放要求锁对于获取进行计数自增,计数表示当前锁被重复获取的次数,而锁被释放时,计数自减,当计数等于0时表示锁已经成功释放
java多线程-读写锁原理

Java5 在 java.util.concurrent 包中已经包含了读写锁.尽管如此,我们还是应该了解其实现背后的原理. 读/写锁的 Java 实现(Read / Write Lock Java Implementation) 读/写锁的重入(Read / Write Lock Reentrance) 读锁重入(Read Reentrance) 写锁重入(Write Reentrance) 读锁升级到写锁(Read to Write Reentrance) 写锁降级到读锁(Write to
Java 读写锁源码分析

前言在实际项目中,比如我们有一个共享资源文件,我们程序会会同时并发的去读.写这个共享资源文件,那怎么能保证在高并发场景下安全.高效读写呢?OK,看了下文便知提示:以下是本篇文章正文内容,案例仅供参考一.技术介绍 1.ReentranReadWriteLock是什么? ReadWriteLock提供了readLock和writeLock两种锁的操作机制,一个是读锁,一个是写锁,而它的实现类就是ReentranReadWriteLock 读锁可以在没有写锁的时候被多个线程同时持有,写锁是独占的
Java集合框架源码分析之LinkedHashMap详解

LinkedHashMap简介 LinkedHashMap是HashMap的子类,与HashMap有着同样的存储结构,但它加入了一个双向链表的头结点,将所有put到LinkedHashmap的节点一一串成了一个双向循环链表,因此它保留了节点插入的顺序,可以使节点的输出顺序与输入顺序相同. LinkedHashMap可以用来实现LRU算法(这会在下面的源码中进行分析). LinkedHashMap同样是非线程安全的,只在单线程环境下使用. LinkedHashMap源码剖析 LinkedHashM
Java struts2请求源码分析案例详解

Struts2是Struts社区和WebWork社区的共同成果,我们甚至可以说,Struts2是WebWork的升级版,他采用的正是WebWork的核心,所以,Struts2并不是一个不成熟的产品,相反,构建在WebWork基础之上的Struts2是一个运行稳定.性能优异.设计成熟的WEB框架. 我这里的struts2源码是从官网下载的一个最新的struts-2.3.15.1-src.zip,将其解压即可.里面的目录页文件非常的多,我们只需要定位到struts-2.3.15.1\src\core
Java Array.sort()源码分析讲解

阅读起点: Arrays.sort(nums1); 使用ctrl+左键进入sort()方法 1.Arrays.sort() 关于sort()的方法一共有14个,就目前调用的来看是以下这种最基础的. public static void sort(int[] a) { DualPivotQuicksort.sort(a, 0, a.length - 1, null, 0, 0); } 2.DualPivotQuicksort DualPivotQuicksort即双轴快排,定义了七种原始类型的排序
Java并发LinkedBlockingQueue源码分析

目录简介常量构造方法 put await isOnSyncQueue signal 简介 LinkedBlockingQueue是一个阻塞的有界队列,底层是通过一个个的Node节点形成的链表实现的,链表队列中的头节点是一个空的Node节点,在多线程下操作时会使用ReentrantLock锁来保证数据的安全性,并使用ReentrantLock下的Condition对象来阻塞以及唤醒线程. 常量 /** * 链表中的节点类 */ static class Node<E> { //节点中的元素
Java BufferedWriter BufferedReader 源码分析

一:BufferedWriter 1.类功能简介: BufferedWriter.缓存字符输出流.他的功能是为传入的底层字符输出流提供缓存功能.同样当使用底层字符输出流向目的地中写入字符或者字符数组时.每写入一次就要打开一次到目的地的连接.这样频繁的访问不断效率底下.也有可能会对存储介质造成一定的破坏.比如当我们向磁盘中不断的写入字节时.夸张一点.将一个非常大单位是G的字节数据写入到磁盘的指定文件中的.没写入一个字节就要打开一次到这个磁盘的通道.这个结果无疑是恐怖的.而当我们使用Buffered
Java并发结合源码分析AQS原理

前言: 如果说J.U.C包下的核心是什么?那我想答案只有一个就是AQS.那么AQS是什么呢?接下来让我们一起揭开AQS的神秘面纱 AQS是什么? AQS是AbstractQueuedSynchronizer的简称.为什么说它是核心呢?是因为它提供了一个基于FIFO的队列和state变量来构建锁和其他同步装置的基础框架.下面是其底层的数据结构. AQS的特点 1.其内使用Node实现FIFO(FirstInFirstOut)队列.可用于构建锁或者其他同步装置的基础框架 2.且利用了一个int类表示
Java并发Timer源码分析

timer在JDK里面,是很早的一个API了.具有延时的,并具有周期性的任务,在newScheduledThreadPool出来之前我们一般会用Timer和TimerTask来做,但是Timer存在一些缺陷,为什么这么说呢? Timer只创建唯一的线程来执行所有Timer任务.如果一个timer任务的执行很耗时,会导致其他TimerTask的时效准确性出问题.例如一个TimerTask每10秒执行一次,而另外一个TimerTask每40ms执行一次,重复出现的任务会在后来的任务完成后快速连续的被
java.util.Collection源码分析与深度理解

写在开头 java.util.Collection 作为Java开发最常用的接口之一,我们经常使用,今天我带大家一起研究一下Collection接口,希望对大家以后的编程以及系统设计能有所帮助,本文所研究的jdk版本为jdk1.8.0_131 明确一下几点: Collection是接口,其继承了Iterable接口 Collection属于单值类型集合,重点子接口List接口和Set接口 Java.util.List接口(有序.不唯一) ArraryList ArrayList 是一个数组队列,
Java集合系列之LinkedHashMap源码分析

这篇文章我们开始分析LinkedHashMap的源码,LinkedHashMap继承了HashMap,也就是说LinkedHashMap是在HashMap的基础上扩展而来的,因此在看LinkedHashMap源码之前,读者有必要先去了解HashMap的源码,可以查看我上一篇文章的介绍<Java集合系列[3]----HashMap源码分析>.只要深入理解了HashMap的实现原理,回过头来再去看LinkedHashMap,HashSet和LinkedHashSet的源码那都是非常简单的.因此,读