一次性能调优笔记(线程池)
普通的性能调优主要从四个方面入手
网络，磁盘IO，内存，CPU四个方面入手，下面案例就是从这四个角度来看。
?
我们的页面每天PV在30W ，主要是分布在两个主要页面：个人主页，展示主页。假设每个页面各自承担50%的PV，假设访问时间集中在白天8小时，平均下来每秒的请求数是 5.2个，考虑到高峰情况，那么我们就乘以系数20, 就当100个处理，我们最大的一个请求会产生13个processor ,也就是说 最大产生的线程回事 13*100 = 1300。也就是说高峰时刻会有1300个线程需要被处理，我们将队列设置为1000，对于高峰情况就抛弃，因为若是为了满足高峰情况的需要，就会使得部分请求处在队列中，不能充分的利用CPU的资源。
?
在做压力测试时候，自身应用内部做了小的多线程处理的框架，内部采用的线程池是 SPRING的 ThreadPoolTaskExecutor 的类，通过自身的一个监控框架我们发现，所有的线程单元执行的很快，但是在最后组装processor的时候，花费了时间，在过程中观察CPU的利用率并不是很高。
所以预估是在等待所有线程执行完成时，也就是说有大量的processor在线程池的等待队列中，为了验证是否由于该原因造成的，所以做如下测试：
?
因为前面提到每秒的平均请求是5.2 考虑到一般的情况，就设置为压测的并发数为 3*5 = 15.
?
测试案例一：
?
15线程?
循环100次
线程池：
?corePoolSize ： CPU = 4?
?maxPoolSize ?： 2 * corePoolSize = 8?
?queueCapacity ： 1000?
?
压测页面： /xxx/22933?
?
---------------------------------------------- 这个是分割线 ----------------------------------------------
稳定情况下的线程数：
[root@host_77-69 ~]# ps -eLf | grep java ?| wc -l?
229
主要是观察，是否充分利用了CPU核数，达到我们预期的效果。现在的服务继承很多框架或是模块后，会启动很多你不知道的线程，在那跑着，时不时跳出来干扰你下，所以一定要等系统运行稳定后观察这个数值。
---------------------------------------------- 这个是分割线 ----------------------------------------------
CPU的一些信息：
[root@host_77-69 ~]# vmstat -ns 3 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 2056 723528 392024 1330728 0 0 0 1 1 2 0 0 100 0 0 0 0 2056 723404 392024 1330728 0 0 0 0 467 806 0 0 100 0 0 0 0 2056 723404 392028 1330728 0 0 0 17 462 807 0 0 100 0 0 0 0 2056 723404 392028 1330728 0 0 0 0 457 814 0 0 100 0 0??
主要是关注 in ， cs 这两个参数
in：每秒软中断次数
cs: 每秒上下文切换的次数
?
因为操作系统本身会有一些操作，在未压测前的数值基本在 460 .800 左右。
---------------------------------------------- 这个是分割线 ----------------------------------------------
?
[root@host_77-69 ~]# mpstat -P ALL 5 Linux 2.6.32-71.el6.x86_64 (host_77-69) 09/12/2012 _x86_64_(4 CPU)02:04:21 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle02:04:26 PM all 0.10 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.9002:04:26 PM 0 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.80??
关注soft 这个参数 这个代表当前CPU在所有时间中，用于切换上下所化时间比,若是花费的越多，代表当前的线程切换过于频繁，没有充分利用CPU，建议减少线程数或是增加CPU。
user 、 nice、sys主要是观察系统中是否存在大量计算，或是死循环的情况，来消耗大量的CPU。
这个命令是对于vmstat的补充，更直观的观察CPU的上下文切换及软中断情况。
?
---------------------------------------------- 下面是内存的初始情况了 ----------------------------------------------
JVM自身的内存情况：
?
[root@host_77-69 ~]# jstat -gcutil `jps | grep -i main | awk '{print $1}'` 3000 1000 S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 0.00 90.91 13.56 60.25 26 0.877 2 0.802 1.679 0.00 0.00 91.17 13.56 60.25 26 0.877 2 0.802 1.679 0.00 0.00 91.27 13.56 60.25 26 0.877 2 0.802 1.679 0.00 0.00 91.28 13.56 60.25 26 0.877 2 0.802 1.679?fugcc次数基本不变，而且各个代内存变化基本不大?
?
操作系统的内存情况：
?
[root@host_77-69 releases]# for i in {1..10};do free;sleep 3 ; done; total used free shared buffers cachedMem: 3925596 3223996 701600 0 392352 1330896-/+ buffers/cache: 1500748 2424848Swap: 4194296 2056 4192240 total used free shared buffers cachedMem: 3925596 3223996 701600 0 392352 1330896-/+ buffers/cache: 1500748 2424848Swap: 4194296 2056 4192240 total used free shared buffers cachedMem: 3925596 3223996 701600 0 392352 1330896-/+ buffers/cache: 1500748 2424848Swap: 4194296 2056 4192240??数值也基本保持不变化
?
---------------------------------------------- 下面是磁盘IO的初始情况了 ----------------------------------------------?
?
[root@host_77-69 ~]# for i in {1..10};do iostat ; sleep 3 ; done ;Linux 2.6.32-71.el6.x86_64 (host_77-69) 09/12/2012 _x86_64_(4 CPU)avg-cpu: %user %nice %system %iowait %steal %idle 0.10 0.00 0.02 0.00 0.00 99.88Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtnsda 0.31 0.33 5.93 1751462 31740872Linux 2.6.32-71.el6.x86_64 (host_77-69) 09/12/2012 _x86_64_(4 CPU)avg-cpu: %user %nice %system %iowait %steal %idle 0.10 0.00 0.02 0.00 0.00 99.88Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtnsda 0.31 0.33 5.93 1751462 31740960??主要观察?
Blk_read/s ? ?每秒中读取的块数
Blk_wrtn/s ? ?每秒中写的块数
%iowait ? ? ? 当前在等待磁盘IO的情况
?
---------------------------------------------- 说了这么多终于要开始了 ----------------------------------------------?
?
开始压测后，得到下面的数据：
?
[root@host_77-69 ~]# vmstat -ns 3 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----0 0 2056 698224 393212 1331344 0 0 0 3 536 867 0 0 100 0 0 3 0 2056 694796 393212 1332248 0 0 0 19 7170 7515 55 4 40 0 0 1 0 2056 694796 393212 1333132 0 0 0 4 7121 7627 50 5 45 0 0 4 0 2056 692936 393216 1334376 0 0 0 17 6478 8738 54 5 42 0 0 2 0 2056 691548 393232 1335620 0 0 0 25 6497 7663 48 4 48 0 0 5 0 2056 689936 393232 1337052 0 0 0 3 7597 7174 47 5 48 0 0 3 0 2056 688704 393232 1338496 0 0 0 12 7369 8774 49 5 45 0 0 3 0 2056 686348 393232 1341528 0 0 0 819 12298 16011 50 5 45 0 0 4 0 2056 684976 393236 1343020 0 0 0 12 6034 6951 48 4 48 0 0 3 0 2056 664268 393240 1344508 0 0 0 1 6731 9584 52 5 42 0 0 1 0 2056 659360 393240 1346284 0 0 0 12 7797 8431 54 5 41 0 0 2 0 2056 657624 393240 1347564 0 0 0 2684 6908 7656 50 5 45 0 0??
在压测的这个过程中，CPU大量上下文切换动作明显增加了很多。
?
[root@host_77-69 ~]# mpstat -P ALL 5 04:01:32 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle04:01:37 PM all 0.15 0.00 0.10 0.00 0.00 0.05 0.00 0.00 99.7004:01:37 PM 0 0.20 0.00 0.00 0.00 0.00 0.20 0.00 0.00 99.6004:01:37 PM 1 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.8004:01:37 PM 2 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.8004:01:37 PM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00?
这个数据上看出其中一个CPU花费在切换的时间比是0.2%，也不是很高。
?
[root@host_77-69 ~]# ps -eLf | grep java | wc -l 229[root@host_77-69 ~]# ps -eLf | grep java | wc -l 236[root@host_77-69 ~]# ps -eLf | grep java | wc -l 236[root@host_77-69 ~]# ps -eLf | grep java | wc -l 235[root@host_77-69 ~]# ps -eLf | grep java | wc -l 229[root@host_77-69 ~]# ps -eLf | grep java | wc -l 229??
java的线程数增加到了236，也就是说增加了7个，我们最初设置是4个，队列1000 ，在队列满了后，增加了3个，也就是说，这种情况，扩容到7个线程，就能满足我们的压测条件，那说明core为4，存在大量的队列积压情况，同时，上面的数据表明，用于上下文切换的比例也不是很高，如此我们就可以增加线程池的corePoolSize。那么下个案例就可以设置为8个试试看。
?
[root@host_77-69 ~]# jstat -gcutil `jps | grep -i main | awk '{print $1}'` 3000 1000 S0 S1 E O P YGC YGCT FGC FGCT GCT 0.00 27.46 76.94 19.37 60.86 31 1.139 3 1.497 2.636 0.00 23.34 85.64 19.37 60.90 33 1.150 3 1.497 2.647 0.00 36.14 38.44 19.37 60.91 35 1.167 3 1.497 2.665 0.00 63.19 37.87 19.37 60.92 37 1.191 3 1.497 2.688 59.29 0.00 1.61 19.48 60.92 40 1.226 3 1.497 2.723 0.00 50.63 58.22 19.50 60.93 41 1.236 3 1.497 2.733 0.00 51.09 70.36 19.58 60.94 43 1.265 3 1.497 2.762 44.05 0.00 2.09 19.67 60.95 46 1.298 3 1.497 2.795 0.00 83.74 75.70 19.68 60.96 47 1.316 3 1.497 2.813 0.00 89.57 77.32 20.21 60.96 49 1.350 3 1.497 2.847 46.02 0.00 36.83 22.12 60.97 52 1.399 3 1.497 2.896 36.69 0.00 37.78 22.12 60.98 54 1.417 3 1.497 2.914 59.51 0.00 23.47 22.12 61.00 56 1.435 3 1.497 2.932 64.53 0.00 36.51 22.29 61.03 58 1.461 3 1.497 2.959 73.19 0.00 78.00 23.01 61.05 60 1.497 3 1.497 2.995 54.24 0.00 36.10 23.01 61.06 62 1.521 3 1.497 3.018 79.36 0.00 82.65 23.01 61.08 64 1.547 3 1.497 3.044 0.00 68.75 48.34 26.61 61.10 67 1.606 3 1.497 3.103 29.33 0.00 93.75 26.61 61.12 68 1.613 3 1.497 3.110 0.00 45.32 23.68 26.61 61.12 71 1.640 3 1.497 3.138 34.93 0.00 19.75 29.84 61.13 74 1.697 3 1.497 3.194 22.59 0.00 27.47 29.84 61.14 76 1.711 3 1.497 3.208 54.40 0.00 74.16 30.45 61.15 78 1.734 3 1.497 3.231 25.23 0.00 77.50 30.45 61.15 80 1.747 3 1.497 3.245 25.23 0.00 98.39 30.45 61.15 80 1.747 3 1.497 3.245 25.23 0.00 99.94 30.45 61.15 80 1.747 3 1.497 3.245 0.00 14.32 1.42 30.45 61.15 81 1.752 3 1.497 3.250 0.00 14.32 2.15 30.45 61.15 81 1.752 3 1.497 3.250 0.00 14.32 2.27 30.45 61.15 81 1.752 3 1.497 3.250 0.00 14.32 2.48 30.45 61.15 81 1.752 3 1.497 3.250?
?
这个是查看JVM的GC情况的，数据表明，压测期间，ygc还是蛮频繁，但是每次ygc后进入old区的数据并不是很多，说明我们的应用大部分是朝生夕死，并不会发生频繁fgc的情况，之后就不用把重心放在JVM的GC上。
?
[root@host_77-69 releases]# for i in {1..10};do free;sleep 3 ; done; total used free shared buffers cachedMem: 3925596 3370968 554628 0 395584 1369572-/+ buffers/cache: 1605812 2319784Swap: 4194296 2056 4192240?操作系统跟之心前相比，基本没有发生任何的改变。
?
avg-cpu: %user %nice %system %iowait %steal %idle 0.10 0.00 0.02 0.00 0.00 99.88Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtnsda 0.31 0.33 5.95 1751462 31823032Linux 2.6.32-71.el6.x86_64 (host_77-69) 09/12/2012 _x86_64_(4 CPU)avg-cpu: %user %nice %system %iowait %steal %idle 0.10 0.00 0.02 0.00 0.00 99.88Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtnsda 0.31 0.33 5.95 1751462 31823032
?
?
这个是当前应用对于磁盘的消耗情况，对比初始值，基本没什么变化，可以看出我们这个应用没有磁盘IO的消耗，这说明本应用并没有大量的操作本地磁盘IO情况。
这个也不是导致我们系统慢的原因，也可以排除。
?
?
xxxModuleProcessor33 最慢的processor是33毫秒
?
我们的processor最大的消耗是33毫秒，外部调用4.9ms ，但是最后看到的消耗时间是557ms，且上面的情况说明了，存在大量队列积压，我们的数据处理processor都在等待队列了
?
下面是我们通过
Avg(ms):
第一次： 662.5 毫秒
第二次： 680 ? 毫秒
第三次： 690 ? 毫秒
?
通过上面的分析，平均响应时间是：680ms,基本可以确定问题在于线程池corePoolSize过小,导致了一定的数据在队列中积压。
?
?
--------------------------------------------- ?这是一条伟大的分割线 ?---------------------------------------------
测试案例二：
?
改动：增加一倍的corePoolSize
?
15线程?
循环100次
线程池：
?corePoolSize ；2 * CPU = ?8?
?maxPoolSize ?：2 * corePoolSize = 16?
?queueCapacity ： 1000?
?
压测页面： /member/22933?
?
--------------------------------------------- ?我又出现了 ?---------------------------------------------
?
再次启动稳定后：
[root@host_77-69 ~]# for i in {1..10000};do ? ?ps -eLf | grep java ?| wc -l; echo "-------" ; sleep 2 ; done;
215
-------
215
-------
215
-------
?
java的线程数维持在215个，跟上面有点不同，当然不管了，这个不是重点。
?
?
[root@host_77-69 ~]# vmstat -ns 3 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- 0 0 2056 933420 395768 1341376 0 0 0 8 579 875 0 0 100 0 0 0 0 2056 933420 395768 1341376 0 0 0 3 579 860 0 0 100 0 0 0 0 2056 933420 395776 1341372 0 0 0 9 568 867 0 0 100 0 0?
?
初始情况CPU运行都很正常?
?
?
[root@host_77-69 ~]# mpstat -P ALL 5 Linux 2.6.32-71.el6.x86_64 (host_77-69) 09/12/2012 _x86_64_(4 CPU)05:43:34 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle05:43:39 PM all 0.40 0.00 0.10 0.00 0.00 0.00 0.00 0.00 99.5005:43:39 PM 0 0.80 0.00 0.20 0.00 0.00 0.00 0.00 0.00 99.00
?
基本没有软中断
?
压测后得到如下数据：
[root@host_77-69 ~]# for i in {1..10000};do ? ?ps -eLf | grep java ?| wc -l; echo "-------" ; sleep 2 ; done;
214
-------
214
-------
214
-------
217
-------
219
-------
219
-------
。。。。。。
221
-------
219
-------
。。。。。。
218
-------
218
-------
214
-------
这个java线程数的变化情况，从 214-- 221 -- 214。 初始化了8个，然后增加了7个，也就是说线程池中总共启用了15个线程。
------------------------------------------------------ ?
?
[root@host_77-69 ~]# mpstat -P ALL 5 05:59:00 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle05:59:05 PM all 51.46 0.00 4.58 0.00 0.29 2.00 0.00 0.00 41.6705:59:05 PM 0 50.98 0.00 4.71 0.00 0.98 7.25 0.00 0.00 36.0805:59:05 PM 1 51.07 0.00 4.29 0.00 0.00 0.39 0.00 0.00 44.2505:59:05 PM 2 50.49 0.00 4.87 0.00 0.00 0.19 0.00 0.00 44.4405:59:05 PM 3 53.29 0.00 4.46 0.00 0.00 0.19 0.00 0.00 42.0505:59:05 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle05:59:10 PM all 49.56 0.00 4.25 0.00 0.29 2.00 0.00 0.00 43.8905:59:10 PM 0 46.56 0.00 3.73 0.00 1.18 7.07 0.00 0.00 41.4505:59:10 PM 1 58.12 0.00 4.31 0.00 0.00 0.39 0.00 0.00 37.1805:59:10 PM 2 45.72 0.00 4.67 0.00 0.00 0.39 0.00 0.00 49.2205:59:10 PM 3 47.95 0.00 4.29 0.00 0.00 0.39 0.00 0.00 47.3705:59:10 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle05:59:15 PM all 50.54 0.00 4.19 0.00 0.29 1.75 0.00 0.00 43.2305:59:15 PM 0 55.36 0.00 3.70 0.00 1.17 5.85 0.00 0.00 33.9205:59:15 PM 1 53.62 0.00 4.70 0.00 0.00 0.59 0.00 0.00 41.1005:59:15 PM 2 46.98 0.00 4.29 0.00 0.00 0.19 0.00 0.00 48.5405:59:15 PM 3 46.21 0.00 4.27 0.00 0.00 0.19 0.00 0.00 49.3205:59:15 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle05:59:20 PM all 52.78 0.00 4.48 0.05 0.39 2.14 0.00 0.00 40.1705:59:20 PM 0 52.17 0.00 3.94 0.00 1.57 7.68 0.00 0.00 34.6505:59:20 PM 1 52.35 0.00 4.90 0.00 0.00 0.39 0.00 0.00 42.3505:59:20 PM 2 57.09 0.00 4.85 0.00 0.00 0.19 0.00 0.00 37.8605:59:20 PM 3 49.42 0.00 4.23 0.00 0.00 0.38 0.00 0.00 45.9605:59:20 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle05:59:25 PM all 46.90 0.00 3.85 0.00 0.34 1.76 0.00 0.00 47.1505:59:25 PM 0 48.34 0.00 3.70 0.00 1.56 6.43 0.00 0.00 39.9605:59:25 PM 1 43.30 0.00 4.47 0.00 0.00 0.39 0.00 0.00 51.8405:59:25 PM 2 50.59 0.00 3.52 0.00 0.00 0.39 0.00 0.00 45.5105:59:25 PM 3 45.14 0.00 3.70 0.00 0.00 0.19 0.00 0.00 50.97??
上面的数据表明，中断占CPU的比例确大大增加了。单核中断最高达到了7.25% 如此导致了什么结果呢?
?
Min(ms)Max(ms)Avg(ms)95Line(ms)Std(ms)TPS
161.2 ?8877.4731.7 ?1000.0 ? ?65.3 ?1.2
?
想比较corePoolSize:4 max:8 性能反而下降了。平均响应时间从662.5降到了731.7。
?
最慢的processor的消耗时间是：187.9
?
期间也猜测可能是其中一个服务被我们压坏了，就重启了那个服务，再次压测的结果是
Min(ms)Max(ms)Avg(ms)95Line(ms)Std(ms)TPS
102.9 ?9188.9762.5 ?1095.0 ? ?657.8 ?3.0
?
平均响应时间是：750毫秒左右。
?
也就是说，基本可以确认是由于我们增加了 coreSize和maxSize导致性能变慢了。慢了近80毫秒。说明过多的CPU并不会加快我们的处理速度。
如此就有了下面的方案。
?
测试方案三：
corePoolSize : cpu数量 + 1 ?= 5?
maxPoolSzie : 2 * corePoolSize = 10?
?
我们看下具体情况吧：
?
?
[root@host_77-69 ~]# mpstat -P ALL 5 06:57:36 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle06:57:41 PM all 58.27 0.00 5.38 0.00 0.49 2.30 0.00 0.00 33.5606:57:41 PM 0 61.66 0.00 4.74 0.00 1.98 8.10 0.00 0.00 23.5206:57:41 PM 1 55.75 0.00 5.65 0.00 0.00 0.58 0.00 0.00 38.0106:57:41 PM 2 57.81 0.00 5.47 0.00 0.00 0.20 0.00 0.00 36.52??
CPU的上下文切换还是很厉害。达到了8.10%
[root@host_77-69 ~]# for i in {1..10000};do ? ?ps -eLf | grep java ?| wc -l; echo "-------" ; sleep 2 ; done;
214
-------
214
-------
219
-------
219
-------
217
-------
215
-------
214
?
214--219?
原来线程池core是5，我们最大是10个，线程数确实增加到了10个，就是说10个线程对应到4个CPU上，两者的比例是1:2.25?
?
结果：
第一次压测是：648毫秒
第二次压测是：622毫秒
第三次压测是：603毫秒
?
就取中间值吧：622毫秒?
?
性能想比较 core：8 max:16的话，有0.060毫秒的提升。说明一定cpu和进程数保持在1:2.25的比例上，效率上还是有提高的，但是上下文切换的还是很厉害。
?
为了不让它切换的这么厉害，就将max设置的小点吧。
?
测试方案四
线程：15?
循环：100次
corePoolSize : cpu数量 + 1 ? ?= ?5?
maxPoolSzie : 2 * cpu ? ?= ?8
?
08:13:13 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle08:13:18 PM all 52.45 0.00 4.60 0.00 0.10 1.27 0.00 0.00 41.5808:13:18 PM 0 60.00 0.00 3.96 0.00 0.59 3.96 0.00 0.00 31.4908:13:18 PM 1 50.29 0.00 5.48 0.00 0.00 0.20 0.00 0.00 44.0308:13:18 PM 2 50.78 0.00 4.86 0.00 0.00 0.58 0.00 0.00 43.7708:13:18 PM 3 48.83 0.00 4.28 0.00 0.00 0.19 0.00 0.00 46.6908:13:18 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle08:13:23 PM all 50.05 0.00 4.29 0.00 0.10 1.22 0.00 0.00 44.3408:13:23 PM 0 57.54 0.00 4.56 0.00 0.20 3.97 0.00 0.00 33.7308:13:23 PM 1 49.81 0.00 4.28 0.00 0.00 0.39 0.00 0.00 45.5308:13:23 PM 2 48.16 0.00 3.88 0.00 0.00 0.39 0.00 0.00 47.5708:13:23 PM 3 45.07 0.00 4.45 0.00 0.00 0.19 0.00 0.00 50.2908:13:23 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle08:13:28 PM all 51.34 0.00 4.69 0.00 0.10 1.27 0.00 0.00 42.6008:13:28 PM 0 60.08 0.00 4.15 0.00 0.40 3.95 0.00 0.00 31.4208:13:28 PM 1 47.75 0.00 6.07 0.00 0.00 0.39 0.00 0.00 45.7908:13:28 PM 2 47.48 0.00 4.26 0.00 0.00 0.39 0.00 0.00 47.8708:13:28 PM 3 50.19 0.00 4.28 0.00 0.00 0.39 0.00 0.00 45.14
中断时间确实从7%下降到了4%左右。
[root@host_77-69 ~]# for i in {1..10000};do ? ?ps -eLf | grep java ?| wc -l; echo "-------" ; sleep 2 ; done;
215
-------
217
-------
217
-------
219
-------
219
-------
218
-------
线程池基本处于饱和状态。
?
结果：
第一次压测结果：629毫秒
第二次压测结果：618毫秒
第三次压测结果：586毫秒
?
这次CPU:线程数为1:2
相比较CPU和线程数1.2.25的结果有稍微的提升，因为CPU中断时间比下降了。
?
最终的结论，JVM的垃圾回收，本地磁盘IO，操作系统内存都不会对本应用产生影响，唯一的元素就是线程池大小的设置。目前测试出来的最佳策略是：
corePoolSize = cpu + 1
maxPoolSize = 2 * cpu??
?