细节爆炸!并发编程的半壁江山——AQS详解( 四 )
能看到这里的证明你真的很爱这个行业,你是最棒的!加油
回顾Lock的实现ReentrantLock其实在上面手写的锁,是有一些缺陷的,因为判断的是不是等于1,所以他是一个不支持可重入的,一旦重入,就会造成死锁,自己锁住自己,但是ReentrantLock就不会
他支持锁的可重入,并且支持锁的公平和非公平
文章插图
通过源码可以看到,他是通过状态的累加完成的锁的可重入,当然前提是已经拿到锁的线程,会有这样一个判断
文章插图
所以可想而知,释放的时候,每次释放就递减,最终等于0的时候完成锁的释放
文章插图
在实现公平锁的时候,就是判断当前节点是否有前期节点,是不是第一个,如果有,不是第一个,抱歉你不能抢锁
文章插图
可想而知在非公平锁中就是不判断而已
因为不需要判断,并且是谁抢到锁,锁就是谁的,所以说非公平锁比公平锁效率高
ReentrantReadWriteLock在读写锁中,一个状态如何 保存两个状态呢?采用位数分割
文章插图
应该有知道 int是32位的,他把32位一分为二,采用低位保存写的状态,高位保存读的状态
写锁,应该都知道,只能同时被一个线程持有,所以重入的话,也比较好保存
但是读锁不一样,可以被多个线程同时持有,是共享锁,并且重入的次数是不一样的,那么该怎么保存呢?采用高位置保存被多少线程持有
文章插图
采用每个持有锁的线程中的一个HoldCounter对象保存,使用ThreadLocalHoldCounter继承ThreadLocal来保存线程变量,区别不同线程
读写锁的升级和降级读写锁支持写锁降级为读锁,但是不支持读锁升级为写锁,为了保证线程安全和数据可见性,因为在写锁执行期间,读锁是被阻塞的,所以说写锁降级为读锁是没有问题的,但是如果是读锁升级为写锁,在其他线程使用完写锁的时候,读锁是看不见的,为了保证线程安全,所以不支持读锁升级成写锁
到此AQS就写完了,因为AQS涉及的知识太多,能看到现在的也都是大神了,恭喜你们,掌握了并发编程的半壁江山,为了自己的梦想更近了一步,加油,因为知识点多,所以大家多看几遍,不理解的可以百度,也可以评论区提问
原文链接:
如果觉得本文对你有帮助 , 可以转发关注支持一下
- 高像素|加持高像素只为解析力?vivo S7丛林秘境展对样张细节的要求更严苛
- 用心|用心网友制作了一加9 Pro渲染图:细节程度堪比官方
- 选对|为何都说这次OriginOS的方向选对了?来看下这些细节就知道了
- Store|苹果将在韩国开设第二家Apple Store直营店 并发布纪念壁
- 刘作虎|一加9系列更多细节曝光,刘作虎也玩起了“三机齐发”
- Linux(服务器编程):百万并发服务器系统参数调优
- 参数|外行看参数内行看细节,新手能牢记这四点,你也算半个内行了
- 并发容器ConcurrentHashMap
- 华为Mate40系列细节曝光,90Hz高刷+红外测温
- 为什么 Redis 单线程能支撑高并发?