并发工具类CountDownLatch
countdownlatch 是一个同步工具类,它允许一个或多个线程一直等待,直到其他线程的操作执行完毕再执行。
从命名可以解读到 countdown 是倒数的意思,类似于我们倒计时的概念。
countdownlatch 提供了两个方法,一个是 countDown, 一个是 await, countdownlatch 初始化的时候需要传入一个整数,在这个整数倒数到 0 之前,调用了 await 方法的程序都必须要等待,然后通过 countDown 来倒数。
CountDownLatch的构造函数
public CountDownLatch(int count) {
if (count < 0) throw new IllegalArgumentException("count < 0");
this.sync = new Sync(count);
}
使用案例
public class Test {
public static void main(String[] args) throws InterruptedException {
CountDownLatch countDownLatch = new CountDownLatch(3);
new Thread(() -> {
System.out.println("" + Thread.currentThread().getName() + "-执行中");
countDownLatch.countDown();
System.out.println("" + Thread.currentThread().getName() + "-执行完毕");
}, "t1").start();
new Thread(() -> {
System.out.println("" + Thread.currentThread().getName() + "-执行中");
countDownLatch.countDown();
System.out.println("" + Thread.currentThread().getName() + "-执行完毕");
}, "t2").start();
new Thread(() -> {
System.out.println("" + Thread.currentThread().getName() + "-执行中");
countDownLatch.countDown();
System.out.println("" + Thread.currentThread().getName() + "-执行完毕");
}, "t3").start();
countDownLatch.await();
System.out.println("所有线程执行完毕");
}
}
从代码的实现来看,有点类似 join 的功能,但是比 join 更加灵活。CountDownLatch 构造函数会接收一个 int 类型的参数作为计数器的初始值,当调用 CountDownLatch 的 countDown 方法时,这个计数器就会减一。通过 await 方法去阻塞去阻塞主流程
CountDownLatch 源码分析
public class CountDownLatch {
/**
* Synchronization control For CountDownLatch.
* Uses AQS state to represent count.
*/
private static final class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = 4982264981922014374L;
Sync(int count) {
setState(count);
}
int getCount() {
return getState();
}
可以看到CountDownLatch 中有内部类Sync继承了AbstractQueuedSynchronizer(AQS,同步队列)
对于 CountDownLatch,我们仅仅需要关心两个方法,一个是 countDown() 方法,另一个是 await() 方法。 countDown() 方法每次调用都会将 state 减 1,直到 state 的值为 0;而 await 是一个阻塞方法,当 state 减为 0 的时候,await 方法才会返回。await 可以被多个线程调用,大家在这个时候脑子里要有个图:所有调用了 await 方法的线程阻塞在 AQS 的阻塞队列中,等待条件满足(state == 0),将线程从队列中一个个唤醒过来。
CountDownLatch.await();
public void await() throws InterruptedException {
sync.acquireSharedInterruptibly(1);
}
countdownlatch 也用到了 AQS,在 CountDownLatch 内部写了一个 Sync 并且继承了 AQS 这个抽象类,重写了 AQS 中的共享锁方法。首先看到下面这个代码,这块代码主要是判断当前线程是否获取到了共享锁;(在 CountDownLatch 中,使用的是共享锁机制,因为 CountDownLatch 并不需要实现互斥的特性)
public final void acquireSharedInterruptibly(int arg)
throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
if (tryAcquireShared(arg) < 0)//state 如果不等于 0,说明当前线程需要加入到共享锁队列中
doAcquireSharedInterruptibly(arg);
}
protected int tryAcquireShared(int acquires) {
return (getState() == 0) ? 1 : -1;
}
private void doAcquireSharedInterruptibly(int arg) // 获取可中断共享锁
throws InterruptedException {
//创建一个共享模式的节点添加到队列中
final Node node = addWaiter(Node.SHARED);// addWaiter 设置为 shared 模式。
boolean failed = true;
try {
for (;;) {
final Node p = node.predecessor();
if (p == head) {
int r = tryAcquireShared(arg);//尝试获取锁
if (r >= 0) {//r>=0表示获取到了执行权限,这个时候因为 state!=0,所以不会执行这段代码
setHeadAndPropagate(node, r);
p.next = null; // help GC
failed = false;
return;
}
}
//阻塞线程
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
doAcquireSharedInterruptibly (可中断共享)
- addWaiter 设置为 shared 模式。
- tryAcquire 和 tryAcquireShared 的返回值不同,因此会多出一个判断过程
- 在判断前驱节点是头节点后,调用了setHeadAndPropagate方法,而不是简单的更新一下头节点。
图解分析
假如这个时候有 3 个线程调用了 await 方法,由于这个时候 state 的值还不为 0,所以这三个线程都会加入到 AQS 队列中。并且三个线程都处于阻塞状态
第一步:将当前线程封装成node添加到aqs队列,并且锁的状态为共享锁
CountDownLatch.countDown();
public void countDown() {
sync.releaseShared(1);
}
public final boolean releaseShared(int arg) {
if (tryReleaseShared(arg)) {
doReleaseShared();
return true;
}
return false;
}
protected boolean tryReleaseShared(int releases) {
// Decrement count; signal when transition to zero
for (;;) { //用自旋的方法实现 state 减 1
int c = getState();
if (c == 0)
return false;
int nextc = c-1;
if (compareAndSetState(c, nextc))
return nextc == 0;
}
}
由于线程被 await 方法阻塞了,所以只有等到 countdown 方法使得 state=0 的时候才会被唤醒,我们来看看 countdown 做了什么
- 只有当 state 减为 0 的时候,tryReleaseShared 才返回 true, 否则只是简单的 state = state - 1
- 如果 state=0, 则调用 doReleaseShared唤醒处于 await 状态下的线程
AQS. doReleaseShared
private void doReleaseShared() {
for (;;) {
Node h = head;
if (h != null && h != tail) {
int ws = h.waitStatus;
if (ws == Node.SIGNAL) {
if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
continue; // loop to recheck cases
unparkSuccessor(h);
}
// 这个CAS失败的场景是:执行到这里的时候,刚好有一个节点入队,入队会将这个ws设置为 -1
else if (ws == 0 &&
!compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
continue; // loop on failed CAS
}
// 如果到这里的时候,前面唤醒的线程已经占领了 head,那么再循环
// 通过检查头节点是否改变了,如果改变了就继续循环
if (h == head) // loop if head changed
break;
}
}
h == head:说明头节点还没有被刚刚用 unparkSuccessor 唤醒的线程(这里可以理解为 ThreadB)占有,此时 break 退出循环。
h != head:头节点被刚刚唤醒的线程(这里可以理解为 ThreadB)占有,那么这里重新进入下一轮循环,唤醒下一个节点(这里是 ThreadB )。我们知道,等到 ThreadB 被唤醒后,其实是会主动唤醒 ThreadC…
共享锁的释放和独占锁的释放有一定的差别。前面唤醒锁的逻辑和独占锁是一样,先判断头结点是不是 SIGNAL 状态,如果是,则修改为 0,并且唤醒头结点的下一个节点
PROPAGATE: 标识为 PROPAGATE 状态的节点,是共享锁模式下的节点状态,处于这个状态下的节点,会对线程的唤醒进行传播(像多米诺骨牌一样一个一个去唤醒)
doAcquireSharedInterruptibly
private void doAcquireSharedInterruptibly(int arg) // 获取可中断共享锁
throws InterruptedException {
//创建一个共享模式的节点添加到队列中
final Node node = addWaiter(Node.SHARED);// addWaiter 设置为 shared 模式。
boolean failed = true;
try {
for (;;) {//被唤醒的线程进入下一次循环继续判断
final Node p = node.predecessor();
if (p == head) {
int r = tryAcquireShared(arg);//尝试获取锁
if (r >= 0) {//r>=0表示获取到了执行权限,这个时候因为 state!=0,所以不会执行这段代码
setHeadAndPropagate(node, r);
//把当前节点移除 aqs 队列
p.next = null; // help GC
failed = false;
return;
}
}
//阻塞线程
if (shouldParkAfterFailedAcquire(p, node) &&
parkAndCheckInterrupt())
throw new InterruptedException();
}
} finally {
if (failed)
cancelAcquire(node);
}
}
一旦 ThreadA 被唤醒,代码又会继续回到 doAcquireSharedInterruptibly 中来执行。如果当前 state 满足=0 的条件,则会执行 setHeadAndPropagate 方法
setHeadAndPropagate
private void setHeadAndPropagate(Node node, int propagate) {
Node h = head; // Record old head for check below
setHead(node);
if (propagate > 0 || h == null || h.waitStatus < 0 ||
(h = head) == null || h.waitStatus < 0) {
Node s = node.next;
if (s == null || s.isShared())
doReleaseShared();
}
}
这个方法的主要作用是把被唤醒的节点,设置成 head 节 点。 然后继续唤醒队列中的其他线程。 由于现在队列中有 3 个线程处于阻塞状态,一旦 ThreadA 被唤醒,并且设置为 head 之后,会继续唤醒后续的 ThreadB
图示:
并发工具类CycliBarrier
CyclicBarrier 的字面意思是可循环使用(Cyclic)的屏障 (Barrier)。它要做的事情是,让一组线程到达一个屏障(也可以叫同步点)时被阻塞,直到最后一个线程到达屏障时, 屏障才会开门,所有被屏障拦截的线程才会继续工作。 CyclicBarrier 默认的构造方法是 CyclicBarrier(int parties), 其参数表示屏障拦截的线程数量,每个线程调用 await 方 法告诉 CyclicBarrier 当前线程已经到达了屏障,然后当前线程被阻塞
使用场景
当存在需要所有的子任务都完成时,才执行主任务,这个时候就可以选择使用 CyclicBarrier
使用案例
DataImportThread
public class DataImportThread extends Thread {
private CyclicBarrier cyclicBarrier;
private String path;
public DataImportThread(CyclicBarrier cyclicBarrier, String path) {
this.cyclicBarrier = cyclicBarrier;
this.path = path;
}
@Override
public void run() {
System.out.println("开始导入:" + path + " 位置的数据");
try {
cyclicBarrier.await();//阻塞
} catch (InterruptedException e) {
e.printStackTrace();
} catch(BrokenBarrierException e) {
e.printStackTrace();
}
}
}
CycliBarrierDemo
public class CycliBarrierDemo extends Thread {
@Override
public void run() {
System.out.println("开始进行数据分析");
}
public static void main(String[] args) {
CyclicBarrier cycliBarrier = new CyclicBarrier(3, new CycliBarrierDemo());
new Thread(new DataImportThread(cycliBarrier, "file 1")).start();
new Thread(new DataImportThread(cycliBarrier, "file 2")).start();
new Thread(new DataImportThread(cycliBarrier, "file 3")).start();
}
}
注意点
- 对于指定计数值 parties,若由于某种原因,没有足够的线程调用 CyclicBarrier 的 await,则所有调用 await 的线程都会被阻塞;
- 同样的 CyclicBarrier 也可以调用 await(timeout, unit), 设置超时时间,在设定时间内,如果没有足够线程到达, 则解除阻塞状态,继续工作;
- 通过 reset 重置计数,会使得进入 await 的线程出现 BrokenBarrierException;
- 如果采用是 CyclicBarrier(int parties, Runnable barrierAction) 构造方法,执行 barrierAction 操作的是最后一个到达的线程
实现原理
CyclicBarrier 相比 CountDownLatch 来说,要简单很多, 源码实现是基于 ReentrantLock 和 Condition 的组合使用。
并发工具类Semaphore
semaphore 也就是我们常说的信号灯,semaphore 可以控制同时访问的线程个数,通过 acquire 获取一个许可,如果没有就等待,通过 release 释放一个许可。类似限流的作用。叫信号灯的原因也和他的用处有关,比如某商场就 5 个停车位,每个停车位只能停一辆车,如果这个时候来了 10 辆车,必须要等前面有空的车位才能进入。
使用场景
Semaphore 比较常见的就是用来做限流操作。
代码案例
public class Test {
public static void main(String[] args) {
Semaphore semaphore = new Semaphore(5);
for (int i = 0; i < 10; i++) {
new Car(i, semaphore).start();
}
}
static class Car extends Thread {
private int num;
private Semaphore semaphore;
public Car(int num, Semaphore semaphore) {
this.num = num;
this.semaphore = semaphore;
}
public void run() {
try {
semaphore.acquire();//获取一个许可
System.out.println("第" + num + "占用一个停车位 ");
TimeUnit.SECONDS.sleep(2);
System.out.println("第" + num + "辆车离开");
semaphore.release();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
Semaphore 源码分析
从 Semaphore 的功能来看,我们基本能猜测到它的底层实现一定是基于 AQS 的共享锁,因为需要实现多个线程共享一个令牌池
创建 Semaphore 实例的时候,需要一个参数 permits, 可以确定是设置给 AQS 的 state 的,然后每个线程调用 acquire 的时候,执行 state = state - 1,release 的时候执行 state = state + 1,当然,acquire 的时候,如果 state=0,说明没有资源了,需要等待其他线程 release。
Semaphore 分公平策略和非公平策略
FairSync 公平策略
static final class FairSync extends Sync {
private static final long serialVersionUID = 2014338818796000944L;
FairSync(int permits) {
super(permits);
}
protected int tryAcquireShared(int acquires) {
for (;;) {
// 区别就在于是不是会先判断是否有线程在排 队,然后才进行 CAS 减操作
if (hasQueuedPredecessors())
return -1;
int available = getState();
int remaining = available - acquires;
if (remaining < 0 ||
compareAndSetState(available, remaining))
return remaining;
}
}
}
NofairSync 非公平策略
通过对比发现公平和非公平的区别就在于是否多了一个 hasQueuedPredecessors 的判断
static final class NonfairSync extends Sync {
private static final long serialVersionUID = -2694183684443567898L;
NonfairSync(int permits) {
super(permits);
}
protected int tryAcquireShared(int acquires) {
return nonfairTryAcquireShared(acquires);
}
}
final int nonfairTryAcquireShared(int acquires) {
for (;;) {
int available = getState();
int remaining = available - acquires;
if (remaining < 0 ||
compareAndSetState(available, remaining))
return remaining;
}
}
由于后面的代码和 CountDownLatch 的是完全一样,都是基于共享锁的实现,所以也就没必要再花时间来分析了。