应该有人发现了，因为我们是在main方法中执行比赛的，其他线程单独执行，主main线程执行完就终止了程序，而不会管其他线程有没有结束。
这明显和我们想要的不一样，我们需要等所有的选手跑完，才能算比赛结束。那应该怎么优化呢？往下看

CyclicBarrier

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

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

终点优化

根据上面的CyclicBarrier知识点，我们把代码优化一下
一、增加CyclicBarrier变量

//定义屏障，为什么要加1？
final CyclicBarrier cb = new CyclicBarrier(nThreads + 1);

为什么要加1？因为比赛裁判肯定先到终点（即主线程），那也需要等待，所以屏障点需要加1。

二、选手跑完到屏障点
在选手跑完后，增加到达屏障点，等待
三、裁判到屏障点
这个代码是在main主线程的，也就是裁判会先到，设置屏障点
终点优化结束，执行比赛吧

系统耗时

我们小伙伴再仔细观察下，上面的成绩：
1、最后一名的耗时3397ms
2、比赛执行完耗时3398ms
相差1ms，当然我们这里设计是以毫秒为单位的，如果以纳秒为单位他们的相差会比1ms少。这个不是关键，关键是其实最后一名跑完，其实就是比赛结束了。按照道理比赛执行耗时和最后一名的耗时是一样的哦。
比赛执行多次，效果都一样相差1ms。这个是为什么呢？就是因为系统耗时，我们看看比赛是在什么时候记时的，是全部选手开跑后才记时的。这边就会存在误差，因为系统执行也会耗时

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

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