Overview of ReadWriteLock
As we said before, ReentrantLock is an exclusive lock. Only one thread can acquire the lock at a time. In fact, there will be many scenarios where read more and less write , and the read operation itself will not have data competition problems. If you use an exclusive lock , May cause one of the reader threads to wait for other reader threads, reducing performance.
In response to this scenario where read more and write less, read-write locks came into being. The read-write lock allows multiple reader threads to access at the same time, but when the writer thread accesses, all reader threads and other writer threads are blocked. Let's take a look at the top-level interface of read-write locks in Java, which is located in: java.util.concurrent.locks package:
public interface ReadWriteLock {
// 读锁
Lock readLock();
// 写锁
Lock writeLock();
}I believe you will understand at once that the read-write lock actually maintains a pair of locks, one write lock and one read lock. Through the read-write separation strategy, multiple threads are allowed to acquire read locks at the same time, which greatly improves concurrency.
Read-write lock case
The JavaDoc document is very detailed and gives us an example of using ReentrantReadWriteLock. Let's take a look directly:
class CachedData {
Object data;
volatile boolean cacheValid;
// 创建读写锁实例
final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
void processCachedData() {
// 获取读锁
rwl.readLock().lock();
// 缓存失效的情况
if (!cacheValid) {
// 释放掉读锁，必须！在获取写锁之前给读锁释放了
rwl.readLock().unlock();
// 获取写锁
rwl.writeLock().lock();
try {
// 重新检查状态，因为在等待写锁的过程中，可能前面有其他写线程执行过了
if (!cacheValid) {
data = ...
cacheValid = true;
}
// 持有写锁的情况下，获取读锁的，称为 “锁降级”
rwl.readLock().lock();
} finally {
// 释放写锁，此时还剩一个读锁
rwl.writeLock().unlock();
}
}
try {
use(data);
} finally {
// 释放读锁
rwl.readLock().unlock();
}
}
}Summarize a little, in detail in the following analysis part:
ReentrantReadWriteLock read-write locks are divided into read locks and write locks. Read locks are shared locks and write locks are exclusive locks. The thread holding the write lock can continue to acquire the read lock, which is called lock degradation.
Overview of ReentrantReadWriteLock architecture
ReentrantReadWriteLock is the implementation of ReadWriteLock. In fact, seeing the name: reentrant read-write lock, we can probably guess its meaning. In addition to implementing the readLock() and writeLock() methods, it also provides some important methods, which we will analyze later.
public class ReentrantReadWriteLock
implements ReadWriteLock, java.io.Serializable {
private static final long serialVersionUID = -6992448646407690164L;
/** 内部维护ReadLock */
private final ReentrantReadWriteLock.ReadLock readerLock;
/** 内部维护WriteL */
private final ReentrantReadWriteLock.WriteLock writerLock;
/** 读、写锁公用一个AQS的Sync的实例 */
final Sync sync;
/** 默认使用非公平模式 */
public ReentrantReadWriteLock() {
this(false);
}
/** 初始化读锁和写锁实例 */
public ReentrantReadWriteLock(boolean fair) {
sync = fair ? new FairSync() : new NonfairSync();
readerLock = new ReadLock(this);
writerLock = new WriteLock(this);
}
public ReentrantReadWriteLock.WriteLock writeLock() { return writerLock; }
public ReentrantReadWriteLock.ReadLock readLock() { return readerLock; }
/**
* AQS的实现
*/
abstract static class Sync extends AbstractQueuedSynchronizer {
// ...
}
/**
* Sync 非公平版本的实现
*/
static final class NonfairSync extends Sync {
private static final long serialVersionUID = -8159625535654395037L;
final boolean writerShouldBlock() {
return false; // writers can always barge
}
final boolean readerShouldBlock() {
return apparentlyFirstQueuedIsExclusive();
}
}
/**
* Sync 公平版本的实现
*/
static final class FairSync extends Sync {
private static final long serialVersionUID = -2274990926593161451L;
final boolean writerShouldBlock() {
return hasQueuedPredecessors();
}
final boolean readerShouldBlock() {
return hasQueuedPredecessors();
}
}
/**
* 可以通过ReentrantReadWriteLock#readLock方法得到一个读锁实例
*/
public static class ReadLock implements Lock, java.io.Serializable {
private static final long serialVersionUID = -5992448646407690164L;
private final Sync sync;
protected ReadLock(ReentrantReadWriteLock lock) {
sync = lock.sync;
}
// 可以看到读锁使用的是共享模式
public void lock() {
sync.acquireShared(1);
}
public void unlock() {
sync.releaseShared(1);
}
//...省略tryLock、lockInterruptibly等方法
}
/**
* 可以通过ReentrantReadWriteLock#writeLock方法获得一个写锁实例
*/
public static class WriteLock implements Lock, java.io.Serializable {
private static final long serialVersionUID = -4992448646407690164L;
private final Sync sync;
protected WriteLock(ReentrantReadWriteLock lock) {
sync = lock.sync;
}
// 可以看到读锁使用的是独占模式
public void lock() {
sync.acquire(1);
}
public void unlock() {
sync.release(1);
}
//...省略tryLock、lockInterruptibly等方法
}
Let’s summarize:
- ReentrantReadWriteLock maintains two internal classes, ReadLock and WriteLock, both of which entrust Sync to implement specific functions [Sync is the implementation of AQS, which I said before is very clear].
- Like ReentrantLock, it also provides two implementations of fairness and unfairness: FairSync and NonfairSync. They are the implementation classes of Sync. For the two differences, see: Differences between fair and unfair strategies
- ReadLock and WriteLock instances can be obtained through two methods: readLock() and writeLock().
- ReadLock uses shared mode and WriteLock uses exclusive mode. For the difference between the two, see: Java Concurrent Package Source Learning Series: The difference between AQS shared and exclusive acquisition and release of resources.
Sync important fields and internal class representation
As we mentioned when learning AQS, the key of AQS is the synchronization state field state. For example, taking ReentrantLock as an example, its state is 0 to indicate that the lock is free, 1 to indicate that the lock is acquired, and greater than 1 to indicate that the lock is being used by the same thread. Re-entry.
However, it is known that the read-write lock needs to maintain two states. How to represent it with only one integer variable state? The read-write lock uses the idea of bit-wise cutting to cleverly divide the state into two parts:
- High 16 bits: indicates the read status, representing the number of read lock acquisitions [including the number of reentrants]. Due to the sharing mode, multiple threads can acquire the lock and reentrant.
- The 16th bit: Represents the write status, representing the number of reentrant write locks. In exclusive mode, only one thread can obtain the write lock, but it can represent the number of reentrants.
Note the difference between the two.
/*
* Read vs write count extraction constants and functions.
* Lock state is logically divided into two unsigned shorts:
* The lower one representing the exclusive (writer) lock hold count,
* and the upper the shared (reader) hold count.
*/
static final int SHARED_SHIFT = 16;
// 共享锁状态单位值 65536
static final int SHARED_UNIT = (1 << SHARED_SHIFT);
// 共享锁线程最大个数 65535
static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1;
// 排他锁掩码 65535 二进制表示 15个1
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
/** 返回读锁的获取次数【包括重入次数】 无符号补0右移16位，其实就是获取高16位 */
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
/** 返回写锁可重入次数 将高16位抹去，其实就是获取低16位 */
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }
- sharedCount: unsigned complement 0 and shift right by 16 bits, in fact, it is to get the high 16 bits.
- exclusiveCount: Erasing the high 16 bits is actually getting the low 16 bits.
// 记录每个线程持有的读锁数量
static final class HoldCounter {
// 持有的读锁数
int count = 0;
// Use id, not reference, to avoid garbage retention
// 线程id
final long tid = getThreadId(Thread.currentThread());
}
/**
* ThreadLocal subclass. Easiest to explicitly define for sake
* of deserialization mechanics.
* ThreadLocal的子类
*/
static final class ThreadLocalHoldCounter
extends ThreadLocal<HoldCounter> {
// 每个线程都需要记录获取读锁的次数，判断是否重入
public HoldCounter initialValue() {
return new HoldCounter();
}
}
// ThreadLocalHoldCounter继承ThreadLocal
// 存放除去第一个获取读锁线程外的其他线程获取读锁的可重入次数
private transient ThreadLocalHoldCounter readHolds;
// 记录最后一个获取读锁的线程获取读锁的可重入次数
private transient HoldCounter cachedHoldCounter;
// 记录第一个获取到读锁的线程
private transient Thread firstReader = null;
// 记录第一个获取到读锁的线程获取读锁的可重入次数
private transient int firstReaderHoldCount;
Sync() {
// 初始化readHolds
readHolds = new ThreadLocalHoldCounter();
// 保证readHolds的内存可见性
setState(getState()); // ensures visibility of readHolds
}Acquisition of write lock
The write lock in ReentrantReadWriteLock is implemented by WriteLock.
void lock()
The write lock is an exclusive lock, and only one thread can acquire the lock at a time.
- If no thread currently acquires the read lock and write lock, the current thread can acquire the write lock and return.
- If the current thread has acquired the read lock and write lock, the thread currently requesting the write lock will be blocked and suspended.
The write lock is a reentrant lock. If the current thread has already acquired the lock, acquiring it again simply returns the number of reentrant times +1.
// ReentrantReadWriteLock.WriteLock#lock
public static class WriteLock implements Lock, java.io.Serializable {
private final Sync sync;
public void lock() {
sync.acquire(1);
}
}
// AQS # acquire
public final void acquire(int arg) {
// 调用子类实现的tryAcquire，如果位false，则加入阻塞队列，阻塞
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
// ReentrantReadWriteLock.Sync#tryAcquire
abstract static class Sync extends AbstractQueuedSynchronizer {
protected final boolean tryAcquire(int acquires) {
/*
* Walkthrough:
* 1. If read count nonzero or write count nonzero
* and owner is a different thread, fail.
* 2. If count would saturate, fail. (This can only
* happen if count is already nonzero.)
* 3. 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.
*/
Thread current = Thread.currentThread();
int c = getState();
int w = exclusiveCount(c);
// c != 0表示读锁或者写锁已经被某个线程获取了
if (c != 0) {
// c != 0 && w == 0表示有线程获取了读锁，share count此时不为0。
// c != 0 && w != 0并且当前线程不是写锁拥有者，返回false
// 意思是只要有读锁或写锁被占用，这次获取写锁就会失败
if (w == 0 || current != getExclusiveOwnerThread())
return false;
//走到这里说明当前线程就是已经获取写锁的，判断可重入的次数是否超过了最大值
if (w + exclusiveCount(acquires) > MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// 设置可重入的次数，不需要CAS，因为走到这里必然是写锁重入
setState(c + acquires);
return true;
}
// 走到这，表示 c==0，此时为第一个线程尝试获取写锁。
// 如果写锁不需要block，进行cas操作，成功则表示获取成功
if (writerShouldBlock() ||
!compareAndSetState(c, c + acquires))
return false;
// 经过前面的步骤之后，到这一步，才设置锁的持有者为当前线程
setExclusiveOwnerThread(current);
return true;
}
}
boolean writerShouldBlock()
The writerShouldBlock method is implemented, there is a difference between fairness and unfairness:
static final class FairSync extends Sync {
private static final long serialVersionUID = -2274990926593161451L;
final boolean writerShouldBlock() {
// 返回是否存在前驱节点，会先看看前面有没有在排队的
return hasQueuedPredecessors();
}
}
static final class NonfairSync extends Sync {
private static final long serialVersionUID = -8159625535654395037L;
// 总是返回false，直接去cas
final boolean writerShouldBlock() {
return false; // writers can always barge
}
}Obviously, for unfair locks, this method will always return false, which means that it will and will go directly to the compareAndSetState(c, c + acquires) step, try to acquire the write lock through CAS, and set the state after the acquisition is successful. The current thread will be set as the lock holder, and false will be returned on failure.
It means: In unfair mode, it will directly try cas to grab the write lock, and then queue up if it can't be grabbed; for fair mode, if the current thread has a precursor node in the blocking queue, it will give up the process of CAS competing for the write lock. .
void lockInterruptibly()
Similar to the lockInterruptibly() method of ReentrantLock, when other threads call the interrupt() method of the thread to interrupt the current thread, the current thread will throw an InterruptedException.
public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
//AQS
public final void acquireInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
if (!tryAcquire(arg))
doAcquireInterruptibly(arg);
}
boolean tryLock()
Try to acquire a write lock. If no other thread currently holds a write lock or a read lock, the current thread will successfully acquire the write lock and return true.
If there are currently other threads holding a write lock or a read lock, this method directly returns false, and the current thread will not be blocked.
If the current thread already holds the write lock, simply increase the state value of AQS and return true directly.
public boolean tryLock( ) {
return sync.tryWriteLock();
}
// AQS
final boolean tryWriteLock() {
Thread current = Thread.currentThread();
int c = getState();
if (c != 0) {
int w = exclusiveCount(c);
if (w == 0 || current != getExclusiveOwnerThread())
return false;
if (w == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
}
if (!compareAndSetState(c, c + 1))
return false;
setExclusiveOwnerThread(current);
return true;
}In fact, the logic of the lock method is not much different, but the unfair lock logic of the lock method is adopted.
boolean tryLock(long timeout,TimeUnit unit)
Similar to the tryLock(long timeout, TimeUnit unit) method of ReentrantLock.
Try to acquire the write lock. If the acquisition fails, the current thread will be suspended for a specified time. After the time is up, the current thread will be activated. If the lock is still not acquired, false will be returned.
In addition, this method will respond to interrupts. If other threads call the interrupt() method of the current thread, respond to the interrupt and throw an exception.
Write lock release
void unlock()
Try to release the lock. If the current thread holds the lock, calling this method will decrement the AQS state held by the thread by 1; if the current state value is 0 after decrementing 1, the current thread will release the lock.
If the current thread does not hold the lock and calls this method, an IllegalMonitorStateException is thrown.
public void lock() {
sync.acquireShared(1);
}
// 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;
}
// ReentrantReadWriteLock.Sync#tryAcquire
abstract static class Sync extends AbstractQueuedSynchronizer {
protected final boolean tryRelease(int releases) {
// 当前线程没有持有该锁而调用了该方法
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
int nextc = getState() - releases;
// 判断一下是不是需要释放锁了
boolean free = exclusiveCount(nextc) == 0;
// 清空一下
if (free)
setExclusiveOwnerThread(null);
// state没有到0，仅仅是设置state而已
setState(nextc);
// 如果写锁全部释放，返回true，上面的方法就会唤醒之后的节点
return free;
}
}
Acquisition of read lock
The read lock in ReentrantReadWriteLock is implemented by ReadLock. ps: The acquisition and release of read locks is more complicated than write locks.
void lock()
// ReentrantReadWriteLock.ReadLock#lock
public static class ReadLock implements Lock, java.io.Serializable {
private final Sync sync;
public void lock() {
sync.acquireShared(1);
}
}
// AQS # acquireShared
public final void acquireShared(int arg) {
// 调用子类实现的tryAcquireShared，如果为false，则加入阻塞队列，阻塞
if (tryAcquireShared(arg) < 0)
doAcquireShared(arg);
}
// ReentrantReadWriteLock.Sync#tryAcquire
abstract static class Sync extends AbstractQueuedSynchronizer {
protected final int tryAcquireShared(int unused) {
/*
* Walkthrough:
* 1. If write lock held by another thread, fail.
* 2. Otherwise, this thread is eligible for
* lock wrt state, so ask if it should block
* because of queue policy. If not, try
* to grant by CASing state and updating count.
* Note that step does not check for reentrant
* acquires, which is postponed to full version
* to avoid having to check hold count in
* the more typical non-reentrant case.
* 3. If step 2 fails either because thread
* apparently not eligible or CAS fails or count
* saturated, chain to version with full retry loop.
*/
Thread current = Thread.currentThread();
// 获取当前状态值
int c = getState();
if (exclusiveCount(c) != 0 && // 说明有线程持有写锁
getExclusiveOwnerThread() != current) // 并且不是当前线程持有写锁
return -1; // 失败
//----- 这里提一嘴，上面如果持有写锁的是自己，就还是可以获取读锁的 -----//
// 获取读锁计数
int r = sharedCount(c);
// 读锁获取是否需要阻塞，若不成功将会进入fullTryAcquireShared进行重试
if (!readerShouldBlock() &&
r < MAX_COUNT && // 判断读锁获取次数是否溢出
// 尝试将高16位+1，低16位不变，如果获取成功则表示获取到了读锁
compareAndSetState(c, c + SHARED_UNIT)) {
// ----- 能走到这里表示当前线程获取读锁成功 ----- //
// r==0表示第一个线程获取读锁 ，也有可能之前有线程但被释放了，当前自然就是第一个啦
if (r == 0) {
firstReader = current; // 记录一下firstReader【每次将读锁获取次数从0变成1】
firstReaderHoldCount = 1; // 记录一下持有的读锁数量 1
// 来到这里 c != 0 且 firstReader == current ，表示firstReader可重入了
} else if (firstReader == current) {
firstReaderHoldCount++; // 直接计数加1
} else {
// cachedHoldCounter 使用来缓存最后一个获取读锁的线程的，之后用rh表示
HoldCounter rh = cachedHoldCounter;
// 如果rh还没缓存 或者 存的不是当前线程
if (rh == null || rh.tid != getThreadId(current))
// 那就更新一下cachedHoldCounter 为当前线程的HoldCounter
cachedHoldCounter = rh = readHolds.get();
// 走到这里，说明缓存的是当前线程，但是count是0
else if (rh.count == 0)
readHolds.set(rh);
// count 加1
rh.count++;
}
return 1; // 大于0表示获取到了共享锁
}
// 类似tryAcquireShared，自旋获取，这里失败的话，就得进阻塞队列去了嗷
return fullTryAcquireShared(current);
}
}
boolean readerShouldBlock()
The readerShouldBlock method is implemented, there is a difference between fairness and unfairness:
static final class FairSync extends Sync {
final boolean readerShouldBlock() {
// 看看阻塞队列中是否已经有其他元素在排队
return hasQueuedPredecessors();
}
}
static final class NonfairSync extends Sync {
final boolean readerShouldBlock() {
/* As a heuristic to avoid indefinite writer starvation,
* block if the thread that momentarily appears to be head
* of queue, if one exists, is a waiting writer. This is
* only a probabilistic effect since a new reader will not
* block if there is a waiting writer behind other enabled
* readers that have not yet drained from the queue.
*/
// 判断阻塞队列中 第一个节点是否是来获取写锁的，如果是的话，让这个写锁先来。
return apparentlyFirstQueuedIsExclusive();
}
}Specifically look at the implementation of unfair locks, apparentlyFirstQueuedIsExclusive method:
final boolean apparentlyFirstQueuedIsExclusive() {
Node h, s;
return (h = head) != null && // 队列是否为空
(s = h.next) != null && // 是否存在第一个元素
!s.isShared() && // 第一个元素是否正在尝试获取写锁
s.thread != null; // 该元素的线程是否为null
}Link up and explain:
- !readerShouldBlock(): If there is an element in the queue, determine whether the first element is trying to acquire a write lock. If it is, let this element come first, and its priority is high.
- r <MAX_COUNT: Determine whether the thread currently acquiring the read lock reaches the maximum value.
- compareAndSetState(c, c + SHARED_UNIT): Perform CAS operation to increase the high 16-bit value of the AQS state value by 1 .
In fact: see if the first node in the queue is trying to acquire the write lock , if so, let him come first. If you are acquiring a read lock, I'm sorry, go to CAS obediently and see who can get it.
What happens if the read lock is not acquired? Enter the fullTryAcquireShared logic to see:
int fullTryAcquireShared(Thread)
/**
* Full version of acquire for reads, that handles CAS misses
* and reentrant reads not dealt with in tryAcquireShared.
*/
final int fullTryAcquireShared(Thread current) {
/*
* 这段代码和tryAcquireShared部分冗余，但总体更加简单
*/
HoldCounter rh = null;
// 自旋
for (;;) {
int c = getState();
// 已经有线程获取了写锁
if (exclusiveCount(c) != 0) {
// 且获取写锁的线程不是当前线程，那就直接进队，如果是当前线程，走到cas去，锁降级的过程
if (getExclusiveOwnerThread() != current)
return -1;
} else if (readerShouldBlock()) {
// 走到这一步，表示写锁没被占有，且阻塞队列中有其他线程在等待
// firstReader线程重入读锁，直接快进到下面的cas
if (firstReader == current) {
// assert firstReaderHoldCount > 0;
} else {
if (rh == null) {
rh = cachedHoldCounter;
// cachedHoldCounter 没有缓存或缓存的不是当前线程
if (rh == null || rh.tid != getThreadId(current)) {
// 如果当前线程从来没有初始化ThreadLocal中的值，get方法会进行初始化
rh = readHolds.get();
// 表示上一行代码是初始化的，执行remove
if (rh.count == 0)
readHolds.remove();
}
}
// 排队
if (rh.count == 0)
return -1;
}
}
if (sharedCount(c) == MAX_COUNT)
throw new Error("Maximum lock count exceeded");
// cas操作成功，表示获取读锁了，接下来设置firstReader或firstReaderHoldCount
if (compareAndSetState(c, c + SHARED_UNIT)) {
if (sharedCount(c) == 0) {
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) {
firstReaderHoldCount++;
} else {
// 将cachedHoldCounter设置为当前线程
if (rh == null)
rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
cachedHoldCounter = rh; // cache for release
}
return 1;
}
}
}The next few methods of reading locks and writing locks are actually not much different, the source code will not be posted, and interested friends can see for themselves.
void lockInterruptibly()
Similar to the lock() method, the difference is that this method can interrupt the response. When other threads call the interrupt() method of the thread to interrupt the current thread, the current thread throws an InterruptedException.
boolean tryLock()
Try to read the lock. If no other thread currently holds the write lock, the current thread will acquire the read lock successfully and return true.
If there are other threads currently holding the write lock, it will return false without blocking.
If the current thread already holds the read lock, use AQS to increase the high 16 bits of state by 1, and return true.
boolean tryLock(long timeout,TimeUnit unit)
Similar to tryLock, the difference is that the timeout period is set, and the timeout period is up. If the read lock is not read, false is directly returned.
The response can be interrupted. When other threads call the interrupt() method of this thread to interrupt the current thread, the current thread throws InterruptedException.
Read lock release
void unlock()
public void unlock() {
sync.releaseShared(1);
}
// AQS
public final boolean releaseShared(int arg) {
// 如果tryReleaseShared返回true，释放一个由于获取写锁而被阻塞的线程
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}
abstract static class Sync extends AbstractQueuedSynchronizer {
protected final boolean tryReleaseShared(int unused) {
Thread current = Thread.currentThread();
if (firstReader == current) {
// 如果firstReaderHoldCount为1，这次解锁之后，就会变成0了，将firstReader设置为null
if (firstReaderHoldCount == 1)
firstReader = null;
else
// 否则减1就可以
firstReaderHoldCount--;
} else {
// 判断cacheHoldCounter是否缓存的是当前线程，如果不是的话，需要从ThreadLocal中取。
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
rh = readHolds.get();
int count = rh.count;
if (count <= 1) {
// 不再持有锁了，调用remove，防止内存泄露
readHolds.remove();
if (count <= 0)
throw unmatchedUnlockException();
}
--rh.count;
}
// 无限循环，保证CAS操作成功
for (;;) {
// 获取状态值
int c = getState();
int nextc = c - SHARED_UNIT;
// CAS 操作更新状态值。CAS操作如果不成功，会一直循环
if (compareAndSetState(c, nextc))
// 如果更新成功，查看当前状态值是否为0，如果为0说明已经没有读线程占用读锁
// 如果不为0，则说明还有其他线程持有读锁，返回false
return nextc == 0;
}
}
}
Understanding of lock degradation
Lock downgrading means that a write lock can be downgraded to a read lock , but the sequence of acquiring the write lock, acquiring the read lock and then releasing the write lock must be followed . Note that if the current thread first acquires the write lock, then releases the write lock, and then acquires the read lock, this process cannot be called lock degradation. Lock degradation must follow that order.
Note that the author Doug Lea did not say that write locks are more advanced. If a thread holds a read lock, then write lock acquisition also needs to wait, but it can be seen in the source code that write locks are given special care, such as in unfair mode In order to improve throughput, if it is found that the first node is the thread that acquires the write lock, it is directly acquired.
The part of the lock downgrade is reflected in the source code:
int c = getState();
// 已经有线程获取了写锁
if (exclusiveCount(c) != 0) {
// 且获取写锁的线程不是当前线程，那就直接进队，如果是当前线程，走到cas去，锁降级的过程
if (getExclusiveOwnerThread() != current)
return -1;Is it necessary to acquire a read lock during lock degradation?
If the current thread A does not acquire the read lock but directly releases the write lock, at this time another thread B acquires the write lock, then the data modification of this thread B will not be visible to the current thread A. If a read lock is acquired, thread B judges that if there is a read lock that has not been released during the process of acquiring a write lock, it will be blocked. Only after the current thread A releases the read lock, thread B will successfully acquire the write lock.
to sum up
- The bottom layer of ReentrantReadWriteLock is implemented using AQS. The upper 16 bits of the AQS status value indicate the number of read locks acquired, and the lower 16 bits identify the number of reentrant threads that have acquired the write lock. The CAS is operated on to achieve read-write separation. , It is suitable for scenarios where read more and write less.
- Three features of ReentrantReadWriteLock: Fairness: Supports both fair and unfair modes. Re-entrancy: Supports re-entry, read-write locks support up to 65535. Lock downgrade: Acquire the write lock first, then acquire the read lock, and then release the write lock, the write lock can be downgraded to a read lock.
- Read-write lock: The read-write lock allows multiple reader threads to access at the same time, but when the write thread accesses, all reader threads and other write threads are blocked.
Original link: https://www.cnblogs.com/summerday152/p/14284646.html
If you think this article is helpful to you, you can follow my official account and reply to the keyword [Interview] to get a compilation of Java core knowledge points and an interview gift package! There are more technical dry goods articles and related materials to share, let everyone learn and progress together!
