ICode9

精准搜索请尝试: 精确搜索
首页 > 编程语言> 文章详细

Java并发(十一),java基础类型和包装类型

2021-12-28 12:31:17  阅读:162  来源: 互联网

标签:Java 16 写锁 读写 获取 读锁 线程 类型 java


    • tryRelease

概述


ReentrantLock和Mutex都是一个排他锁,也就是说,同一时刻只有一个线程可以去获取这把锁

但读写锁并不完全是排他锁,同一时刻是允许多个读线程来进行访问的,读写锁实际上指的是一对锁,读锁和写锁

读锁可以被共享,但只要写锁被获取了,那么读锁和写锁都将被阻塞。

读写锁不仅可以保证写操作对读操作的可见性外,还可以简化读写交互场景,比如对于一个缓存的结构来说,缓存一般是以读服务为主,读写锁可以保证,写操作对于后续的读操作是可见的(因为写的时候不允许读,只要写完才可以读)

读写锁是在Java5之后才拥有的,在没有读写锁之前,Java采用的是等待通知机制来实现上面的操作的,即写操作对于后续的读操作是可见的,具体是当写操作开始的时候,所有晚于该写操作的读操作均会进入等待状态,只有等写操作完成并进行通知之后,所有正在等待的读操作才能继续进行,而对于写操作而言,写操作之间是使用Synchronized来进行同步的,保证了只能写操作之间是互斥的,使得读操作可以读取到正确得数据,不会出现脏读

读写锁其实也就是针对上面的场景得出的,因为使用Synchronized为重量级锁,效率会比较慢,最重要的是采用等待通知机制去让读操作进入等待状态会比较麻烦,改用读写锁去实现的话,只需要在读操作时获取读锁,写操作时获取写锁即可,当写锁被获取到时,后续的读写操作都会被阻塞,等写锁释放了之后,后续所有的读写操作才能继续进行

ReentrantReadWriteLock


特性

  • ReentrantReadWriteLock支持非公平和公平的获取锁方式,吞吐量依然是非公平优于公平,并且默认的方式是非公平

  • ReentrantReadWriteLock支持可重入,当读线程获取了读锁之后,其能继续去获得读锁;当写线程获得了写锁之后,其能继续去获得写锁,也能去获得读锁(写线程能自己读,但其他线程不能读,也不能写)

  • 支持锁降级,当获取了写锁、再获取读锁,之后释放了写锁之后,会自动降级为读锁

使用方法

在这里插入图片描述

使用的方法也比较简单,对于读写锁都是

  • 创建一个ReentrantReadWriteLock

  • 利用ReentrantReadWriteLock来获取读锁或者写锁

  • 调用读锁或者写锁的lock方法进行上锁

  • 调用读锁或者写锁的unlock方法进行解锁

读写锁的实现分析

之前学习ReentrantLock的时候认识了同步状态这个概念,同步状态就是指锁被一个线程重复获取的次数,在ReentrantLock就是state这个变量

但对于读写锁来说,不仅需要维护同步状态,还需要去维护多个读线程和一个写线程的状态(写线程只可能有一个,一旦出现写线程,其余读线程全部停止)

同步状态

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

是一个整形变量,而一个整形变量上去维护多种状态,就需要按位切割使用这个变量,而去维护这个变量是关键所在,总的来说就是怎样使用一个变量来区分读写锁的状态,为什么不使用多个变量去记录两种锁的同步状态呢?

读写锁对于该整形变量进行了按位切割使用,高16位表示读而低16位表示写

在这里插入图片描述

如何使用位拆分去表示两种锁的重入状态呢?

对于写锁的低16位,只要采用与运算,与0x0000FFFF进行与运算,就可以把高16位给去掉了,然后对于重入次数只要正常加减即可

对于读锁的高16位,不能像写锁一样简单地使用与运算就可以算出,因为简单的与运算只能保留高16位,但重入的次数不能通过简单的加减来得到了,不过其实也差不多,采用的是无符号右移16位的做法,因为是一个正数,所以只要无符号右移16位就可以将高16位移去低16位,并且高16位会变成全为0,然后重入的时候再进行同样的加减即可

如何判断读锁和写锁获取

