在java中,常常使用synchronized实现并发访问,但是ReentrantLock是基于AQS实现的,AQS仅仅是一个工具类,没有使用更底层的机器指令,不是关键字,也不依靠 JDK 编译时的特殊处理,仅仅作为一个普通的类就完成了代码块的并发访问控制。
在介绍AQS之前,先讲讲CLH锁,引用网上的定义,CLH锁是一种基于链表的可扩展、高性能、公平的自旋锁,申请线程只在本地变量上自旋,它不断轮询前驱的状态,如果发现前驱释放了锁就结束自旋获取锁。
简化一下便于理解,CLH是一个链表,链表中的每个元素都是一个线程,每个线程只监听前置节点的状态。
AQS基于CLH的队列实现了两种锁,独占所和共享锁,分别对应四个方法:
以ReentrantLock为例,ReentrantLock是基于AQS实现的可重入锁,的使用方法为:
reentrantLock.lock()
//do something
reentrantLock.unlock()
do something期间,同一时刻只有一个线程的 lock 方法会返回。其余线程会被挂起,直到获取锁。从这里可以看出,其实 ReentrantLock实现的就是一个独占锁的功能:有且只有一个线程获取到锁,其余线程全部挂起,直到该拥有锁的线程释放锁,被挂起的线程被唤醒重新开始竞争锁。这就是基于AQS的独占锁。
再看ReentrantLock的公平锁、非公平锁。
这里我们可以想一下ReentrantLock是如何获取锁,在AQS中,有那么一个volatile 修饰的标志位叫做state,用来表示有没有线程拿走了锁,或者说,锁还存不存在。当线程去获取锁时,会通过cas直接修改标志位state的值,如果state当前值为0,且成功修改,则表示该线程获取到锁。等待链表中的后继节点在不断自旋,当前置节点的线程释放锁时,会结束自旋,获取锁。
从ReentrantLock实现,可以看到AQS独占功能的内部实现,思路其实是使用的标志位+队列的方式,记录锁、竞争、释放等一系列独占的状态。回头再看ReentrantLock的实现思想:
公平锁:使用FIFO的方式进行线程队列的调度。
非公平锁:在进入线程队列之前,先抢占锁。
可重入锁:对标志位state反复累加。
所有的功能都是对AQS的标志位和队列灵活的运用,实现自己的功能。基于这个认识,我们再来看共享锁。
以CountDownLatch为例,先回顾一下CountDownLatch的使用场景,有某些情况下,我们需要在一个时刻,所有线程同时运行,因此CountDownLatch的状态位state有初始值,触发一次次递减,当state=0时,所有线程同时触发。
这一点和ReentrantLock作对比,在ReentrantLock的等待队列中,head释放锁的状态只会被后续节点获取,并获取锁。Head后续节点之后的线程并不能感知到state状态。但是CountDownLatch是如何实现让队列中所有线程被唤醒呢。
重复上述步骤,将共享状态向后传播,直到所有线程被唤醒。
所以从中我们可以看到CountDownLatch也是对AQS中标志位和队列使用的变形。
首先,AQS其实只有两个工具,一个是标志位,一个是队列,它并没有定义“什么是锁”,对于 AQS 来说它只是实现了一系列的用于判断资源是否可以访问的API,并且封装了在访问资源受限时将请求访问的线程的加入队列、挂起、唤醒等操作, AQS 只关心“资源不可以访问时,怎么处理”。“资源是可以被同时访问,还是在同一时间只能被一个线程访问”等一系列围绕资源访问的问题,而至于资源何时被访问,则交给 AQS 的子类去实现。
当 AQS 的子类是实现独占功能时,例如 ReentrantLock,“资源是否可以被访问”被定义为只要 AQS 的state 变量不为 0,并且持有锁的线程不是当前线程,则代表资源不能访问。ReentrantLock一次只唤醒一个线程
当 AQS 的子类是实现共享功能时,例如:CountDownLatch,“资源是否可以被访问”被定义为只要 AQS的 state 变量不为 0,说明资源不能访问。CountDownLatch一次唤醒多个线程。
这是典型的将规则和操作分开的设计思路:规则子类定义,操作逻辑因为具有公用性,放在父类中去封装。
这种设计提炼已经到返璞归真的程度,仅仅使用一个变量和一个队列就解决了并发访问的线程,从这个角度出发,取理解其他基于AQS的上层并发类,应该也就不会难了。