常用并发工具类总结
JUC
下的常用并发工具类(锁和线程间通信工具类),主要包括 ReentrantLock
、ReentrantReadWriteLock
、CountDownLatch
、CyclicBarrier
、Semaphore
、Exchanger
ReentrantLock 和 ReentrantReadWriteLock
ReentrantLock
是可重入独占锁,ReentrantReadWriteLock
是可重入读写锁。
ReentrantLock
ReentrantLock
支持公平和非公平锁两种模式,可以通过 new ReentrantLock(boolean fair)
构造方法来指定公平或非公平模式,默认为非公平模式。
注意,公平和非公平模式在这里主要指的是尝试获取锁的线程是否会在排到同步队列末尾之前尝试获取一遍锁。
- 如果在排到队尾之前会尝试获取一边锁,那么就是非公平模式,因为有可能在这一次尝试获取就直接得到了锁,等同于一个插队操作,所以是非公平锁
- 如果是老老实实排到队尾,那么就是公平模式,因为不会存在插队操作
ReentrantLock
的公平与非公平模式,主要是靠其内部的两个 AQS
子类,FairSync
和 NonfairSync
来实现的。
RenntrantReadWriteLock
ReentrantReadWriteLock
是读写锁,其主要性质如下:
ReentrantReadWriteLock
内部有一个Sync
对象,用于执行所有的同步机制Sync
类继承了AQS
Sync
类有一个公平锁实现FairSync
,和一个非公平锁实现NonfairSync
Sync
类中state
的含义为,高16
位代表获取读锁的次数,低16
位代表获取写锁的次数
- 内部有一个
ReadLock
对象(读锁),有一个WriteLock
对象(写锁)- 读锁和写锁实际上都是依赖于
Sync
对象来实现的 - 基于
Sync
对象对于state
的定义,读锁和写锁的获取次数上限都为 65535 (2^16-1
) - 读锁的加锁操作本质上是对
state
的高16
位进行+1
操作,释放锁本质上是对state
的高16
位进行-1
操作 - 写锁的加锁操作本质上是对
state
的低16
位进行+1
操作,释放锁本之上是对state
的低16
位进行-1
操作
- 读锁和写锁实际上都是依赖于
- 操作顺序与互斥关系
- 读读不互斥
- 写写互斥
- 读写互斥
- 写读互斥
- 读锁和写锁均可重入
- 读锁不能升级为写锁(即持有读锁时去获取写锁)
- 如果使用
writeLock().lock()
获取写锁会发生死锁 - 如果使用
writeLock().tryLock(long timeout, Timeunit unit)
会在超时后返回
- 如果使用
- 写锁可以降级为读锁(即持有写锁时去获取读锁)
- 读锁和写锁的加锁和释放锁的逻辑必须成对出现
Semaphore
Semaphore
是信号量的意思,主要用于限定临界资源同时能被多少个线程访问。主要特性:
- 内部有一个
Sync
类继承了AQS
,是AQS
共享模式的一种具体实现 Sync
类有一个公平锁实现FairSync
,和一个非公平锁实现NonfairSync
,由构造函数public Semaphore(int permits, boolean fair)
来指定- 公平锁实现,当前线程获取不到许可时,将会进入队列等待
- 非公平锁实现,当前线程将会一直(自旋)尝试获取许可
Sync
类中state
的含义为public Semaphore(int permits)
中permits
的数值(许可的数量)Sync
类的获取许可操作本质上是对state
的-1
操作,释放许可操作本之上是对state
的+1
操作
Exchanger
Exchanger
是交换器的意思,主要用于两个线程之间的数据交换。
注意在多个线程同时使用一个 Exchanger
对象进行数据交换的时候,交换结果可能是未知的。所以 Exchanger
适用于成对线程之间的数据通信。
CyclicBarrier
CyclicBarrier
是循环栅栏的意思,主要用于帮助多个线程同时达到某个等待点后再把这些线程唤醒。主要特性:
- 主要的构造函数为
public CyclicBarrier(int parties)
和public CyclicBarrier(int parties, Runnable barrierAction)
parties
代表的是参与协作的线程数量barrierAction
代表的是协作线程的数量等于parties
时,将会执行的动作
CyclicBarrier
有一把内置的ReentrantLock
锁,和由这把锁创建出来的一个Condition
对象- 当调用
await()
方法时,首先会尝试获取锁,获取成功后当前需要等待的剩余协作线程数量-1
- 如果此时需要等待的剩余协作线程数量不为
0
,即代表参与协作的线程数量还没有到达初始设定的数量,则调用Condition
对象的await()
方法,将当前线程阻塞在Condition
对象的条件队列中 - 如果此时需要等待的协作线程数量为
0
,即代表参与协作的线程数量已经到达了初始设定的数量,则执行打开栅栏动作(调用nextGeneration()
方法),(调用Condition
对象的singalAll()
方法)唤醒所有等待在Condition
对象上的线程,唤醒完成后,重置栅栏到初始状态
- 如果此时需要等待的剩余协作线程数量不为
- 当调用
reset()
方法时,之前调用了await()
方法的所有线程将会被唤醒,并抛出异常 - 当某个线程调用了
await()
方法后被中断,那么CyclicBarrier
会被设置成一个中断状态,此时需要调用reset()
方法把CyclicBarrier
对象重置成初始状态
总的来说 ,CyclicBarrier
是通过 AQS
的条件等待机制(ConditionObject
)来实现的
CountDownLatch
CountDownLatch
是计数门闩的意思,主要用于在一组执行线程都到达某个等待点之后,再唤醒等待在这个门闩上的所有线程一个同步工具。
- 内部有一个
Sync
类继承了AQS
,是AQS
共享模式的一种具体实现 Sync
类中state
的含义为public CountDownLatch(int count)
中count
的数值(需要打开门闩的次数)- 调用
countDown()
方法后(相当于尝试释放共享锁),将会使用CAS
+ 自旋将state
变量值-1
- 调用
await()
方法后(相当于尝试获取共享锁),首先会判断当前的state
是否等于0
- 如果等于
0
,则获取成功,将会立马返回 - 如果不等于
0
,则获取失败,当前线程将会被封装为共享节点放入到AQS
同步队列中,并阻塞
- 如果等于
CyclicBarrier 和 CountDownLatch 的异同
相同点:
- 都是
JUC
包下的同步工具类 - 都是
AQS
的应用实例 - 都可以在指定数目个线程到达某个等待点后,执行一些动作
不同点:
- 实现目标不同:
CyclicBarrier
是帮助多个协作线程最终都到达某个等待点后,再同时唤醒这些协作线程本身CountDownLatch
是在多个执行线程最终都到达某个等待点后,再同时唤醒所有等待线程
- 调用方式不同:
CyclicBarrier
调用await()
方法后,如果此时的count
值不为0
,那么将会阻塞自身,所以不能在同一时间连续调用CountDownLatch
在调用countDown()
方法后,不会阻塞自身,在同一时间可以连续调用
- 阻塞、修改计数计数和通知的对象不一样:
CyclicBarrier
阻塞、修改计数和通知的对象都是执行await()
方法的线程CountDownLatch
阻塞和通知的是调用await()
方法的线程,修改计数的对象是执行countDown()
方法的线程
- 实现方式不同:
CyclicBarrier
是基于AQS
的条件等待机制来实现的CountDownLatch
内部有一个Sync
类直接继承了AQS
,是AQS
共享机制的一种实现
- 状态是否可重置:
CyclicBarrier
可以在到达计数条件后重置自身状态,可以重复使用;也可以主动调用reset()
方法来重置自身状态CountDownLatch
不能重置自身状态,不能重复使用
- 计数条件到达后是否可以执行操作:
CyclicBarrier
可以调用public CyclicBarrier(int parties, Runnable barrierAction)
中传入计数条件到达后的操作。在计数条件到达之后,将会调用barrierAction
的run()
方法执行一些特殊操作CountDownLatch
不能设置计数条件到达后的执行操作