当低16位不为0的时候,即代表读锁被获取,当高16位不为0的时候,即代表写锁去获取,但去判断写锁的时候,要先去移位才可以判断

写锁


写锁的使用如下

public void test(){

ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock();

ReentrantReadWriteLock.WriteLock writeLock = reentrantReadWriteLock.writeLock();

writeLock.lock();

writeLock.unlock();

}

从构造方法上看

在这里插入图片描述

可以看到,其调用的是另外一个构造方法,并且fair变量设为false,这也证明了前面提到的,默认的读写锁实现是一个非公平锁

public ReentrantReadWriteLock(boolean fair) {

sync = fair ? new FairSync() : new NonfairSync();

readerLock = new ReadLock(this);

writerLock = new WriteLock(this);

}

在这里插入图片描述

在这里插入图片描述

可以看到

  • 公平锁的实现由sync成员变量来决定

  • 构造方法直接实例化了ReadLock和WriteLock

  • 并且,读写锁的获取其实就是直接返回构造实例化的ReadLock和WriteLock

  • 并且,ReentrantReadWriteLock里面的内部类有5哥

  • ReadLock:读锁

  • WriteLock:写锁

  • Sync:抽象的读写锁的同步功能实现(线程安全的功能主要由Sync来保证)

  • FariSync:公平的同步功能

  • UnFairSync:不公平的同步功能

  • 并且Sync是否公平,取决于构造方法,默认是不公平的

写锁的获取

lock方法

写锁的获取是直接调用WriteLock的lock方法

在这里插入图片描述

从代码上可以看到,写锁的获取直接依赖于Sync同步类来实现

在这里插入图片描述

再深入,发现其底层实现就是AQS,可以看到很多锁的底层实现都是AQS,下面就来看看这段代码是干什么的

public final void acquire(int arg) {

//尝试去获取锁

//如果获取锁失败就去进行入队等待

if (!tryAcquire(arg) &&

acquireQueued(addWaiter(Node.EXCLUSIVE), arg))

//如果获取锁失败,并且入队成功

//将自己设为中断状态???

selfInterrupt();

}

tryAcquire

这个方法就是去获取锁,可以看到进来

其由ReentrantReadWriteLock去实现的

protected final boolean tryAcquire(int acquires) {

/*

  • Walkthrough:

    1. If read count nonzero or write count nonzero
  • and owner is a different thread, fail.

    1. If count would saturate, fail. (This can only
  • happen if count is already nonzero.)

    1. Otherwise, this thread is eligible for lock if
  • it is either a reentrant acquire or

  • queue policy allows it. If so, update state

  • and set owner.

*/

//从注释上我们可以看到三种情况

//1.如果有人获取了读锁或者有人获取了写锁,那就获取锁失败

//2.如果计数达到饱和也会停止,也就是可重入次数达到上线了

//3.其余状态都可以进行获取锁了

//获取当前线程

Thread current = Thread.currentThread();

//获取state变量,也就是获取同步状态

int c = getState();

//计算wrieteLock的同步状态

int w = exclusiveCount©;

//如果state不为0,代表有其他线程获取读锁或者写锁

if (c != 0) {

// (Note: if c != 0 and w == 0 then shared count != 0)

//如果w为0.代表有人获取了读锁,return false

//如果w不为0,但当前线程并不是已经获取了写锁的线程,return false

//以上两种情况都不能获取锁了,因为读锁有人获取了,或者没人获取读锁,但写锁的拥有者不是自己

if (w == 0 || current != getExclusiveOwnerThread())

return false;

//如果w不为0,且写锁的拥有者是自己,那就代表发生重入锁了

//改变writeLock的同步状态

if (w + exclusiveCount(acquires) > MAX_COUNT)

//如果超过了最大值

//最大值为16左移一位并且减一(刚好6位)

//抛出异常

throw new Error(“Maximum lock count exceeded”);

// Reentrant acquire

//重新设置同步状态

setState(c + acquires);

//返回true代表加锁成功

return true;

}

//如果状态栏为0

//判断写线程是否需要阻塞

//如果不需要阻塞,使用CAS来重新设置同步状态

if (writerShouldBlock() ||

标签:Java,16,写锁,读写,获取,读锁,线程,类型,java
来源: https://blog.csdn.net/m0_64867152/article/details/122190368

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有