性能优化的本质，就是最大发挥服务器服务能力。
- 是什么影响了CPU的能力发挥
- CPU出现空闲
线程数不足：线程数最好大于核心数
CPU等待：等待IO响应(比如JDK)，读内存有的数据（比读寄存器，缓冲区慢） - CPU忙于其他事
线程切换
被动切换：线程过多，为了公平,OS会进程强制切换
主动切换：并发锁争用导致线程切换，一般是中间件或应用并发处理能力的问题，线上无法控制
中断处理：较复杂，一般也介入不了。
- 调整配置依据：
对于第一种CPU空闲，我们通过增加线程数，提高IO速度让CPU忙起来。
对于第二种 除低线程数减少线程切换。 - 结论：线程数的最优值，就是一个平衡值。
线程池调优
线程池主要关注最大线程池大小。
- 为了不让CPU空闲，这个值最小要等于或接近CPU核心数。
- 不要让线程没必要过多导致线程切换，不要大于前端连接数。
（前端连接数<=LoadRunner并发数2）
所以得出表达式：
CPU 核心数(记为min)<=线程池最大值<=LoadRunner并发数 2(记为max)
如果请求是IO操作较慢，则增大线程，最多接近max值。
如果请求基本在CPU与内存之间完成，比如简单JSP，静态页面测试，因为都在内存中。
所以减少线程，最少接近min值。
通过Vmstat -r 列代表正在运行的线程数与准备就绪的线程数。 如果这个值经常大于CPU核数过多，说明线程配多了。如r小于CPU核数，说明线程本配少了。比CPU核数，稍多一点就可以, 即允许少量线程等待。
Pidstat -t -w -p time count 可以查看初动切换与主动切换情况。
JVM调优
－ 堆内存大小:根据实际应用需要调整，中间件自身内存要求不高。
－ 元空间最大值: 建议1G以上。
GC算法选择问题
总暂停时间: G1GC > Parallel Old > CMS
最大暂停时间：Parallel Old > CMS > G1GC
从总暂停时间看，G1GC的吞吐量并不理想，牺牲了吞吐量换来的是较快的响应时间。从上面的比较来看CMS是个不错的选择，但CMS的配置方法确实较复杂。
一般情况：4G堆以下选Parallel Old。以上选G1GC或CMS。
JDBC调优
- JDBC数据源基本属性
连接池大小：根据业务调整。 - JDBC数据源高级属性
1.缓存PreparedStatement 开启
2.缓存Statement功能按需开启(一般情况开启)
3.SQL跟踪+慢语句告警
该功能可以在日志输出较慢的SQL的执行时间，因为有些DB没优化之前较慢，可以用这个功能来发现DB是否存在慢的现象。