一.CountDownLatch 和 CyclicBarrier的区别

1. CountDownLatch和CyclicBarrier都是线程同步的工具类，都是基于AQS实现的；
2. CountDownLatch 的计数器是大于或等于线程数的，而CyclicBarrier是一定等于线程数；
3. CountDownLatch 放行由其他线程控制而CyclicBarrier是由本身来控制的，CountDownLatch允许一个或多个线程一直等待，直到这些线程完成它们的操作，而CyclicBarrier不一样，它往往是当线程到达某状态后，暂停下来等待其他线程，等到所有线程均到达以后，才继续执行，二者的等待主体是不一样的；
4. CountDownLatch调用await()通常是主线程/调用线程，而CyclicBarrier调用await()是在任务线程调用的；
5. CountDownLatch 操作的是事件，阻塞足够多的次数即可，不管几个线程；而 CyclicBarrier 侧重点是线程，强调多个线程间互相等待，同时结束；
6. CountDownLatch 是不可以重置的，所以无法重用；而 CyclicBarrier 则没有这个限制，可以重用；

二.详解

CountDownLatch是通过计数器实现，每次完成一个任务后，计数器减一当为0时，CountDownLatch.await()方法的线程就可以恢复执行任务。

CountDownLatch是基于AQS实现的，它的实现机制很简单，当我们在构建CountDownLatch对象时，传入的值其实就会赋值给 AQS 的关键变量state，执行countDown方法时，其实就是利用CAS 将state 减一，执行await方法时，其实就是判断state是否为0，不为0则加入到队列中，将该线程阻塞掉（除了头结点），因为头节点会一直自旋等待state为0，当state为0时，头节点把剩余的在队列中阻塞的节点也一并唤醒。

CyclicBarrier是直接借助ReentrantLock加上Condition 等待唤醒的功能 进而实现的，在构建CyclicBarrier时，传入的值会赋值给CyclicBarrier内部维护count变量，也会赋值给parties变量（这是可以复用的关键），每次调用await时，会将count -1 ，操作count值是直接使用ReentrantLock来保证线程安全性，如果count不为0，则添加则condition队列中，如果count等于0时，则把节点从condition队列添加至AQS的队列中进行全部唤醒，并且将parties的值重新赋值为count的值（实现复用）

总结

CountDownlatch基于AQS实现，会将构造CountDownLatch的入参传递至state，countDown()就是在利用CAS将state减-1，await()实际就是让头节点一直在等待state为0时，释放所有等待的线程
CyclicBarrier则利用ReentrantLock和Condition，自身维护了count和parties变量。每次调用await将count-1，并将线程加入到condition队列上。等到count为0时，则将condition队列的节点移交至AQS队列，并全部释放。

用法

CountDownLatch 用法

从代码层面，CountDownLatch 的用法是：

// 设置10个计数 
CountDownLatch countDownLatch = new CountDownLatch(10); 
// 每次调用即可减1 
countDownLatch.countDown(); 
// 其他线程一直等待减到0后，才继续执行 
countDownLatch.await()

举个栗子：
假设有一个业务场景，我们要求把所有的图片上传到文件服务器，然后将图片的地址URL保存到数据库;
其中上传素材，我们可以使用多线程去上传，都上传完之后，再入库。

publicbooleandealVedoi(List<Vedio>vedioList){//每个线程处理的最大任务数intmaxNum=10;intthreadNums=0;Map<String,String>map=newConcurrentHashMap<String,String>((int)(vedioList.size()/0.75));if(vedioList.size()<maxNum){threadNums=1;}else{//获取当前系统可用的处理器核心数量threadNums=Runtime.getRuntime().availableProcessors()>vedioList.size()/maxNum?vedioList.size()/maxNum:Runtime.getRuntime().availableProcessors();}try{//创建固定线程数处理这批任务ExecutorServiceexecutor=Executors.newFixedThreadPool(threadNums);CountDownLatchcountDownLatch=newCountDownLatch(vedioList.size());Iterator<Vedio>iterator=vedioList.iterator();while(iterator.hasNext()){executor.submit(()->{Vediovedio=iterator.next();Stringurl=store(vedio);map.put(vedio.getName());countDownLatch.countDown();});}countDownLatch.await();//所有素材上传成功后，入库saveDataBase(map);}catch(InterruptedExceptione){e.printStackTrace();}
}

newFixedThreadPool 方法用于创建一个固定大小的线程池，其中参数指定线程池的大小（即线程数量）。

适合的线程池大小取决于你的具体需求和应用场景。以下几点是需要考虑的因素：

1. 任务的性质： 如果你的任务是 CPU 密集型的（需要大量的计算和处理），那么线程池的大小通常与处理器的核心数相近或略多一些可能是合适的。这样可以充分利用 CPU 资源。如果任务是 I/O 密集型的（例如涉及网络请求或文件操作），则可能需要更多的线程，以充分利用等待 I/O 的时间。
2. 可用的系统资源： 考虑可用的系统资源，包括 CPU 核心数、内存和其他正在运行的应用程序。如果系统资源有限，将线程池大小保持在合理的范围内，以避免过度消耗资源。
3. 任务的数量和规模： 考虑任务的数量和规模。如果你预计会有大量的任务需要处理，并且这些任务是短暂的，那么增加线程池的大小可以提高并发处理能力。但是，如果任务的数量较少或任务的执行时间较长，可能不需要太多的线程。
   需要注意的是，如果线程池的大小设置过大，可能会导致资源竞争、上下文切换开销增加，甚至对系统性能产生负面影响。因此，需要根据实际情况进行调整和测试，找到适合你应用程序的线程池大小。
   综合考虑以上因素，你可以根据你的应用需求和性能测试来选择一个合适的线程池大小。通常情况下，线程池大小在 2 到 10 之间是一个常见的范围。根据实际情况进行调整和优化是最佳的做法。

CyclicBarrier 用法

从代码使用角度来说：

// 初始化值为5的栅栏 
CyclicBarrier cyclicBarrier = new CyclicBarrier(5); 
// 每个线程调用 await()
cyclicBarrier.await(); 
// 等到有 5 个线程都执行了 await() 之后，继续执行。 
// 并且 栅栏的 计数器会自动重置为 5 ，可以接着用

然后我们模拟一个场景
在游戏中，选好英雄之后，会等待所有 5 个玩家进度条都到 100% 才开始游戏，我们可以使用 CyclicBarrier 来模拟这个场景

publicclassCyclicBarrierTest{privatefinalstaticExecutorServiceEXECUTOR_SERVICE=Executors.newFixedThreadPool(5);privatefinalstaticCyclicBarrierBARRIER=newCyclicBarrier(10);publicstaticvoidmain(String[]args){for(inti=0;i<5;i++){finalStringname="玩家"+i;EXECUTOR_SERVICE.execute(newRunnable(){@Overridepublicvoidrun(){try{Thread.sleep(2000);System.out.println(name+"已准备,等待其他玩家准备...");BARRIER.await();Thread.sleep(1000);System.out.println(name+"已加入游戏");}catch(InterruptedExceptione){System.out.println(name+"离开游戏");}catch(BrokenBarrierExceptione){System.out.println(name+"离开游戏");}}});}EXECUTOR_SERVICE.shutdown();}
}