性能调优笔记
Java性能调优笔记
调优步骤：衡量系统现状、设定调优目标、寻找性能瓶颈、性能调优、衡量是否到达目标(如果未到达目标，需重新寻找性能瓶颈）、性能调优结束。
寻找性能瓶颈
性能瓶颈的表象：资源消耗过多、外部处理系统的性能不足、资源消耗不多但程序的响应速度却仍达不到要求。
资源消耗：CPU、文件IO、网络IO、内存。
外部处理系统的性能不足：所调用的其他系统提供的功能或数据库操作的响应速度不够。
资源消耗不多但程序的响应速度却仍达不到要求：程序代码运行效率不够高、未充分使用资源、程序结构不合理。
CPU消耗分析
CPU主要用于中断、内核、用户进程的任务处理，优先级为中断>内核>用户进程。
上下文切换：
每个线程分配一定的执行时间，当到达执行时间、线程中有IO阻塞或高优先级线程要执行时，将切换执行的线程。在切换时要存储目前线程的执行状态，并恢复要执行的线程的状态。
对于Java应用，典型的是在进行文件IO操作、网络IO操作、锁等待、线程Sleep时，当前线程会进入阻塞或休眠状态，从而触发上下文切换，上下文切换过多会造成内核占据较多的CPU的使用。
运行队列：
每个CPU核都维护一个可运行的线程队列。系统的load主要由CPU的运行队列来决定。
运行队列值越大，就意味着线程会要消耗越长的时间才能执行完成。
利用率：
CPU在用户进程、内核、中断处理、IO等待、空闲，这五个部分使用百分比。
文件IO消耗分析
Linux在操作文件时，将数据放入文件缓存区，直到内存不够或系统要释放内存给用户进程使用。所以通常情况下只有写文件和第一次读取文件时会产生真正的文件IO。
对于Java应用，造成文件IO消耗高主要是多个线程需要进行大量内容写入（例如频繁的日志写入）的动作、磁盘设备本身的处理速度慢、文件系统慢、操作的文件本身已经很大。
网络IO消耗分析
对于分布式Java应用，网卡中断是不是均衡分配到各CPU(cat/proc/interrupts查看)。
内存消耗分析（-Xms和-Xmx设为相同的值，避免运行期JVM堆内存要不断申请内存）
对于Java应用，内存的消耗主要在Java堆内存上，只有创建线程和使用Direct ByteBuffer才会操作JVM堆外的内存。
JVM内存消耗过多会导致GC执行频繁，CPU消耗增加，应用线程的执行速度严重下降，甚至造成OutOfMemoryError，最终导致Java进程退出。
JVM堆外的内存
swap的消耗、物理内存的消耗、JVM内存的消耗。
程序执行慢原因分析
锁竞争激烈：很多线程竞争互斥资源，但资源有限， 造成其他线程都处于等待状态。
未充分使用硬件资源：线程操作被串行化。
数据量增长：单表数据量太大（如1个亿）造成数据库读写速度大幅下降（操作此表）。
调优
JVM调优（最关键参数为：-Xms -Xmx -Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold）
代大小调优：避免新生代大小设置过小、避免新生代大小设置过大、避免Survivor设置过小或过大、合理设置新生代存活周期。
-Xmn 调整新生代大小，新生代越大通常也意味着更多对象会在minor GC阶段被回收，但可能有可能造成旧生代大小，造成频繁触发Full GC，甚至是OutOfMemoryError。
-XX:SurvivorRatio调整Eden区与Survivor区的大小，Eden 区越大通常也意味着minor GC发生频率越低，但可能有可能造成Survivor区太小，导致对象minor GC后就直接进入旧生代，从而更频繁触发Full GC。
GC策略的调优：CMS GC多数动作是和应用并发进行的，确实可以减小GC动作给应用造成的暂停时间。对于Web应用非常需要一个对应用造成暂停时间短的GC，再加上Web应用 的瓶颈都不在CPU上，在G1还不够成熟的情况下，CMS GC是不错的选择。
（如果系统不是CPU密集型，且从新生代进入旧生代的大部分对象是可以回收的，那么采用CMS GC可以更好地在旧生代满之前完成对象的回收，更大程度降低Full GC发生的可能）
在调整了内存管理方面的参数后应通过-XX:PrintGCDetails、-XX:+PrintGCTimeStamps、 -XX:+PrintGCApplicationStoppedTime以及jstat或visualvm等方式观察调整后的GC状况。
出内存管理以外的其他方面的调优参数：-XX:CompileThreshold、-XX:+UseFastAccessorMethods、 -XX:+UseBaiasedLocking。
程序调优
CPU消耗严重的解决方法
CPU us高的解决方法：
CPU us 高的原因主要是执行线程不需要任何挂起动作，且一直执行，导致CPU 没有机会去调度执行其他的线程。
调优方案： 增加Thread.sleep，以释放CPU 的执行权，降低CPU 的消耗。以损失单次执行性能为代价的，但由于其降低了CPU 的消耗，对于多线程的应用而言，反而提高了总体的平均性能。
（在实际的Java应用中类似场景， 对于这种场景最佳方式是改为采用wait/notify机制）
对于其他类似循环次数过多、正则、计算等造成CPU us过高的状况， 则需要结合业务调优。
对于GC频繁，则需要通过JVM调优或程序调优，降低GC的执行次数。
CPU sy高的解决方法：
CPU sy 高的原因主要是线程的运行状态要经常切换，对于这种情况，常见的一种优化方法是减少线程数。
调优方案： 将线程数降低
这种调优过后有可能会造成CPU us过高，所以合理设置线程数非常关键。
对于Java分布式应用，还有一种典型现象是应用中有较多的网络IO操作和确实需要一些锁竞争机制（如数据库连接池），但为了能够支撑搞得并发量，可采用协程（Coroutine）来支撑更高的并发量，避免并发量上涨后造成CPU sy消耗严重、系统load迅速上涨和系统性能下降。
在Java中实现协程的框架有Kilim，Kilim执行一项任务创建Task，使用Task的暂停机制，而不是Thread，Kilim承担了线程调度以及上下切换动作，Task相对于原生Thread而言就轻量级多了，且能更好利用CPU。Kilim带来的是线程使用率的提升，但同时由于要在JVM堆中保存Task上下文信息，因此在采用Kilim的情况下要消耗更多的内存。（目前JDK 7中也有一个支持协程方式的实现，另外基于JVM的Scala的Actor也可用于在Java使用协程）
文件IO消耗严重的解决方法
从程序的角度而言，造成文件IO消耗严重的原因主要是多个线程在写进行大量的数据到同一文件，导致文件很快变得很大，从而写入速度越来越慢，并造成各线程激烈争抢文件锁。
常用调优方法：
异步写文件
批量读写
限流
限制文件大小
网络IO消耗严重的解决方法
从程序的角度而言，造成网络IO消耗严重的原因主要是同时需要发送或接收的包太多。
常用调优方法：
限流，限流通常是限制发送packet的频率，从而在网络IO消耗可接受的情况下来发送packget。
内存消耗严重的解决方法
释放不必要的引用：代码持有了不需要的对象引用，造成这些对象无法被GC，从而占据了JVM堆内存。（使用ThreadLocal：注意在线程内动作执行完毕时，需执行ThreadLocal.set把对象清除，避免持有不必要的对象引用）
使用对象缓存池：创建对象要消耗一定的CPU以及内存，使用对象缓存池一定程度上可降低JVM堆内存的使用。
采用合理的缓存失效算法：如果放入太多对象在缓存池中，反而会造成内存的严重消耗， 同时由于缓存池一直对这些对象持有引用，从而造成Full GC增多，对于这种状况要合理控制缓存池的大小，避免缓存池的对象数量无限上涨。（经典的缓存失效算法来清除缓存池中的对象：FIFO、LRU、LFU等）
合理使用SoftReference和WeekReference：SoftReference的对象会在内存不够用的时候回收，WeekReference的对象会在Full GC的时候回收。
资源消耗不多但程序执行慢的情况的解决方法降低锁竞争： 多线多了，锁竞争的状况会比较明显，这时候线程很容易处于等待锁的状况，从而导致性能下降以及CPU sy上升。
使用并发包中的类：大多数采用了lock-free、nonblocking算法。
使用Treiber算法：基于CAS以及AtomicReference。
使用Michael-Scott非阻塞队列算法：基于CAS以及AtomicReference，典型ConcurrentLindkedQueue。
（基于CAS和AtomicReference来实现无阻塞是不错的选择，但值得注意的是，lock-free算法需不断的循环比较来保证资源的一致性的，对于冲突较多的应用场景而言，会带来更高的CPU消耗，因此不一定采用CAS实现无阻塞的就一定比采用lock方式的性能好。 还有一些无阻塞算法的改进：MCAS、WSTM等）
尽可能少用锁：尽可能只对需要控制的资源做加锁操作（通常没有必要对整个方法加锁，尽可能让锁最小化，只对互斥及原子操作的地方加锁，加锁时尽可能以保护资源的最小化粒度为单位--如只对需要保护的资源加锁而不是this）。
拆分锁：独占锁拆分为多把锁（读写锁拆分、类似ConcurrentHashMap中默认拆分为16把锁），很多程度上能提高读写的性能，但需要注意在采用拆分锁后，全局性质的操作会变得比较复杂（如ConcurrentHashMap中size操作）。（拆分锁太多也会造成副作用，如CPU消耗明显增加）
去除读写操作的互斥：在修改时加锁，并复制对象进行修改，修改完毕后切换对象的引用，从而读取时则不加锁。这种称为CopyOnWrite，CopyOnWriteArrayList是典型实现，好处是可以明显提升读的性能，适合读多写少的场景， 但由于写操作每次都要复制一份对象，会消耗更多的内存。
充分利用硬件资源（CPU和内存）：
充分利用CPU
在能并行处理的场景中未使用足够的线程（线程增加：CPU资源消耗可接受且不会带来激烈竞争锁的场景下）， 例如单线程的计算，可以拆分为多个线程分别计算，最后将结果合并，JDK 7中的fork-join框架。
Amdahl定律公式：1/(F+(1-F)/N)。
充分利用内存
数据的缓存、耗时资源的缓存（数据库连接创建、网络连接的创建等）、页面片段的缓存。
毕竟内存的读取肯定远快于硬盘、网络的读取， 在内存消耗可接受、GC频率、以及系统结构（例如集群环境可能会带来缓存的同步）可接受情况下，应充分利用内存来缓存数据，提升系统的性能。
总结：
好的调优策略是收益比（调优后提升的效果/调优改动所需付出的代价）最高的，通常来说简单的系统调优比较好做，因此尽量保持单机上应用的纯粹性， 这是大型系统的基本架构原则。
调优的三大有效原则：充分而不过分使用硬件资源、合理调整JVM、合理使用JDK包。
学习参考资料：
《分布式Java应用：基础与实践》 （有好多代码例子）
http://blog.csdn.net/bigtree_3721/article/details/51214249
JVM调优总结 -Xms -Xmx -Xmn -Xss
- 堆大小设置
JVM 中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统下，一般限制在1.5G~2G；64为操作系统对内存无限制。我在Windows Server 2003 系统，3.5G物理内存，JDK5.0下测试，最大可设置为1478m。
典型设置：- java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx3550m：设置JVM最大可用内存为3550M。
-Xms3550m：设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-Xmn2g：设置年轻代大小为2G。整个JVM内存大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
-Xss128k：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。 - java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
-XX:NewRatio=4:设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的1/5
-XX:SurvivorRatio=4：设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6
-XX:MaxPermSize=16m:设置持久代大小为16m。
-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。
- java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
- 回收器选择
JVM给了三种选择：串行收集器、并行收集器、并发收集器，但是串行收集器只适用于小数据量的情况，所以这里的选择主要针对并行收集器和并发收集器。默认情况下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后，JVM会根据当前系统配置进行判断。- 吞吐量优先的并行收集器
如上文所述，并行收集器主要以到达一定的吞吐量为目标，适用于科学技术和后台处理等。
典型配置：- java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelGC：选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，而年老代仍旧使用串行收集。
-XX:ParallelGCThreads=20：配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。 - java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
-XX:+UseParallelOldGC：配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。 - java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=100:设置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。 - java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveSizePolicy：设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收集器时，一直打开。
- java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
- 响应时间优先的并发收集器
如上文所述，并发收集器主要是保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。
典型配置：- java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC：设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好用-Xmn设置。
-XX:+UseParNewGC:设置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。 - java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。
-XX:+UseCMSCompactAtFullCollection：打开对年老代的压缩。可能会影响性能，但是可以消除碎片
- java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
- 吞吐量优先的并行收集器
- 辅助信息
JVM提供了大量命令行参数，打印信息，供调试使用。主要有以下一些：- -XX:+PrintGC
输出形式：[GC 118250K->113543K(130112K), 0.0094143 secs][Full GC 121376K->10414K(130112K), 0.0650971 secs]
- -XX:+PrintGCDetails
输出形式：[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs][GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
- -XX:+PrintGCTimeStamps -XX:+PrintGC：PrintGCTimeStamps可与上面两个混合使用
输出形式：11.851: [GC 98328K->93620K(130112K), 0.0082960 secs] - -XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前，程序未中断的执行时间。可与上面混合使用
输出形式：Application time: 0.5291524 seconds - -XX:+PrintGCApplicationStoppedTime：打印垃圾回收期间程序暂停的时间。可与上面混合使用
输出形式：Total time for which application threads were stopped: 0.0468229 seconds - -XX:PrintHeapAtGC:打印GC前后的详细堆栈信息
输出形式：
34.702: [GC {Heap before gc invocations=7:
def new generation total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K, 99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)
from space 6144K, 55% used [0x221d0000, 0x22527e10, 0x227d0000)
to space 6144K, 0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
tenured generation total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K, 3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:
def new generation total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
eden space 49152K, 0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)
from space 6144K, 55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
to space 6144K, 0% used [0x221d0000, 0x221d0000, 0x227d0000)
tenured generation total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
the space 69632K, 4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
}
, 0.0757599 secs] - -Xloggc:filename:与上面几个配合使用，把相关日志信息记录到文件以便分析。
- -XX:+PrintGC
- 常见配置汇总
- 堆设置
- -Xms:初始堆大小
- -Xmx:最大堆大小
- -XX:NewSize=n:设置年轻代大小
- -XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为1：3，年轻代占整个年轻代年老代和的1/4
- -XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5
- -XX:MaxPermSize=n:设置持久代大小
- 收集器设置
- -XX:+UseSerialGC:设置串行收集器
- -XX:+UseParallelGC:设置并行收集器
- -XX:+UseParalledlOldGC:设置并行年老代收集器
- -XX:+UseConcMarkSweepGC:设置并发收集器
- 垃圾回收统计信息
- -XX:+PrintGC
- -XX:+PrintGCDetails
- -XX:+PrintGCTimeStamps
- -Xloggc:filename
- 并行收集器设置
- -XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
- -XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
- -XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为1/(1+n)
- 并发收集器设置
- -XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
- -XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使用的CPU数。并行收集线程数。
- 堆设置
四、调优总结
- 年轻代大小选择
- 响应时间优先的应用：尽可能设大，直到接近系统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对象。
- 吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可以并行进行，一般适合8CPU以上的应用。
- 年老代大小选择
- 响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：
- 并发垃圾收集信息
- 持久代并发收集次数
- 传统GC信息
- 花在年轻代和年老代回收上的时间比例
- 吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。
- 响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较长的收集时间。最优化的方案，一般需要参考以下数据获得：
- 较小堆引起的碎片问题
因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：- -XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
- -XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full GC后，对年老代进行压缩
参考资料：
性能调优思路 http://www.voidcn.com/blog/bigtree_3721/article/p-5786972.html
linux下性能监控命令 http://linuxtools-rst.readthedocs.io/zh_CN/latest/advance/index.html
关于JVM CPU资源占用过高的问题排查 http://my.oschina.net/shipley/blog/520062
java排查工具 http://my.oschina.net/feichexia/blog/196575
jvm参数调优 http://www.cnblogs.com/java-zhao/archive/2016/02/08/5185092.html
java linux系统调优工具 https://www.ibm.com/developerworks/cn/java/j-lo-performance-tuning-practice/
gc优化的一些思路 http://mm.fancymore.com/reading/gc%E4%BC%98%E5%8C%96%E7%9A%84%E4%B8%80%E4%BA%9B%E6%80%9D%E8%B7%AF.html
性能优化的思路和步骤 http://www.uml.org.cn/j2ee/201602013.asp
性能调优攻略 http://coolshell.cn/articles/7490.html
JVM性能调优入门 http://www.jianshu.com/p/c6a04c88900a
JVM性能调优 http://blog.csdn.net/chen77716/article/details/5695893
Tomcat性能优化 https://yq.aliyun.com/articles/38861?utm_campaign=wenzhang&utm_medium=article&utm_source=QQ-qun&2017323&utm_content=m_14698
浙公网安备 33010602011771号