本文主要是介绍深入理解AQS独占锁之ReentrantLock源码分析,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
传送门:JUC并发工具类的应用场景详解
上一章我们讲解了ReentrantLock、Semaphore、CountDownLatch、CyclicBarrier等同步工具类的应用场景及实现,本章我们重点讲解ReentrantLock源码分析。
目录
管程 — Java同步的设计思想
MESA模型
AQS原理分析
什么是AQS
AQS核心结构
AQS定义两种队列
ReentrantLock源码分析
源码阅读过程中要关注的问题
结合源码分析流程图理解ReentrantLock的实现
管程 — Java同步的设计思想
管程:指的是管理共享变量以及对共享变量的操作过程,让他们支持并发。
互斥:同一时刻只允许一个线程访问共享资源;
同步:线程之间如何通信、协作。
MESA模型
在管程的发展史上,先后出现过三种不同的管程模型,分别是Hasen模型、Hoare模型和MESA模型。现在正在广泛使用的是MESA模型。
管程中引入了条件变量的概念,而且每个条件变量都对应有一个等待队列。条件变量和等待队列的作用是解决线程之间的同步问题。
Java中针对管程有两种实现
- 一种是基于Object的Monitor机制,用于synchronized内置锁的实现
- 一种是抽象队列同步器AQS,用于JUC包下Lock锁机制的实现
AQS原理分析
什么是AQS
java.util.concurrent包中的大多数同步器实现都是围绕着共同的基础行为,比如等待队列、条件队列、独占获取、共享获取等,而这些行为的抽象就是基于AbstractQueuedSynchronizer(简称AQS)实现的,AQS是一个抽象同步框架,可以用来实现一个依赖状态的同步器。
JDK中提供的大多数的同步器如Lock, Latch, Barrier等,都是基于AQS框架来实现的
- 一般是通过一个内部类Sync继承 AQS
- 将同步器所有调用都映射到Sync对应的方法
AQS具备的特性:
- 阻塞等待队列
- 共享/独占
- 公平/非公平
- 可重入
- 允许中断
AQS核心结构
AQS内部维护属性volatile int state
- state表示资源的可用状态
State三种访问方式:
- getState()
- setState()
- compareAndSetState()
定义了两种资源访问方式:
- Exclusive-独占,只有一个线程能执行,如ReentrantLock
- Share-共享,多个线程可以同时执行,如Semaphore/CountDownLatch
AQS实现时主要实现以下几种方法:
- isHeldExclusively():该线程是否正在独占资源。只有用到condition才需要去实现它。
- tryAcquire(int):独占方式。尝试获取资源,成功则返回true,失败则返回false。
- tryRelease(int):独占方式。尝试释放资源,成功则返回true,失败则返回false。
- tryAcquireShared(int):共享方式。尝试获取资源。负数表示失败;0表示成功,但没有剩余可用资源;正数表示成功,且有剩余资源。
- tryReleaseShared(int):共享方式。尝试释放资源,如果释放后允许唤醒后续等待结点返回true,否则返回false。
AQS定义两种队列
- 同步等待队列: 主要用于维护获取锁失败时入队的线程。
- 条件等待队列: 调用await()的时候会释放锁,然后线程会加入到条件队列,调用signal()唤醒的时候会把条件队列中的线程节点移动到同步队列中,等待再次获得锁。
AQS 定义了5个队列中节点状态:
- 值为0,初始化状态,表示当前节点在sync队列中,等待着获取锁。
- CANCELLED,值为1,表示当前的线程被取消;
- SIGNAL,值为-1,表示当前节点的后继节点包含的线程需要运行,也就是unpark;
- CONDITION,值为-2,表示当前节点在等待condition,也就是在condition队列中;
- PROPAGATE,值为-3,表示当前场景下后续的acquireShared能够得以执行;
同步等待队列
AQS当中的同步等待队列也称CLH队列,CLH队列是Craig、Landin、Hagersten三人发明的一种基于双向链表数据结构的队列,是FIFO先进先出线程等待队列,Java中的CLH队列是原CLH队列的一个变种,线程由原自旋机制改为阻塞机制。
AQS 依赖CLH同步队列来完成同步状态的管理:
- 当前线程如果获取同步状态失败时,AQS则会将当前线程已经等待状态等信息构造成一个节点(Node)并将其加入到CLH同步队列,同时会阻塞当前线程
- 当同步状态释放时,会把首节点唤醒(公平锁),使其再次尝试获取同步状态。
- 通过signal或signalAll将条件队列中的节点转移到同步队列。(由条件队列转化为同步队列)
条件等待队列
AQS中条件队列是使用单向列表保存的,用nextWaiter来连接:
- 调用await方法阻塞线程;
- 当前线程存在于同步队列的头结点,调用await方法进行阻塞(从同步队列转化到条件队列)
ReentrantLock源码分析
ReentrantLock是一种基于AQS框架的应用实现,是JDK中的一种线程并发访问的同步手段,它的功能类似于synchronized是一种互斥锁,可以保证线程安全。
ReentrantLock基本使用方式
public class ReentrantLockTest {private final ReentrantLock lock = new ReentrantLock();// ...public void doSomething() {lock.lock(); // block until condition holdstry {// ... method body} finally {lock.unlock();}}
}
源码阅读过程中要关注的问题
1.公平和非公平锁,可重入锁是如何实现的
2.设计的精髓:并发场景下入队和出队操作是如何设计的
- 线程竞争锁失败入队阻塞逻辑实现
- 释放锁的线程唤醒阻塞线程出队竞争锁的逻辑实现
结合源码分析流程图理解ReentrantLock的实现
- 当线程1进入时,通过cas操作,首先将state状态更新为1,然后判断独占,将exclusiveOwnerThread置为线程1.
- 此时又来了线程2,通过cas操作时发现state=1,加锁失败,需要进行入队并且阻塞。首先判断是否有队列,没有队列时创建一个节点,thread为null,waitState为0,该节点既是head节点,又是tail节点。然后再创建一个结点,thread置为线程2,waitState为0,并将tail标志移到该节点。将head节点的next指针指向tail节点,tail节点的prev指针指向head节点(双向链表)。
- 在线程2阻塞前,将head节点state置为-1,用于之后线程2唤醒准备工作。并通过LockSupport.park(this)将线程2阻塞。
- 当此时又来了线程3,同第2步一样,通过cas操作时发现state=1,加锁失败,需要进行入队并且阻塞。发现有队列时,创建节点,thread置为线程3,waitState为0,并将tail标志移到该节点。将上一个节点(线程2)的next指针指向tail节点,tail节点的prev指针指向线程2节点。
- 同步骤3一样,在线程3阻塞前,将线程2节点state置为-1,用于之后线程3唤醒准备工作。并通过LockSupport.park(this)将线程3阻塞。
- 此时线程1完成并通过cas释放锁,将state状态置为0,exclusiveOwnerThread置为null。并为线程2出队做准备工作,将head节点waitState置为0.
- 此时线程2通过cas操作加锁成功,将state置为1,并将exclusiveOwnerThread置为线程2.然后线程2出队,将原来的线程2节点中,thread置为null,prev指针置为null,head节点的next指针也置为null,此时原来的线程2节点成为head节点。而原来的线程2节点没有任何引用会被GC回收。
注意:因为ReentranLock默认为非公平锁,因此在线程2通过cas加锁的同时,如果有新的线程进来时,会与线程2抢占锁。
这篇关于深入理解AQS独占锁之ReentrantLock源码分析的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!