性能优化-记ThreadPoolExecutor和CountDownLatch的一次实际优化经历

场景：作为电商系统，会经常需要统计某些商品的PV，UV，购物率等数据，并统计成可直观渲染查看的数据，供运营人员定制和决策活动做参考。
数据来源：BI团队，将前台商品的PV，UV，加车率，购买率等数据每天异步方式写入到统计数据表中，数据为T+ 1的方式。然后后台通过异步定时器读取数据，并汇总统计，形成图表。
问题：起初，BI推过来的商品数据量不是很大，后台异步定时器以单线程的方式运行足够应付这些数据，但随着活动商品的增加，BI推过来的商品数据越来越庞大，定时器分析数据经常在规定的时间内没法分析完成，导致运营人员经常投诉。
问题解决：将单线程的方式改为多线程的方式。新建一个ThreadPoolExecutor，将统计分析的功能单独抽出来放到一个新的线程类中。然后根据服务器的cpu处理器的个数，在线程池中创建对应数据的线程数。
新的问题：多线程同时去统计分析数据虽然能解决时间和速度上的问题，但却带来一个新的问题。如果同一个商品的统计数据分到了多个线程统计，那么有可能A统计的数据被B统计的数据覆盖掉了，导致数据结果不准确。
解决：采用CountDownLatch的功能，用来监控我们运行的线程是否都已经运行完成，如果未完成，主线程wait，如果运行完成，那么将多个线程中相同的数据进行汇总统计，再回写到数据库。汇总统计时采用HashMap数据结构，对相同商品(key值)进行汇总，也就不会出现上面的问题了。

继续优化的思路：分片，并增加机器，在多台机器上进行多线程分析。考虑将待分析的数据按机器的数量分成均匀的片区，每台机器分析某个片区的数据。