想了解更多JUC的知识——JUC并发编程合集
17. ReadWriteLock
1. 概述
-
ReadWriteLock也是一个接口，提供了readLock和writeLock两种锁的操作机制
-
读写锁与排他锁(独占锁)不同的是，读写锁在同一时刻可以允许多个读线程方法，但是在写线程访问时，所有的读线程和其它写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写锁，使得并发性相比一般的排它锁有了很大的提升
- 读锁：readLock是
共享锁 - **写锁：**writeLock是
独占锁 - 读写互斥，读读共享，写写互斥。
- 读锁：readLock是
-
好处：读写分离锁可以有效地帮助减少锁竞争, 提升系统性能。
2. 读写锁的使用
-
使用范式：
Lock readLock = readWriteLock.readLock(); readLock.lock(); try { // TODO } finally { readLock.unlock(); } Lock writeLock = readWriteLock.writeLock(); writeLock.lock(); try { // TODO } finally { writeLock.unlock(); }当使用ReadWriteLock 的时候，并不是直接使用，而是获得其内部的读锁和写锁，然后分别调用lock/unlock。
-
ReadWriteLock接口有一个唯一的实现类：ReentrantReadWriteLock
-
案例
public class ReadWriteLockTest { public static void main(String[] args) { MyCache myCache = new MyCache(); for (int i = 1; i < 10; i++) { final int temp = i; new Thread(() -> { myCache.read(String.valueOf(temp)); }, String.valueOf(i)).start(); } for (int i = 1; i < 10; i++) { final int temp = i; new Thread(() -> { myCache.write(String.valueOf(temp), String.valueOf(temp)); }, String.valueOf(i)).start(); } } } class MyCache { private volatile Map<String, Object> map = new HashMap<>(); private ReadWriteLock lock = new ReentrantReadWriteLock(); //读方法，从map中读取数据 public void read(String key) { lock.readLock().lock(); try { System.out.println(Thread.currentThread().getName() + "线程开始读取"); map.get(key); System.out.println(Thread.currentThread().getName() + "线程读取完毕"); } catch (Exception e) { e.printStackTrace(); } finally { lock.readLock().unlock(); } } //写方法，把数据写入map中 public void write(String key, String value) { lock.writeLock().lock(); try { System.out.println(Thread.currentThread().getName() + "线程开始写入"); map.put(key, value); System.out.println(Thread.currentThread().getName() + "线程写入完毕"); } catch (Exception e) { e.printStackTrace(); } finally { lock.writeLock().unlock(); } } }
3. 写锁的获取与释放
3.1 获取锁
-
写锁是一个
支持重入的排它锁。如果当前线程已经获取了写锁，则增加写状态。如果当前线程在获取写锁时，读锁或者写锁已被其他线程获取，则当前线程进入等待状态，代码如所示：// 读锁实现类 public static class WriteLock implements Lock, java.io.Serializable { private final Sync sync; protected WriteLock(ReentrantReadWriteLock lock) { sync = lock.sync; } public void lock() { sync.acquire(1); //获取写锁 } } // Sync 实现的 AbstractQueuedSynchronizer 中获取独占锁的方法 protected final boolean tryAcquire(int acquires) { Thread current = Thread.currentThread(); int c = getState(); // 获取当前同步状态 int w = exclusiveCount(c); // 获取写锁重入数量 if (c != 0) { // 如果当前同步状态不为 0，表示锁（读锁或写锁）已被占用 // 如果 w == 0 说明存在读锁，直接返回，为了保证写对读可见，当前写线程必须阻塞。 // 如果 w != 0 说明存在写锁，判断当前线程不是已获取写锁的线程，获取锁失败，当前线程被阻塞 if (w == 0 || current != getExclusiveOwnerThread()) return false; if (w + exclusiveCount(acquires) > MAX_COUNT) // 如果低 16位满了表示超过了获取锁数量的最大值抛出异常 throw new Error("Maximum lock count exceeded"); // Reentrant acquire setState(c + acquires); return true; } if (writerShouldBlock() || // 此方法是判断前面是否存在等待的写线程 !compareAndSetState(c, c + acquires)) return false; setExclusiveOwnerThread(current); //如果抢锁成功，把持有锁的线程更新为当前线程 return true; }分析：
-
if(c！=0) and w == 0，说明当前一定是读线程拿着锁，写锁一定拿不到，返回false。
-
if(c！=0) and w != 0，说明当前一定是写线程拿着锁，执行current!=getExclusiveOwnerThread()判断拿着写锁的线程是不是自己，发现ownerThread不是自己，返回false。
-
c！=0，w！=0，且current=getExclusiveOwnerThread()，才会走到if(w+exclusiveCount(acquires）> MAX_COUNT)。判断重入次数，重入次数超过最大值，抛出异常。因为是用state的低16位保存写锁重入次数的，所以MAX_COUNT是216。如果超出这个值，会写到读锁的高16位上。为了避免这种情形，这里做了一个检测。当然，一般不可能重入这么多次。
-
if(c==0)，说明当前既没有读线程，也没有写线程持有该锁。可以通过CAS操作抢锁。
- 公平实现和非公平实现几乎一模一样，只是 writerShouldBlock() 分别被FairSync 和NonfairSync实现，公平锁会判断是否有在等待的写锁，而非公平锁则会直接抢锁。
-
3.2 释放锁
-
写锁的释放与 Reentrant 的释放过程基本类似，每次释放均减少写状态，当写状态为0时表示写锁已被释放，从而等待的读写线程能够继续访问读写锁，同时前次写线程的修改对后续的读线程可见。代码如下所示：
protected final boolean tryRelease(int releases) { if (!isHeldExclusively()) //如果当前线程没有获取锁则抛出异常 throw new IllegalMonitorStateException(); int nextc = getState() - releases; // 是当前写状态减1. boolean free = exclusiveCount(nextc) == 0; if (free) setExclusiveOwnerThread(null); setState(nextc); // 因为写锁为排它锁，不会存在其他线程占有写锁或读锁，所有不用使用 CAS操作 return free; }
4 读锁的获取与释放
- 读锁是一个
支持重入的共享锁，它能够被多个线程同时获取，在没有其他写线程访问时，读锁总会被成功的获取，而所做的只是增加读状态。如果当前线程已经获取了读锁，则增加读状态。如果当前线程在获取读锁时，写锁已被其他线程获取，则进入阻塞等待状态。读状态是所有线程获取读锁的总和，而每个线程各自获取读锁的次数保存在ThreadLocal中，由线程自身维护。
4.1 获取锁
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)) {
if (r == 0) { // 如果读锁未被获取过，则更新第一个读线程为当前线程
firstReader = current;
firstReaderHoldCount = 1;
} else if (firstReader == current) { // 如果第一个读线程为当前线程则数量加1
firstReaderHoldCount++;
} else {
// 获取读锁的线程重入的次数是保存在 ThreadLocal 中的有线程本身保存
// 着自己获取锁的次数
HoldCounter rh = cachedHoldCounter;
if (rh == null || rh.tid != getThreadId(current))
cachedHoldCounter = rh = readHolds.get();
else if (rh.count == 0)
readHolds.set(rh);
rh.count++;
}
return 1;
}
return fullTryAcquireShared(current); // 如果上面拿锁失败，则进行自旋不停的拿锁
}
4.2 释放锁
-
因为读锁是共享锁，所以在释放读锁时是通过
CAS + 自旋的方式不停的更改锁状态直到更新成功。如下所示：protected final boolean tryReleaseShared(int unused) { Thread current = Thread.currentThread(); if (firstReader == current) { // assert firstReaderHoldCount > 0; if (firstReaderHoldCount == 1) firstReader = null; else firstReaderHoldCount--; } else { HoldCounter rh = cachedHoldCounter; if (rh == null || rh.tid != getThreadId(current)) rh = readHolds.get(); int count = rh.count; if (count <= 1) { readHolds.remove(); if (count <= 0) throw unmatchedUnlockException(); } --rh.count; } for (;;) { // 通过自旋 + CAS 的方式更新读锁状态 int c = getState(); int nextc = c - SHARED_UNIT; if (compareAndSetState(c, nextc)) return nextc == 0; } }
5 锁降级
-
锁降级是指写锁可以降级为读锁。如果当前线程拥有写锁，在不释放写锁的情况下是可以再获取读锁的，完后在释放(先前获取)的写锁，再释放读锁。ReentrantReadWriteLock 是支持锁降级，但不支持锁升级。
-
在耗时长的事务中，锁降级的优势：
- 使写锁占用时间缩短.
- 线程并发的程度增高
- 并且保证了事务不被打断。
781
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
