Java并发5：ReentrantReadWriteLock原理

最新推荐文章于 2024-08-17 10:11:38 发布
最新推荐文章于 2024-08-17 10:11:38 发布
阅读量245 收藏
点赞数
分类专栏： Java并发
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_37935909/article/details/107894468
版权

文章目录

1、图解流程

读写锁用的是同一个 Sycn 同步器，因此等待队列、state 等也是同一个
t1 w.lock，t2 r.lock
1） t1 成功上锁，流程与 ReentrantLock 加锁相比没有特殊之处，不同是写锁状态占了 state 的低 16 位，而读锁
使用的是 state 的高 16 位
在这里插入图片描述
2）t2 执行 r.lock，这时进入读锁的 sync.acquireShared(1) 流程，首先会进入 tryAcquireShared 流程。如果有写锁占据，那么 tryAcquireShared 返回 -1 表示失败。

tryAcquireShared 返回值表示

  • -1 表示失败
  • 0 表示成功，但后继节点不会继续唤醒
  • 正数表示成功，而且数值是还有几个后继节点需要唤醒，读写锁返回 1

在这里插入图片描述
3）这时会进入 sync.doAcquireShared(1) 流程，首先也是调用 addWaiter 添加节点，不同之处在于节点被设置为Node.SHARED 模式而非 Node.EXCLUSIVE 模式，注意此时 t2 仍处于活跃状态
在这里插入图片描述
4）t2 会看看自己的节点是不是老二，如果是，还会再次调用 tryAcquireShared(1) 来尝试获取锁
5）如果没有成功，在 doAcquireShared 内 for 循环一次，把前驱节点的 waitStatus 改为 -1，再 for 循环一次尝试 tryAcquireShared(1) 如果还不成功，那么在 parkAndCheckInterrupt() 处 park
在这里插入图片描述
t3 r.lock，t4 w.lock
这种状态下，假设又有 t3 加读锁和 t4 加写锁，这期间 t1 仍然持有锁，就变成了下面的样子

在这里插入图片描述
接下来执行唤醒流程 sync.unparkSuccessor，即让老二恢复运行，这时 t2 在 doAcquireShared 内
parkAndCheckInterrupt() 处恢复运行
这回再来一次 for 执行 tryAcquireShared 成功则让读锁计数加一
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
下一个节点不是 shared 了，因此不会继续唤醒 t4 所在节点
t2 r.unlock，t3 r.unlock
t2 进入 sync.releaseShared(1) 中，调用 tryReleaseShared(1) 让计数减一，但由于计数还不为零
在这里插入图片描述
在这里插入图片描述

1、写锁上锁流程

// WriteLock
static final class NonfairSync extends Sync {
	// ... 省略无关代码
	// 外部类 WriteLock 方法, 方便阅读, 放在此处
	public void lock() {
		sync.acquire(1);
	}
	// AQS 继承过来的方法, 方便阅读, 放在此处
	public final void acquire(int arg) {
		if (
		// 尝试获得写锁失败
		!tryAcquire(arg) &&
		// 将当前线程关联到一个 Node 对象上, 模式为独占模式
		// 进入 AQS 队列阻塞
		acquireQueued(addWaiter(Node.EXCLUSIVE), arg)
		) {
			selfInterrupt();
		}
	}

// Sync 继承过来的方法, 方便阅读, 放在此处
protected final boolean tryAcquire(int acquires) {
	// 获得低 16 位, 代表写锁的 state 计数
	Thread current = Thread.currentThread();
	int c = getState();
	
	int w = exclusiveCount(c);
	if (c != 0) {
		if (
			// c != 0 and w == 0 表示有读锁, 或者
			w == 0 ||
			// 如果 exclusiveOwnerThread 不是自己
			current != getExclusiveOwnerThread()
		) {
		// 获得锁失败
		return false;
		}
		// 写锁计数超过低 16 位, 报异常
		if (w + exclusiveCount(acquires) > MAX_COUNT)
			throw new Error("Maximum lock count exceeded");
		// 写锁重入, 获得锁成功
		setState(c + acquires);
		return true;
	}
	if (
		// 判断写锁是否该阻塞, 或者
		writerShouldBlock() ||
		// 尝试更改计数失败
		!compareAndSetState(c, c + acquires)
		) {
		// 获得锁失败
		return false;
	}
		// 获得锁成功
		setExclusiveOwnerThread(current);
		return true;
	}
	// 非公平锁 writerShouldBlock 总是返回 false, 无需阻塞
	final boolean writerShouldBlock() {
		return false;
	}
}

