从火箭发场景来学习Java多线程并发闭锁对象
倒计时器场景
在我们开发过程中,有时候会使用到倒计时计数器。最简单的是:int size = 5; 执行后,size—这种方式来实现。但是在多线程并发的情况下,这种操作会不安全的。举个现实中最典型的一个例子:火箭发射的案例。
大家都看过火箭发射的直播吧。火箭在发送的时候,有很多设备需要检查是否都准备就绪。在总控室得到所有设备都准备就绪后,才会下达发射的命令。我们也知道,火箭发射有很多设备需要检验,这不是一个部门一个一个检查的,而是多个部门协同配合实现的。如果把一个个部门看作不同的线程的话。我们就可以假设:
如果是一个部门一个一个设备检查,这就是单线程操作的;
如果是多个部门协同配合的话,就是多线程的。
所以说,在火箭发射前检查设备是 多线程情况下进行的。
我们也不知道,不同部门负责检查的设备的复杂度不同,速度不同,就会导致有些部门检查完成的快,有些部门检查完成的慢。这个过程我们可以理解为不同线程在竞争CPU资源的时候不同。
假设有5个部门同时协同工作,这5个部门的操作可以看作是一组操作。因为速度不同,那么总控室下达发射的命令是以哪个检查完毕为准呢?是A部门还是B部门或者D部门呢?都不是,总控室下达发射的命令是在得到5个部门都检查完毕后才会下达发射的命令。我们也可以理解为总控室在得到这一组(五个部门)都操作完成才执行的。此时总控室可以理解为一个线程,五个部门一组可以理解一个线程组。
从上面现实生活中的案例分析,我们来想想上面的操作用Java程序怎么实现 ?
使用count—的代码实现
模拟不同部门的线程:
我们先来看看常规的。使用count--的效果。
模拟总控室的主线程:
从上面代码中,我们可以看到当计数器count减到0的时候,总控室下达发射命令。这个从逻辑上来说,是正确的,没问题的。我们来看看运行结果:
运行结果:
从运行结果,我们可以看到,当总控室接收到count =0的指令后,认为各个部门都已经检查完毕了。所以就下达了发射命令。但是在最后,我们发现火箭已经发射了,部门4和5才想总控室汇报检查完毕,准备就绪。这种情况是很危险的。因为我们知道火箭的造价是很昂贵的而且凝聚了很多科研人员的心血。如果因为某个部门未检查完毕就发射而导致火箭发射失败或者坠落,在现实生活中,这种情况是不允许出现的。
那么这种情况,在Java中,怎么解决呢?可以使用countdownlatch这个对象来解决。
Countdownlatch
Countdownlatch是什么?
先来看看源码中怎么解释的:A synchronization aid that allows one or more threads to wait until a set of operations being performed in other threads completes.
什么意思呢?
简单的来说,是一个同步辅助工具类,运行一个或多个线程在等待其他线程完成一组操作后再接着执行的工具类。
实现的流程:
通过一个计数器来实现的,计数器的初始值就是要执行的线程的数量。每当一个线程执行完毕之后,计数器的值就会减一,当计数器的的减少到0的时候,表示所有的线程都执行完毕了。然后再闭锁上等待的其他线程就可以恢复正常工作了。
来看看主要的方法
说明:
Sync:是countdownlatch内部类,继承AbstractQueuedSynchronizer使用AQS状态来代替计数的。
有参构造器:public CountDownLatch(int count){}
await():等待方法。还有一个带参数重载的方法。
countdown():执行计数器减1操作的方法。
使用countdownlatch模拟火箭发射前准备代码:
我们来看看使用countdownlatch来模拟火箭发射前准备会不会出问题。
来看看模拟部门的线程代码:
为了保证计数器减一操作不受子线程运行结果影响,讲count.coundDown()操作放在finally代码块里面。
再来看看总控室下达发射命令的主线程:
在downLatch.await()之后,下达发射命令。
查看运行结果:
我们可以看到,当所有部门都准备就绪后,总控室接收到完成的指令后,下达发射火箭命令。这个流程才是正常的。从运行结果来看也是正常的。
使用场景:
场景1:某线程在运行前需要等待其他N个线程执行完成之后在执行。
比如:
容器启动spring 容器的启动,需要初始化、bean装配、检查其他依赖等加载完毕之后,在主线程在继续执行;
在比如:电商中统计库存问题。我们知道,一个电商项目有很多分类,不同分类下的库存不一样。如果要统计当前剩余总库存。这个时候,就可以使用其他线程统计每个分类下的库存。等所有分类都统计完成之后,主线程在进行汇总操作。