Concurrent.util工具类详细讲解和使用

Concurrent.util常用类

1. CyclicBarrier使用：

假设有一个场景：每个线程代表一个跑步运动员，当运动员都准备好后，才一起出发，只要有一个没有准备好，大家都等待。（github）

2. CountDownLacth使用：

他经常用于监听某些初始化操作，等初始化执行完毕后，通知主线程继续工作。（github）

3. Callable和Future使用：

Callable与Runable相比有返回值。这个例子其实就是实现Future模式。jdk给与我们一个实现的封装，使用非常简单。（github）

Future模式非常合适在处理很耗时很长的业务逻辑时进行使用，可以有效的减小系统的响应时间，提高系统的吞吐量。

4. Semaphore信号量：

• 在Semaphore信号量非常适合高并发访问，新系统在上线之前，要对系统的访问量进行评估，当然这个值肯定不是随便拍拍脑袋就能想出来的，是经过以往的经验、数据、历年的访问量，已推广力度进行一个合理的评估，当然评估标准不能太大也不能太小，太大的话投入的资源达不到实际效果，纯粹浪费资源，太小的话，某个时间点一个小高峰的访问量上来直接可以压垮系统。
  相关概念：

• PV（page view）网站的总访问量，页面浏览量或点击量，用户每刷新一次就会被记录一次。

• UV（unique Visitor）访问网站的一台电脑客户端为一个访客。一般来讲，时间上以00:00-24:00之内相同ip的客户端只记录一次。

• QPS（query per second）即每秒查询数，qps很大程度上代表了系统业务上的繁忙程度，每次请求的背后，可能对应着多次磁盘I/O，多次网络请求，多个cpu时间片都等。我们通过qps可以非常直观的了解当前系统业务情况，一旦当前qps超过所设定的预警阀值，可以考虑增加机器对集群扩容，以免压力过大导致宕机，可以根据前期的压力测试得到估值，在结合后期综合运维情况，估算出阀值。

• RT（response time）即请求的响应时间，这个指标非常关键，直接说明前端用户的体验，因此任何系统设计师都想降低rt时间。
  当然还涉及到cpu、内存、网络、磁盘等情况，更细节的问题很多，如select、update、delete/ps等数据库层面的统计。

• 容量评估：一般来说通过开发、运维、测试、以及业务等相关人员，综合出系统的一系列阀值，然后我们根据关键阀值如qps、rt等对系统进行有效变更。

• 一般来讲，我们进行多轮压力测试以后，可以对系统进行峰值评估，采用所谓的80/20原则，即80%的访问请求将在20%的时间内到达。这样我们可以根据系统对应的PV计算出峰值qps。

• 峰值qps = （总PV * 80）/（606024*20%）

• 然后在总的峰值qps除以单台机器所能承受的最高qps值，就是所需要机器的数量：机器数 = 总的峰值qps / 压测得出的单机极限qps

• 当然不排除系统在上线前进行大型促销活动，或者双十一、双十二热点事件、遭受到DDos攻击等情况，系统的开发和维护人员急需要了解当前系统运行的状态和负载情况，一般都会有后台系统去维护。

Semaphore可以控制系统的流量：
拿到信号量的线程可以进入，否则等待。通过acquire()和release()获取和释放许可。（github）