ReentrantLock之AQS原理与源码详解

原文链接:https://segmentfault.com/a/1190000017351736

ReentrantLock和AQS的关系


ReentrantLock使用

图片描述

AbstractQueuedSynchronizer,抽象队列同步器;给大家画一个图先,看一下ReentrantLock和AQS之间的关系。
图片描述

AbstractQueuedSynchronizer为ReentrantLock的静态内部类
图片描述

lock()源码分析

图片描述

2、默认为非公平锁
图片描述

3、最终会调用AbstractQueuedSynchronizer子类NonfairSync.lock()方法;
图片描述
lock()方法做了什么事呢?
首先需要知道AQS会维护两个变量state(初始值0)、exclusiveOwnerThread(初始值null),源码如下,记录线程状态与当前加锁线程
图片描述

图片描述

线程1跑过来调用ReentrantLock的lock()方法尝试进行加锁,这个加锁的过程,直接就是用CAS操作将state值从0变为1。
如果之前没人加过锁,那么state的值肯定是0,此时线程1就可以加锁成功。
一旦线程1加锁成功了之后,就可以设置当前加锁线程是自己。所以大家看下面的图,就是线程1跑过来加锁的一个过程。
图片描述

可重入锁

state记录加锁次数,为0时释放锁

锁的互斥是如何实现的?

线程2跑过来一下看到,哎呀!state的值不是0啊?所以CAS操作将state从0变为1的过程会失败,因为state的值当前为1,说明已经有人加锁了!
接着线程2会看一下,是不是自己之前加的锁啊?当然不是了,“加锁线程”这个变量明确记录了是线程1占用了这个锁,所以线程2此时就是加锁失败。
接着,线程2会将自己放入AQS中的一个等待队列,因为自己尝试加锁失败了,此时就要将自己放入队列中来等待,等待线程1释放锁之后,自己就可以重新尝试加锁了
所以大家可以看到,AQS是如此的核心!AQS内部还有一个等待队列,专门放那些加锁失败的线程!
同样,给大家来一张图,一起感受一下:
图片描述
源码
线程2进来加锁失败后,会进入等待队列;等待队列为链表
图片描述
图片描述
图片描述
接着,线程1在执行完自己的业务逻辑代码之后,就会释放锁!他释放锁的过程非常的简单,就是将AQS内的state变量的值递减1,如果state值为0,则彻底释放锁,会将“加锁线程”变量也设置为null!
整个过程,参见下图:
图片描述

释放锁源码:

LockSupport.unpark(s.thread);
图片描述
图片描述
接下来,会从等待队列的队头唤醒线程2重新尝试加锁。
好!线程2现在就重新尝试加锁,这时还是用CAS操作将state从0变为1,此时就会成功,成功之后代表加锁成功,就会将state设置为1。
此外,还要把“加锁线程”设置为线程2自己,同时线程2自己就从等待队列中出队了。
最后再来一张图,大家来看看这个过程。
图片描述

Node存储等待线程队列

图片描述

参考资料https://juejin.im/post/5c07e5...

展开阅读全文

没有更多推荐了,返回首页