随着应用的数据量不断的增加，系统的反应一般会越来越慢，这个时候我们就需要性能调优。性能调优的步骤如下：
寻找性能瓶颈
通常性能瓶颈的表象是资源消耗过多、外部处理系统的不足，或者资源消耗不多，但是程序的响应速度却达不到要求。下面的分析针对于Linux。
CPU消耗分析
CPU主要用于中断、内核以及用户进程的处理；优先级为中断、内核和用户进程。我们首先有了解3个概念。
1.上下文切换
线程从CPU换出到下一次执行，称为一次上下文切换。上下文切换过多带来的影响：内核占用较多的CPU使用时间，响应速度下降。
2.运行队列
每一个CPU核都维护一个可运行的线程队列，一般建议每个CPU的运行队列是1-3个。
利用率
CPU利用率为CPU在用户进程、内核、中断处理、IO等待以及空闲5个部分使用百分比。可以使用top或者pidstat命令查看。
top
1.2%us,表示用户进程处理所占的百分比，0.4%sy表示系统内核线程处理所占用的百分比，0.0%表示改变优先级任务所占的百分比，98%id表示CPU空闲时间所占的百分比，0.0%wa表示等待IO所占用百分比，0.0%hi表示由于硬件中断所占用的百分比；0.4%si表示软件中断所占用的百分比；
可以在上面试图的基础上按1，就可查看每个CPU的运行情况。注意两图的变化：
可以查看每个进程所占用的CPU情况。
pidstat
需要安装sysstat，然后在使用pidstat 1 2，表示每隔1s输出，一共输出两次，如下
cpu表示当前使用CPU的个数，如果需要详细查看某一个进程，可以使用如下命令
TID表示线程id，这个命令的好处是可以查看每一个线程的具体CPU和线程使用率。
需要知道的是CPU消耗主要集中在us，sy两个值中。
1.us
java造成高us的主要原因是：线程一直处于可运行状态、通常是循环、正则和无阻塞运行造成的；还有一个原因是频繁的GC。解决问题的思路是
先通过Linux命令定位出那一个线程的us较高，然后将线程的id转化为16进制，然后通过 kill -3 [javapid]或者jstack的方式dump出应用的java线程信息，通过之前转化出来的16进制值找到nid值的线程。该线程也就是CPU消耗型线程，这里需要多采样几次，以确保准确。
2.sy
造成这个的主要原因是：启动了很多的线程，且这些线程主要是阻塞和可执行之间切换，然后造成了大量的上下文切换。
解决思路同上。