常用并发工具类总结

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 不能设置计数条件到达后的执行操作