common和select线程数分别为10,20时，通过观察线程状态，select线程出现等待getTask，cpu会到达94%，tps相应的也会增加，并发数的增加也只是提高了tps，但是会导致响应时间的下降；另外并发增大时，select线程都在执行任务，common线程出现在latch上面等待，但是响应时间慢了，cpu忙了，因为所有的select线程都在运行，线程上下文切换（CS）次数肯定会大量增加（可以vmstat查看），
总结： 综合这4组压测数据，初步有个简单的结论，common线程池决定了整体的吞吐量（TPS），但是吞吐量提升的的同时，CPU和响应时间也会增大，而select线程需要依赖common线程的个数，比例在1.5-2之间，少了会导致TPS上不去响应时间也会增加，大了CPU上去了，最终也会导致响应时间的增加，所以common和select线程数的选择需要有据可询。那么针对当前的机器配置，兼顾TPS，响应时间和CPU使用率（低于90%），common线核心程池数设置8，select线程数设为12，此时100的并发数，CPU最高在90%，TPS在760，平均响应时间100ms。
优化方向：
通过线程状态和业务流程的分析，我们发现可以将并发部分的业务流程进行细分，主要划分为IO等待型任务和CPU计算型任务，然后使用不同的线程池，IO型的就多设置线程数，CPU型的就少一点。有个初始经验值
IO 型：2 * CPU个数
CPU型：CPU个数 + 1
另外，分析过程中为了方便线程池配置的变更和观察使用公共包ThreadPoolManager来管理系统所有的线程池。有需要的可以使用
附压测时机器的其他指标，供参考
Pidstat
Vmstat
Mpstat