一场赛跑引发的并发知识

享学特邀做者：老顾

前言

咱们小伙伴们是否是常常须要测试代码的性能？小伙伴们是否是就会想到jmeter进行压力测试一下，模拟N个用户同时执行下，看看响应的时间多少。

今天老顾就用一个经典的比赛案例，来尝试自行编写个比赛业务，并随便介绍一下CyclicBarrier和CountDownLatch区别。 能够根据比赛业务，能够抽象出性能测试工具类。

需求场景

有N个短跑选手进行比赛，但愿记录下来整个比赛的时间

一、 第一名选手跑完比赛路程所花时间

二、 最后一名选手跑完比赛路程所花时间

三、 全部选手跑完比赛路程所花时间

四、 每一个选手跑完比赛路程所花时间之和

上面就是业务需求，那咱们如何去实现？

分析需求

先上个图，小伙伴们会更好理解

上图中4个选手在进行赛跑，咱们先看一下赛跑规则：

一、每一个 选手互不干扰，在本身的赛道上面进行跑步

二、选手在跑步前都须要活动一下， 作好预备姿式

三、选手是应该在 裁判一声枪响下，才能开始跑，不能提早跑

四、每一个选手在跑到终点时， 裁判会为每一个选手记录成绩

五、比赛结束后，大会公布各个选手的成绩，以及排名

设计思路

针对上面的规则，咱们须要转换成咱们的程序设计：

一、 选手间互不干扰，又同时进行赛跑。这个比较简单，确定用咱们的 Thread线程去解决。

二、记录时间这个也比较简单，利用System的时钟

咱们先到这边，先上代码，建立任务（赛跑）

RunTask表明选手的跑完比赛的耗时，为了真实模拟，加了随机数，表示每一个选手的耗时不同。继续代码，直接在main方法中，进行比赛

上面是一些基础变量，记录耗时。小伙伴要注意要用AtomicLong原子类，避免线程安全问题。下面的代码就是比赛核心逻辑

一、建立线程（选手）

二、执行任务（赛跑）

三、记录成绩（耗时）

大会公布成绩

执行比赛

小伙伴看看，是否是明显不对啊，总耗时尽然为0，确定有问题。

应该有人发现了，由于咱们是在main方法中执行比赛的，其余线程单独执行，主main线程执行完就终止了程序，而不会管其余线程有没有结束。

这明显和咱们想要的不同，咱们须要等全部的选手跑完，才能算比赛结束。那应该怎么优化呢？往下看

CyclicBarrier

咱们这里引入一个知识点CyclicBarrier循环屏障，CyclicBarrier是一组线程互相等待，只有所有到达屏障点之后才能继续执行。能够举个生活场景

大巴车进入服务区进行休息，大巴车是要 等到全部乘客上车后，才能发车。 并非一我的上车了就能够发车了。这个是全部乘客都知道的规则， 互相等待全部人上车，才发车。 循环的意思就是大巴车是一直这种规则，可重复利用

咱们比赛的例子正好匹配，不是一个选手到达终点（屏障）就比赛结束，而是要等到全部选手到达终点才能结束比赛。

终点优化

根据上面的CyclicBarrier知识点，咱们把代码优化一下

1、增长CyclicBarrier变量

//定义屏障，为何要加1？
final CyclicBarrier cb = new CyclicBarrier(nThreads + 1);复制代码

为何要加1？由于比赛裁判确定先到终点（即主线程），那也须要等待，因此屏障点须要加1。

注意：这个是根据业务来的，若是设置屏障点，是根据业务逻辑设计的

2、选手跑完到屏障点

在选手跑完后，增长到达屏障点，等待

3、裁判到屏障点

这个代码是在main主线程的，也就是裁判会先到，设置屏障点

终点优化结束，执行比赛吧

这个成绩应该没有问题，把大赛的成绩都正确的显示出来了。

系统耗时

咱们小伙伴再仔细观察下，上面的成绩：

一、最后一名的耗时3397ms

二、比赛执行完耗时3398ms

相差1ms，固然咱们这里设计是以毫秒为单位的，若是以纳秒为单位他们的相差会比1ms少。这个不是关键，关键是其实最后一名跑完，其实就是比赛结束了。按照道理比赛执行耗时和最后一名的耗时是同样的哦。

比赛执行屡次，效果都同样相差1ms。这个是为何呢？就是由于系统耗时，咱们看看比赛是在何时记时的，是所有选手开跑后才记时的。这边就会存在偏差，由于系统执行也会耗时

//上面全部选手都已经开跑了
//整个比赛的开始时间
long startTime = System.currentTimeMillis();
//。。。
//整个比赛的结束时间
long endTime = System.currentTimeMillis();复制代码

就是由于系统执行也是会消耗时间的。固然耗时不大就是几纳秒。小伙伴知道这个点后，会不会发现咱们整个代码还存在一个问题？

起点问题

咱们一场比赛是要等全部选手准备好后，等待裁判发令后，才能开跑。咱们来看一下咱们的选手开跑代码

选手是经过for循环建立出来的，并且创新好后，就执行start开跑了。这个是不对的。

小伙伴会说for循环很快的，不要紧吧。

这里是颇有关系的，建立选手耗时是比较长的，并且循环体也有耗时。咱们看一下以前的系统耗时，就是获取结束时间也存在系统耗时，况且这里要分配内存、建立对象等。这样对其余选手就不公平了，那怎么办？老顾再分享一个并发控制类CountDownLatch

CountDownLatch

CountDownLatch是一个或一组线程等待其余线程完成各自的工做后再执行。举个例子：

你们考场考试， 有人提早交卷，但监考老师是不能走的，由于还有人没有考完，只有等到 全部人交卷了，老师才能走。是否是和CyclicBarrier相似，他们也有不一样点，自行百度。

到咱们这个案例中，应该要等待全部选手准备好后，才能开跑。

起点优化

增长变量，计数器为1，这个值是由咱们的设计决定的

//增长CountDownLatch控制类
final CountDownLatch cdl = new CountDownLatch(1);复制代码

选手预备等待

裁判发令

裁判发令后，全部的选手就会当即开跑，利用CountDownLatch达到了控制线程等待，一块儿执行。再执行比赛看看，也解决了系统耗时偏差的问题

-----------大会公布成绩-------------
比赛选手数：4
------------------------
全部选手总耗时：6686ms
比赛执行完耗时：1920ms
第一名耗时：1281ms
最后一名耗时：1920ms复制代码

总结

这篇文章只是个引子，把并发编程的两个重要的类抛出来，主要介绍应用场景。具体类的用法，小伙伴们能够网上自行学习。还有CyclicBarrier和CountDownLatch二者有相同点，有些场景能够替换使用。固然他们也有不一样点，小伙伴们要注重关注。谢谢！！！

小伙伴是否是会说，那个 性能测试工具类呢？其实上面已经把90%的核心代码介绍了， 把跑步抽象成外部传入的任务，在加入 循环执行次数就ok了， 小伙伴能够自行完善。

END

欢迎长按下图关注公众号：享学课堂online！

公众号后台回复【java】，获取精选准备的架构学习资料（视频+文档+架构笔记）