2、写锁释放流程

static final class NonfairSync extends Sync {
	// ... 省略无关代码
	// WriteLock 方法, 方便阅读, 放在此处
	public void unlock() {
		sync.release(1);
	}
	// AQS 继承过来的方法, 方便阅读, 放在此处
	public final boolean release(int arg) {
		// 尝试释放写锁成功
		if (tryRelease(arg)) {
			// unpark AQS 中等待的线程
			Node h = head;
			if (h != null && h.waitStatus != 0)
				unparkSuccessor(h);
			return true;
		}
		return false;
	}
		// Sync 继承过来的方法, 方便阅读, 放在此处
	protected final boolean tryRelease(int releases) {
		if (!isHeldExclusively())
			throw new IllegalMonitorStateException();
		int nextc = getState() - releases;
		// 因为可重入的原因, 写锁计数为 0, 才算释放成功
		boolean free = exclusiveCount(nextc) == 0;
		if (free) {
			setExclusiveOwnerThread(null);
		}
		setState(nextc);
		return free;
	}
}

3、读锁上锁流程

static final class NonfairSync extends Sync {
	// ReadLock 方法, 方便阅读, 放在此处
	public void lock() {
		sync.acquireShared(1);
	}
	// AQS 继承过来的方法, 方便阅读, 放在此处
	public final void acquireShared(int arg) {
		// tryAcquireShared 返回负数, 表示获取读锁失败
		if (tryAcquireShared(arg) < 0) {
			doAcquireShared(arg);
		}
	}
	// Sync 继承过来的方法, 方便阅读, 放在此处
	protected final int tryAcquireShared(int unused) {
		Thread current = Thread.currentThread();
		int c = getState();
		// 如果是其它线程持有写锁, 获取读锁失败
		if (
			exclusiveCount(c) != 0 &&
			getExclusiveOwnerThread() != current
		) {
		return -1;
		}
		int r = sharedCount(c);
		if (
			// 读锁不该阻塞(如果老二是写锁，读锁该阻塞), 并且
			!readerShouldBlock() &&
			// 小于读锁计数, 并且
			r < MAX_COUNT &&
			// 尝试增加计数成功
			compareAndSetState(c, c + SHARED_UNIT)
		) {
		// ... 省略不重要的代码
			return 1;
		}
		return fullTryAcquireShared(current);
	}
	// 非公平锁 readerShouldBlock 看 AQS 队列中第一个节点是否是写锁
	// true 则该阻塞, false 则不阻塞
	final boolean readerShouldBlock() {
		return apparentlyFirstQueuedIsExclusive();
	}
	// AQS 继承过来的方法, 方便阅读, 放在此处
	// 与 tryAcquireShared 功能类似, 但会不断尝试 for (;;) 获取读锁, 执行过程中无阻塞
	final int fullTryAcquireShared(Thread current) {
		HoldCounter rh = null;
		for (;;) {
			int c = getState();
			if (exclusiveCount(c) != 0) {
				if (getExclusiveOwnerThread() != current)
					return -1;
			} else if (readerShouldBlock()) {
				// ... 省略不重要的代码
			}
			if (sharedCount(c) == MAX_COUNT)
				throw new Error("Maximum lock count exceeded");
			if (compareAndSetState(c, c + SHARED_UNIT)) {
				// ... 省略不重要的代码
				return 1;
			}
		}
	}
	// AQS 继承过来的方法, 方便阅读, 放在此处
	private void doAcquireShared(int arg) {
		// 将当前线程关联到一个 Node 对象上, 模式为共享模式
		final Node node = addWaiter(Node.SHARED);
		boolean failed = true;
		try {
			boolean interrupted = false;
			for (;;) {
				final Node p = node.predecessor();
				if (p == head) {
					// 再一次尝试获取读锁
					int r = tryAcquireShared(arg);
					// 成功
					if (r >= 0) {
						// ㈠
						// r 表示可用资源数, 在这里总是 1 允许传播
						//（唤醒 AQS 中下一个 Share 节点）
						setHeadAndPropagate(node, r);
						p.next = null; // help GC
						if (interrupted)
							selfInterrupt();
						failed = false;
						return;
					}
				}
				if (
					// 是否在获取读锁失败时阻塞（前一个阶段 waitStatus == Node.SIGNAL）
					shouldParkAfterFailedAcquire(p, node) &&
					// park 当前线程
					parkAndCheckInterrupt()
				) {
					interrupted = true;
				}
			}
		} finally {
			if (failed)
				cancelAcquire(node);
		}
}
	// ㈠ AQS 继承过来的方法, 方便阅读, 放在此处
	private void setHeadAndPropagate(Node node, int propagate) {
		Node h = head; // Record old head for check below
		// 设置自己为 head
		setHead(node);
		// propagate 表示有共享资源（例如共享读锁或信号量）
		// 原 head waitStatus == Node.SIGNAL 或 Node.PROPAGATE
		// 现在 head waitStatus == Node.SIGNAL 或 Node.PROPAGATE
		if (propagate > 0 || h == null || h.waitStatus < 0 ||
			(h = head) == null || h.waitStatus < 0) {
			Node s = node.next;
			// 如果是最后一个节点或者是等待共享读锁的节点
			if (s == null || s.isShared()) {
				// 进入 ㈡
				doReleaseShared();
			}
		}
	}
	// ㈡ AQS 继承过来的方法, 方便阅读, 放在此处
	private void doReleaseShared() {
		// 如果 head.waitStatus == Node.SIGNAL ==> 0 成功, 下一个节点 unpark
		
		// 如果 head.waitStatus == 0 ==> Node.PROPAGATE, 为了解决 bug, 见后面分析
		for (;;) {
			Node h = head;
			// 队列还有节点
			if (h != null && h != tail) {
				int ws = h.waitStatus;
				if (ws == Node.SIGNAL) {
					if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
						continue; // loop to recheck cases
					// 下一个节点 unpark 如果成功获取读锁
					// 并且下下个节点还是 shared, 继续 doReleaseShared
					unparkSuccessor(h);
				}
				else if (ws == 0 &&
					!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
					continue; // loop on failed CAS
			}
			if (h == head) // loop if head changed
				break;
			}
		}
	}

4、读锁释放流程

static final class NonfairSync extends Sync {
	// ReadLock 方法, 方便阅读, 放在此处
	public void unlock() {
		sync.releaseShared(1);
	}
	// AQS 继承过来的方法, 方便阅读, 放在此处
	public final boolean releaseShared(int arg) {
		if (tryReleaseShared(arg)) {
			doReleaseShared();
			return true;
		}
		return false;
	}
	// Sync 继承过来的方法, 方便阅读, 放在此处
	protected final boolean tryReleaseShared(int unused) {
		// ... 省略不重要的代码
		for (;;) {
			int c = getState();
			int nextc = c - SHARED_UNIT;
			if (compareAndSetState(c, nextc)) {
			// 读锁的计数不会影响其它获取读锁线程, 但会影响其它获取写锁线程
			// 计数为 0 才是真正释放
				return nextc == 0;
			}
		}
	}
	// AQS 继承过来的方法, 方便阅读, 放在此处
	private void doReleaseShared() {
		// 如果 head.waitStatus == Node.SIGNAL ==> 0 成功, 下一个节点 unpark
		// 如果 head.waitStatus == 0 ==> Node.PROPAGATE
		for (;;) {
			Node h = head;
			if (h != null && h != tail) {
				int ws = h.waitStatus;
				// 如果有其它线程也在释放读锁，那么需要将 waitStatus 先改为 0
				// 防止 unparkSuccessor 被多次执行
				if (ws == Node.SIGNAL) {
					if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
						continue; // loop to recheck cases
					unparkSuccessor(h);
				}
				// 如果已经是 0 了，改为 -3，用来解决传播性，见后文信号量 bug 分析
				else if (ws == 0 &&
					!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
					continue; // loop on failed CAS
			}
			if (h == head) // loop if head changed
				break;
			}
		}
	}
Yisnow.
关注
专栏目录
源码解读 | Java中ReentrantReadWriteLock的实现原理
字节幺零二四的博客
08-09 679
本文将介绍Java中ReentrantReadWriteLock的实现原理，从JDK源码层面讲解读写锁的加锁、释放锁的流程。
Java并发编程：锁
rrq_0324的博客
12-02 960
1.1 Lock Lock接口的实现基本都是通过聚合了一个队列同步器AQS的子类来完成线程访问控制的。 package java.util.concurrent.locks; import java.util.concurrent.TimeUnit; public interface Lock { //调用该方法的当前线程将会获取锁 void lock(); //可中断的获取锁，即在锁的获取中可以中断当前线程 void lockInterruptibly() throws Inte
可重入读写锁ReentrantReadWriteLock基本原理分析
wuyangyang555的博客
07-10 233
原文链接：https://www.jianshu.com/p/9f98299a17a5前言本篇适用于了解ReentrantLock或ReentrantReadWriteLock的使用，但想要进一步了解原理的读者。见于之前的分析都是借鉴大量的JDK源码，这次以流程图的形式代替源码，希望读者能有更好的阅读体验。有兴趣了解源码的读者也可以借鉴本篇的分析成果做源码分析。在《从源码分析ReentrantLo...
Java并发编程 - 读写锁ReadWriteLock详解
最新发布
qq_33240556的博客
08-17 596
读写锁是一种非常有效的同步机制，尤其适用于读取操作远多于写入操作的场景。通过允许多个读取者同时访问共享资源，可以显著提高并发性能。提供了丰富的功能，包括升级和降级锁的能力，使得它成为一个强大且灵活的工具。在实际应用中，合理选择锁的类型和管理锁的使用可以大大提高程序的性能和可维护性。
Java并发编程-ReentrantReadWriteLock
weixin_30765319的博客
09-12 109
　　基于AQS的前世今生，来学习并发工具类ReentrantReadWriteLock。本文将从ReentrantReadWriteLock的产生背景、源码原理解析和应用来学习这个并发工具类。 1、 产生背景 　　前面我们学习的重入锁ReentrantLock本质上还是互斥锁，每次最多只能有一个线程持有ReentrantLock。对于维护数据完整性来说，互斥通常是一种过于强硬的规则，因此也就不...
Java并发编程--ReentrantReadWriteLock
GarfieldEr007的专栏
01-05 680
概述 　　ReentrantReadWriteLock是Lock的另一种实现方式，我们已经知道了ReentrantLock是一个排他锁，同一时间只允许一个线程访问，而ReentrantReadWriteLock允许多个读线程同时访问，但不允许写线程和读线程、写线程和写线程同时访问。相对于排他锁，提高了并发性。在实际应用中，大部分情况下对共享数据（如缓存）的访问都是读操作远多于写操作，这时Reen...
【Java并发编程实战】—–“J.U.C”：ReentrantReadWriteLock
chenssy 的技术博客
10-31 4198
ReentrantLock实现了标准的互斥操作，也就是说在某一时刻只有有一个线程持有锁。ReentrantLock采用这种独占的保守锁直接，在一定程度上减低了吞吐量。在这种情况下任何的“读/读”、“读/写”、“写/写”操作都不能同时发生。然而在实际的场景中我们就会遇到这种情况：有些资源并发的访问中，它大部分时间都是执行读操作，写操作比较少，但是读操作并不影响数据的一致性，如果在进行读操作时采用独占
Java并发编程：ReentrantReadWriteLock深度解析
在Java并发编程中，ReentrantReadWriteLock（可重入读写锁）是一个重要的工具，用于控制对共享资源的访问。它是Java并发包（java.util.concurrent.locks）的一部分，提供比synchronized更细粒度的锁控制，允许多个...
Java多线程 ReentrantReadWriteLock原理及实例详解
08-25
Java的ReentrantReadWriteLock是Java并发包`java.util.concurrent.locks`中的一个重要工具，它提供了一种更细粒度的锁定机制，相比普通的独占锁（如ReentrantLock）在某些场景下能显著提高程序的并发性能。...
Java ReentrantReadWriteLock详解：原理与应用
"Java的ReentrantReadWriteLock是Java并发编程中的一个重要工具，它提供了一种在多线程环境下更高效的数据访问方式。ReentrantReadWriteLock实现了读写锁机制，允许多个读线程并发访问，而写线程具有独占性。本文将...
Java并发编程：深入理解ReadWriteLock读写锁
【资源摘要信息】: "本文深入探讨了Java并发编程中的ReadWriteLock使用，特别是JUC（Java Concurrency in Practice）包中的ReadLock和WriteLock。文章提供了详细的解释和示例代码，帮助读者理解如何利用读写锁实现...
说说ReentrantReadWriteLock
pwlazy的专栏
06-01 9459
<br />1） 背景<br />     jni的使用场景，多线程读，单线程写，写的时候会更新java对象，当老的java对象无须再使用的时候必须释放jni所占用本地方法区的内存，这个区域的内存不在java heap范畴，因此也无法被垃圾回收掉，需要显式的释放。<br /><br /> 但问题在于什么释放？<br /><br /> 有人会说使用finalize,但finalize过于依赖jvm的回收的时机，这使得什么时候能真正释放显得不太好预测。<br /><br /> 或者使用synchroni
ReentrantReadWriteLock实现原理
WannaRunning的博客
01-21 184
之前写了synchronized和基于AQS实现的ReentrantLock，这篇文章写一下与ReentrantLock类似的ReentrantReadWriteLock。 ReentrantReadWriteLock 和ReentrantLock一样都在java.util.concurrent包下，通常我们使用ReentrantReadWriteLock的两个内部类ReadLock和WriteLock即读锁和写锁来实现更细粒度的同步功能，读写锁的实现也是基于AQS和CAS实现的，分别用的就是AQS的共
读写锁ReentrantReadWriteLock原理
张大安的博客
03-19 585
文章目录1.ReentrantReadWriteLock使用2.ReentrantReadWriteLock原理2.1 图解流程2.2 源码分析3.StampedLock 1.ReentrantReadWriteLock使用 当读操作远远高于写操作时，这时候使用 读写锁让 读-读可以并行，提高性能。读-写，写-写操作都是相互互斥的！ 代码举例 提供一个 数据容器类内部分别使用读锁保护数据的read()方法，写锁保护数据的 write()方法 /** * @ClassName TestReadWriteLo
ReentrantReadWriteLock原理详解
m0_53127809的博客
12-02 3297
当读操作远远高于写操作时,这时候使用读写锁让读——读可以并发,提高性能。 类似于数据库中的select.,from..lockinsharemode 提供一个数据容器类内部分别使用读锁保护数据的read()方法,写锁保护数据的write()方法 简单来说，就是读锁可以共享，但是写锁必须独占 一、ReentrantReadWriteLock JUC为我们提供了一个可用于读和写的读写锁。 简单看下使用方法： ReentrantReadWriteLo...
ReentrantReadWriteLock原理与使用
秃头的博客
01-08 1116
一、读写锁 有这样一种场景： 1、如果对一个共享资源的写操作没有读操作那么频繁，这个时候可以允许多个线程同时读取共享资源； 2、但是如果有一个线程想去写这些共享资源，那么其他线程此刻就不应该对这些资源进行读和写操作了。 Java中的ReentrantReadWriteLock正是为这种场景提供的锁。该类里面包括了读锁和写锁。 1.1、可获取读锁的情况 没有其他线程正在持有写锁； 尝试获取读锁的线程同时持有写锁。 1.2、可获取写锁的情况 没有其他线程正在持有读锁； 没有其他线程正在持有写锁。 1
快进来！花几分钟看一下 ReentrantReadWriteLock 的原理！
程序员小航
07-28 428
快进来！花几分钟看一下 ReentrantReadWriteLock 的原理！ 前言 在看完 ReentrantLock 之后，在高并发场景下 ReentrantLock 已经足够使用，但是因为 ReentrantLock 是独占锁，同时只有一个线程可以获取该锁，而很多应用场景都是读多写少，这时候使用 ReentrantLock 就不太合适了。读多写少的场景该如何使用？在 JUC 包下同样提供了读写锁 ReentrantReadWriteLock 来应对读多写少的场景。 公众号：liuzhihangs
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值