内容简介:java中锁是个很重要的概念,当然这里的前提是你会涉及并发编程。除了语言提供的锁关键字 synchronized和volatile之外,jdk还有其他多种实用的锁。不过这些锁大多都是基于AQS队列同步器。ReadWriteLock 读写锁就是其中一个。
java中锁是个很重要的概念,当然这里的前提是你会涉及并发编程。
除了语言提供的锁关键字 synchronized和volatile之外,jdk还有其他多种实用的锁。
不过这些锁大多都是基于AQS队列同步器。ReadWriteLock 读写锁就是其中一个。
读写锁的含义是,将读锁与写锁分开对待,读锁可以任意个一起读,因为读并不涉及数据变更,而遇到写锁后,所有后续的读写都将被阻塞。这特性有什么用呢?比如我们有一个缓存,我们可以用它来提高访问速度,但是当数据变更时,怎样能保证能读到准确的数据?
在没有读写锁之前,我们可以使用wait/notify机制,我们可以以写锁作为一个同步介质,当写锁被占用时,读只能等待,写操作完成后,通知所有读继续。这看起来不那么好实现!
当有了读写锁后,我们就不需要这么麻烦了,只需要读操作使用读锁,写操作获取写锁操作。大家可能会想,既然都要获取锁,那和其他锁有什么差别呢,一般看到锁咱们都会想到串行,阻塞。但其实读写锁不是这样的。看起来你是每次都获取读锁,但其实单纯的读锁并不会阻塞线程,所以同样是并行无阻,读锁只有在一种情况下会阻塞,那就是写锁被某线程占用时。因为写锁被占用则意味着,数据可能马上发生变化,如果此再允许读操作任意进行的话,多半可能读到写了一半或者是老数据,而这简直太糟了。而写锁则只每次都会真正进行后续操作的阻塞动作,使写操作保证强一致性。
好了,以上就是咱们从概念上来理解读写锁。
而实际上呢?ReadWriteLock只是一个接口,而其实现则可能是n多的。我们就以jdk实现的 ReentrantReadWriteLock 为契机,看一下读写锁的实现吧。
在介绍 ReetrantReadWriteLock 之前,我们要先简单说下 ReentrantLock 重入锁,从字面意思理解,就是可重新进入的锁。那么,到底是什么意思呢?我们想一下,如果我们有2个资源锁可用,那么,如果我在本线程上上锁两次,是不是资源就没有了呢,那第三次进行锁获取的时候,是不是就把自己给锁死了呢?想想应该是这样的,但是为啥平时咱们都遇不到这种情况呢?原因就在于可重入性。可重入的意思是说,如果当前线程进行多次加锁操作,那么无论如何它自己都是可以进入的。简单从实现来说就是,锁会排除当前线程,从而避免自身阻塞。这些需求看起来很理所当然,但是咱们自己实现的时候可能会因为场景不一样,从而不一定需要这种特性呢。syncronized也是一种重入锁。好了,说了这么多,还是没有看到 ReetrantLock是怎么实现的!
用个不恰当的图描绘下:
我们来看下源码就一目了然了。
/** * Fair version of tryAcquire */ protected final boolean tryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) { // 第一次进入获取到锁后,标记获得锁的线程,后续判定重入 setExclusiveOwnerThread(current); return true; } } // 重入锁判定,否则失败 else if (current == getExclusiveOwnerThread()) { // 最多可重入 int 次 int nextc = c + acquires; if (nextc < 0) throw new Error("Maximum lock count exceeded"); setState(nextc); return true; } return false; } }
重入锁介绍完后,咱们可以安心的来说说 ReentrantReadWriteLock了。该读写锁也是一种可重入锁。它要实现的特性就是,读读锁无阻塞,写锁必阻塞(包括写读锁/写写锁),读写锁阻塞(需等待读锁释放后才能获取写锁从而保证无脏读)。
从上面可以看出,读和写是两个锁,但是他们的状态却是互相关联的,那怎样设计其数据结构呢?用两个变量去推导往往不太可行,因为其本身就是锁,如果再用两个变量去判定锁状态,那么又如何保证变量自身的可靠性呢?ReentrantReadWriteLock 是通过一个状态变量来控制的,具体为 高16位保存读锁状态,低16位保存写锁状态,而在改变状态时,使用cas保证写入的可靠性。(其实这里可以看出,锁个数不应该超过16位即65536个,这种锁数量已经完全被忽略掉了)。有了数据结构,咱们再看下怎么控制读写互联。读锁的获取,写锁没被占用时,即低位为0时,高位大于0即可代表获取了读锁,所以,读锁是n个可用的。而写锁的获取,则要依赖高低位判定了,高位大于0,即代表还有读锁存在,不能进入,如果高位为0,也不一定可进入,低位不为0则代表有写锁在占用,所以只有高低位都为0时,写锁才可用。
下面,来看下读写锁的具体实现!
来个例子先:
public class ReadWriteLockTest { private ReentrantReadWriteLock reentrantReadWriteLock = new ReentrantReadWriteLock(); /** * 读锁 */ private Lock r = reentrantReadWriteLock.readLock(); /** * 写锁 */ private Lock w = reentrantReadWriteLock.writeLock(); /** * 执行线程池 */ private ExecutorService executorService = Executors.newCachedThreadPool(); @Test public void testReadLock() { for (int i = 0; i < 10; i++) { Thread readWorker = new ReadWorker(); executorService.submit(readWorker); } waitForExecutorFinish(); } @Test public void testWriteLock() { for (int i = 0; i < 10; i++) { Thread writeWorker = new WriteWorker(); executorService.submit(writeWorker); } waitForExecutorFinish(); } @Test public void testReadWriteLock() { for (int i = 0; i < 10; i++) { Thread readWorker = new ReadWorker(); Thread writeWorker = new WriteWorker(); executorService.submit(readWorker); executorService.submit(writeWorker); } waitForExecutorFinish(); } /** * 线程模拟完成后,关闭线程池 */ private void waitForExecutorFinish() { executorService.shutdown(); try { executorService.awaitTermination(100, TimeUnit.SECONDS); } catch (InterruptedException e) { e.printStackTrace(); } } private final class ReadWorker extends Thread { @Override public void run() { r.lock(); try { SleepUtils.second(1); System.out.println(System.currentTimeMillis() + ": " + Thread.currentThread().getName() + " reading..."); SleepUtils.second(1); } finally { r.unlock(); } } } private final class WriteWorker extends Thread { @Override public void run() { w.lock(); try { SleepUtils.second(1); System.out.println(System.currentTimeMillis() + ": " + Thread.currentThread().getName() + " writing..."); SleepUtils.second(1); } finally { w.unlock(); } } } }
可以看到 testReadLock(), 无阻塞,立即完成10个读任务!
而 testWriteLock(),则是全部阻塞执行,20秒完成串行10个任务!
而 testReadWriteLock(), 则是 读锁与写锁交替执行,在执行写锁时,所有锁等待,在执行读锁时,可能存在多个锁同时运行!执行结果样例如下:
1543816105277: pool-1-thread-1 reading... 1543816107278: pool-1-thread-2 writing... 1543816109278: pool-1-thread-20 writing... 1543816111278: pool-1-thread-16 writing... 1543816113279: pool-1-thread-12 writing... 1543816115279: pool-1-thread-8 writing... 1543816117280: pool-1-thread-19 reading... 1543816117280: pool-1-thread-15 reading... 1543816119280: pool-1-thread-4 writing... 1543816121280: pool-1-thread-18 writing... 1543816123281: pool-1-thread-3 reading... 1543816123281: pool-1-thread-7 reading... 1543816125287: pool-1-thread-14 writing... 1543816127290: pool-1-thread-6 writing... 1543816129290: pool-1-thread-10 writing... 1543816131290: pool-1-thread-11 reading... 1543816131290: pool-1-thread-13 reading... 1543816131290: pool-1-thread-9 reading... 1543816131290: pool-1-thread-5 reading... 1543816131290: pool-1-thread-17 reading...
ok, 现象已经展示了,是时候透过现象看本质了!
1. 读锁的获取过程 r.lock(), 其实现为 ReadLock!
public void lock() { // 调用 AQS 的 acquireShared() 方法,进行统一调度 sync.acquireShared(1); } // AQS 获取共享读锁 public final void acquireShared(int arg) { // 调用 ReentrantReadWriteLock.Sync.tryAcquireShared(), 定义锁获取方式 if (tryAcquireShared(arg) < 0) doAcquireShared(arg); } // 获取读锁,unused 传参未使用,直接使用内置的高位加1方式处理 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); // 读锁任意获取,除了超过最大限制 if (!readerShouldBlock() && r < MAX_COUNT && compareAndSetState(c, c + SHARED_UNIT)) { if (r == 0) { firstReader = current; firstReaderHoldCount = 1; } else if (firstReader == current) { firstReaderHoldCount++; } else { 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); } // 获取低位数,即写锁状态值 static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; } // 获取高位数,即读锁状态值 static int sharedCount(int c) { return c >>> SHARED_SHIFT; } /** * Full version of acquire for reads, that handles CAS misses * and reentrant reads not dealt with in tryAcquireShared. */ final int fullTryAcquireShared(Thread current) { /* * This code is in part redundant with that in * tryAcquireShared but is simpler overall by not * complicating tryAcquireShared with interactions between * retries and lazily reading hold counts. */ HoldCounter rh = null; for (;;) { int c = getState(); if (exclusiveCount(c) != 0) { if (getExclusiveOwnerThread() != current) return -1; // else we hold the exclusive lock; blocking here // would cause deadlock. } else if (readerShouldBlock()) { // Make sure we're not acquiring read lock reentrantly if (firstReader == current) { // assert firstReaderHoldCount > 0; } else { if (rh == null) { rh = cachedHoldCounter; if (rh == null || rh.tid != getThreadId(current)) { rh = readHolds.get(); 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更新锁状态,使用 SHARED_UNIT 进行高位加1 if (compareAndSetState(c, c + SHARED_UNIT)) { if (sharedCount(c) == 0) { firstReader = current; firstReaderHoldCount = 1; } else if (firstReader == current) { firstReaderHoldCount++; } else { 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; } } }
以上是获取读锁的过程,其实际控制很简单,只是多了很多的状态统计,所以看起来复杂!
2. 下面,来看写锁的获取过程,WriteLock.lock()
public void lock() { // AQS获取独占锁 sync.acquire(1); } // AQS 锁调度 public final void acquire(int arg) { // 如果获取锁失败,则加入到等待队列中 if (!tryAcquire(arg) && acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); } // ReentrantReadWriteLock.Sync.tryAcquire(), 写锁获取过程 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); // 如果是0,则说明不存在读写锁,直接成功 // 否则分有读锁和有写锁两种情况判断 if (c != 0) { // (Note: if c != 0 and w == 0 then shared count != 0) // 存在读锁,或者不是当前线程(重入),则直接失败 if (w == 0 || current != getExclusiveOwnerThread()) return false; if (w + exclusiveCount(acquires) > MAX_COUNT) throw new Error("Maximum lock count exceeded"); // Reentrant acquire setState(c + acquires); return true; } // cas 更新 state if (writerShouldBlock() || !compareAndSetState(c, c + acquires)) return false; setExclusiveOwnerThread(current); return true; } /** * Creates and enqueues node for current thread and given mode. * * @param mode Node.EXCLUSIVE for exclusive, Node.SHARED for shared * @return the new node */ private Node addWaiter(Node mode) { Node node = new Node(Thread.currentThread(), mode); // Try the fast path of enq; backup to full enq on failure Node pred = tail; if (pred != null) { node.prev = pred; if (compareAndSetTail(pred, node)) { pred.next = node; return node; } } enq(node); return node; } // AQS 的锁入队列操,从队列中进行锁获取,如果获取失败,则产线一个中断标志 final boolean acquireQueued(final Node node, int arg) { boolean failed = true; try { boolean interrupted = false; for (;;) { final Node p = node.predecessor(); // 这里是公平锁的实现方式,只会从队列头获取锁 if (p == head && tryAcquire(arg)) { setHead(node); p.next = null; // help GC failed = false; return interrupted; } // 阻塞判定,响应中断 if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); } }
ok, 读写锁的获取已经完成,再来看一下释放的过程!
3. 读锁的释放 ReadLock.unlock()
public void unlock() { // AQS 的释放控制 sync.releaseShared(1); } // AQS 释放锁 public final boolean releaseShared(int arg) { if (tryReleaseShared(arg)) { doReleaseShared(); return true; } return false; } // ReentrantReadWriteLock.Sync.tryReleaseShared() 自定义释放 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 (;;) { int c = getState(); int nextc = c - SHARED_UNIT; // cas更新状态,每次减1,直到为0,锁才算真正释放 if (compareAndSetState(c, nextc)) // Releasing the read lock has no effect on readers, // but it may allow waiting writers to proceed if // both read and write locks are now free. return nextc == 0; } } /** * Release action for shared mode -- signals successor and ensures * propagation. (Note: For exclusive mode, release just amounts * to calling unparkSuccessor of head if it needs signal.) */ private void doReleaseShared() { /* * Ensure that a release propagates, even if there are other * in-progress acquires/releases. This proceeds in the usual * way of trying to unparkSuccessor of head if it needs * signal. But if it does not, status is set to PROPAGATE to * ensure that upon release, propagation continues. * Additionally, we must loop in case a new node is added * while we are doing this. Also, unlike other uses of * unparkSuccessor, we need to know if CAS to reset status * fails, if so rechecking. */ 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 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. 读锁的释放, WriteLock.unlock()
public void unlock() { // AQS 释放控制 sync.release(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; } // Sync.tryRelease() protected final boolean tryRelease(int releases) { if (!isHeldExclusively()) throw new IllegalMonitorStateException(); int nextc = getState() - releases; // 如果写锁状态为0,则意味着当前线程完全释放锁,将 owner 线各设置为null boolean free = exclusiveCount(nextc) == 0; if (free) setExclusiveOwnerThread(null); setState(nextc); return free; } /** * Wakes up node's successor, if one exists. * * @param node the node */ private void unparkSuccessor(Node node) { /* * If status is negative (i.e., possibly needing signal) try * to clear in anticipation of signalling. It is OK if this * fails or if status is changed by waiting thread. */ int ws = node.waitStatus; if (ws < 0) compareAndSetWaitStatus(node, ws, 0); /* * Thread to unpark is held in successor, which is normally * just the next node. But if cancelled or apparently null, * traverse backwards from tail to find the actual * non-cancelled successor. */ Node s = node.next; if (s == null || s.waitStatus > 0) { s = null; for (Node t = tail; t != null && t != node; t = t.prev) if (t.waitStatus <= 0) s = t; } // 调用 LockSupport 释放锁 if (s != null) LockSupport.unpark(s.thread); }
综上,读写锁的简要解析就算完成了。 其主要使用 AQS 的基础组件,进行锁调度! 使用CAS进行状态的安全设置! 而锁的阻塞,则是使用 LockSupport 工具组件进行实际阻塞!
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:- Netty 源码解析:ChannelPipeline 机制与读写过程
- SpringSession系列-sessionId解析和Cookie读写策略
- Apache Iceberg 对推荐应用架构的优化及读写流程解析
- 注册中心 Eureka 源码解析 —— Eureka源码解析 —— 应用实例注册发现 (九)之岁月是把萌萌的读写锁
- 想用数据库“读写分离” 请先明白“读写分离”解决什么问题
- Java 读写锁浅析
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
并行算法的设计与分析
陈国良 / 2009-8 / 66.00元
第3版在修订版的基础上进行了大幅度的修订,新增加3章、重写3章,改写8章。《普通高等教育十一五国家级规划教材·并行算法的设计与分析(第3版)》系统深入地讨论了计算机领域中诸多计算问题的并行算法的设计和分析方法。在着重介绍各种并行计算模型上的常用和典型的并行算法的同时,也力图反映本学科的最新成就、学科前沿和发展趋势。 全书共分二十章,包括基础篇4章(绪论、设计技术、前缀计算、排序和选择网络),......一起来看看 《并行算法的设计与分析》 这本书的介绍吧!
UNIX 时间戳转换
UNIX 时间戳转换
RGB HSV 转换
RGB HSV 互转工具