聊聊高并发(二十九)解析java.util.concurrent各个组件(十一) 再看看ReentrantReadWriteLock可重入读-写锁
来源:互联网 发布:阿里云 服务器地址 编辑:程序博客网 时间:2024/04/29 20:15
上一篇聊聊高并发(二十八)解析java.util.concurrent各个组件(十) 理解ReentrantReadWriteLock可重入读-写锁 讲了可重入读写锁的基本情况和主要的方法,显示了如何实现的锁降级。但是下面几个问题没说清楚,这篇补充一下
1. 释放锁时的优先级问题,是让写锁先获得还是先让读锁先获得
2. 是否允许读线程插队
3. 是否允许写线程插队,因为读写锁一般用在大量读,少量写的情况,如果写线程没有优先级,那么可能造成写线程的饥饿
关于释放锁后是让写锁先获得还是让读锁先获得,这里有两种情况
1. 释放锁后,请求获取写锁的线程不在AQS队列
2. 释放锁后,请求获取写锁的线程已经AQS队列
如果是第一种情况,那么非公平锁的实现下,获取写锁的线程直接尝试竞争锁也不用管AQS里面先来的线程。获取读锁的线程只判断是否已经有线程获得写锁(既Head节点是独占模式的节点),如果没有,那么就不用管AQS里面先来的准备获取读锁的线程。
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(); } }
在公平锁的情况下,获取读锁和写锁的线程都判断是否已经或先来的线程再等待了,如果有,就进入AQS队列等待。
static final class FairSync extends Sync { private static final long serialVersionUID = -2274990926593161451L; final boolean writerShouldBlock() { return hasQueuedPredecessors(); } final boolean readerShouldBlock() { return hasQueuedPredecessors(); } }
对于第二种情况,如果准备获取写锁的线程在AQS队列里面等待,那么实际是遵循先来先服务的公平性的,因为AQS的队列是FIFO的队列。所以获取锁的线程的顺序是跟它在AQS同步队列里的位置有关系。
下面这张图模拟了AQS队列中等待的线程节点的情况
1. Head节点始终是当前获得了锁的线程
2. 非Head节点在竞争锁失败后,acquire方法会不断地轮询,于自旋不同的是,AQS轮询过程中的线程是阻塞等待。
所以要理解AQS的release释放动作并不是让后续节点直接获取锁,而是唤醒后续节点unparkSuccessor()。真正获取锁的地方还是在acquire方法,被release唤醒的线程继续轮询状态,如果它的前驱是head,并且tryAcquire获取资源成功了,那么它就获得锁
public final boolean release(int arg) { if (tryRelease(arg)) { Node h = head; if (h != null && h.waitStatus != 0) unparkSuccessor(h); return true; } return false; }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); } }
3. 图中Head之后有3个准备获取读锁的线程,最后是1个准备获取写锁的线程。
那么如果是AQS队列中的节点获取锁
情况是第一个读锁节点先获得锁,它获取锁的时候就会尝试释放共享模式下的一个读锁,如果释放成功了,下一个读锁节点就也会被unparkSuccessor唤醒,然后也会获得锁。如果释放失败了,那就把它的状态标记了PROPAGATE,当它释放的时候,会再次取尝试唤醒下一个读锁节点
如果后继节点是写锁,那么就不唤醒
private void doAcquireShared(int arg) { 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) { setHeadAndPropagate(node, r); p.next = null; // help GC if (interrupted) selfInterrupt(); failed = false; return; } } if (shouldParkAfterFailedAcquire(p, node) && parkAndCheckInterrupt()) interrupted = true; } } finally { if (failed) cancelAcquire(node); } } private void setHeadAndPropagate(Node node, int propagate) { Node h = head; // Record old head for check below setHead(node); if (propagate > 0 || h == null || h.waitStatus < 0) { Node s = node.next; if (s == null || s.isShared()) doReleaseShared(); } }private void doReleaseShared() { 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; } }
AQS的FIFO队列保证了在大量读锁和少量写锁的情况下,写锁也不会饥饿。
关于读锁能不能插队的问题,非公平性的Sync提供了插队的可能,但是前提是它在tryAcquire就成功获得了,如果tryAcquire失败了,它就得进入AQS队列排队,也不会出现让写锁饥饿的情况。
关于写锁能不能插队的情况,也是和读锁一样,非公平的Sync提供了插队的可能,如果tryAcquire获取失败,就得进入AQS等待。
最后说说为什么Semaphore和ReentrantLock在tryAcquireXX方法就实现了非公平性和公平性,而ReentrantReadWriteLock却要抽象出readerShouldBlock和writerShouldBlock的方法来单独处理公平性。
abstract boolean readerShouldBlock();abstract boolean writerShouldBlock();
原因是Semaphore只支持共享模式,所以它只需要在NonfairSync和FairSync里面实现tryAcquireShared方法就能实现公平性和非公平性。
ReentrantLock只支持独占模式,所以它只需要在NonfairSync和FairSync里面实现tryAcquire方法就能实现公平性和非公平性。
而ReentrantReadWriteLock即要支持共享和独占模式,又要支持公平性和非公平性,所以它在基类的Sync里面用tryAcquire和tryAcquireShared方法来区分独占和共享模式,
在NonfairSync和FairSync的readerShouldBlock和writerShouldBlock里面实现非公平性和公平性。
- 聊聊高并发(二十九)解析java.util.concurrent各个组件(十一) 再看看ReentrantReadWriteLock可重入读-写锁
- 聊聊高并发(二十八)解析java.util.concurrent各个组件(十) 理解ReentrantReadWriteLock可重入读-写锁
- 聊聊高并发(二十一)解析java.util.concurrent各个组件(三) 深入理解AQS(一)
- 聊聊高并发(二十五)解析java.util.concurrent各个组件(七) 理解Semaphore
- 聊聊高并发(二十二)解析java.util.concurrent各个组件(四) 深入理解AQS(二)
- 聊聊高并发(二十)解析java.util.concurrent各个组件(二) 12个原子变量相关类
- 聊聊高并发(二十三)解析java.util.concurrent各个组件(五) 深入理解AQS(三)
- 聊聊高并发(二十四)解析java.util.concurrent各个组件(六) 深入理解AQS(四)
- 聊聊高并发(二十六)解析java.util.concurrent各个组件(八) 理解CountDownLatch闭锁
- 聊聊高并发(二十七)解析java.util.concurrent各个组件(九) 理解ReentrantLock可重入锁
- 聊聊高并发(四十四)解析java.util.concurrent各个组件(二十) Executors工厂类
- 聊聊高并发(三十)解析java.util.concurrent各个组件(十二) 理解CyclicBarrier栅栏
- 聊聊高并发(四十)解析java.util.concurrent各个组件(十六) ThreadPoolExecutor源码分析
- 聊聊高并发(四十三)解析java.util.concurrent各个组件(十九) 任务的定时执行和周期执行
- 聊聊高并发(十七)解析java.util.concurrent各个组件(一) 了解sun.misc.Unsafe类
- 聊聊高并发(三十一)解析java.util.concurrent各个组件(十三) 理解Exchanger交换器
- 聊聊高并发(三十八)解析java.util.concurrent各个组件(十四) 理解Executor接口的设计
- 聊聊高并发(三十九)解析java.util.concurrent各个组件(十五) 理解ExecutorService接口的设计
- Why would an app crash with _objc_msgSend_uncached
- 北风网“双十一”史上最低价,一律全场五折
- Troubleshooting 'enq: TX - index contention' Waits in a RAC Environment. (文档 ID 873243.1)
- Lucene表达式
- codeforce 277div2
- 聊聊高并发(二十九)解析java.util.concurrent各个组件(十一) 再看看ReentrantReadWriteLock可重入读-写锁
- maven插件安装和配置(具体步骤)
- LeetCode总结 -- 树的构造篇
- WebKit源代码里的RefCounted
- 黄金数据查询演示示例
- struct和typedef struct,在C和C++中的区别
- 通过UEFI引导安装win8.1
- 动态链接库和静态链接库的区别
- ubuntu 将Android放在host目录下,无法使用git命令的问题