性能优化总结
- 根据现象进行分析
性能瓶颈的表象：资源消耗过多、外部处理系统的性能不足、资源消耗不多但程序的响应速度却仍达不到要求。
-
- 内存高
分析内存：系统的内存消耗过多往往有以下几种原因：
- 频繁创建Java对象，如：数据库查询时，没分页，导致查出表中所有记录；
- 存在大对象，如：读取文件时，不是边读边写而是先读到一个byte数组，这样如果读取的文件时50M则仅此一项操作就会占有JVM50M内存。
- 存在内存泄漏，导致已不被使用的对象不被GC回收，从而随着系统使用时间的增长，内存不断受到解压，最终OutOfMemory。
- 内存消耗分析（-Xms和-Xmx设为相同的值，避免运行期JVM堆内存要不断申请内存）
对于Java应用，内存的消耗主要在Java堆内存上，只有创建线程和使用Direct ByteBuffer才会操作JVM堆外的内存。
JVM内存消耗过多会导致GC执行频繁，CPU消耗增加，应用线程的执行速度严重下降，甚至造成OutOfMemoryError，最终导致Java进程退出。
- JVM堆外的内存：swap的消耗、物理内存的消耗、JVM内存的消耗。
调优方案：JVM调优（最关键参数为：-Xms -Xmx -Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold）
1） 代大小调优：避免新生代大小设置过小、避免新生代大小设置过大、避免Survivor设置过小或过大、合理设置新生代存活周期。
-Xmn 调整新生代大小，新生代越大通常也意味着更多对象会在minor GC阶段被回收，但可能有可能造成旧生代大小，造成频繁触发Full GC，甚至是OutOfMemoryError。
-XX:SurvivorRatio调整Eden区与Survivor区的大小，Eden 区越大通常也意味着minor GC发生频率越低，但可能有可能造成Survivor区太小，导致对象minor GC后就直接进入旧生代，从而更频繁触发Full GC。
2）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状况。
3）出内存管理以外的其他方面的调优参数：-XX:CompileThreshold、-XX:+UseFastAccessorMethods、 -XX:+UseBaiasedLocking。
充分利用内存：数据的缓存、耗时资源的缓存（数据库连接创建、网络连接的创建等）、页面片段的缓存。毕竟内存的读取肯定远快于硬盘、网络的读取， 在内存消耗可接受、GC频率、以及系统结构（例如集群环境可能会带来缓存的同步）可接受情况下，应充分利用内存来缓存数据，提升系统的性能。
内存消耗严重的解决方法
1） 释放不必要的引用：代码持有了不需要的对象引用，造成这些对象无法被GC，从而占据了JVM堆内存。（使用ThreadLocal：注意在线程内动作执行完毕时，需执行ThreadLocal.set把对象清除，避免持有不必要的对象引用）
2） 使用对象缓存池：创建对象要消耗一定的CPU以及内存，使用对象缓存池一定程度上可降低JVM堆内存的使用。
3） 采用合理的缓存失效算法：如果放入太多对象在缓存池中，反而会造成内存的严重消耗， 同时由于缓存池一直对这些对象持有引用，从而造成Full GC增多，对于这种状况要合理控制缓存池的大小，避免缓存池的对象数量无限上涨。（经典的缓存失效算法来清除缓存池中的对象：FIFO、LRU、LFU等）
4） 合理使用SoftReference和WeekReference：SoftReference的对象会在内存不够用的时候回收，WeekReference的对象会在Full GC的时候回收。
分析步骤：
- 用TOP命令（或者用nmon）监控到JAVA程序占用内存特别高， 然后用jmap -heap pid命令查看内存使用情况（老年代，年轻代等各个区内存设置和内存使用）。然后用jmap -histo pid打印输出每个实例的内存使用。查看TOP20或者TOP30，可以分析出程序中消耗内存较多的实例。还可以用jmap -dump：live,file=a.map pid把java堆dump到本地进行分析，用jhat a.map命令通过html也没进行JAVA堆分析。
- 用top命令监控到JAVA程序内存比较高，用JVISUALVM对程序进行监控，并把堆DUMP下来，在jvisualvm中进行装载，装载后找到实例数最多或者占用内存较多的实例。然后根据这个实例一步步往下详细分析，找到实例中引用最频繁的字段。
- 程序内存占用比较高，可以用jstat -gcutil pid 1000 5查看到内存的yougn gc以及FULL GC的频率，消耗的时间。以及各个内存区所使用和分配的情况。根据各项指标进行内存的分析。还可以使用jstat -class pid查看加载的class数量，以及所占空间信息。
- jprofiler的memory views视图中监控内存使用情况。通过实例数量和实例所占内存大小进行分析。如果是内存泄露，可以对实例添加mark，程序运行一段时间后，进行GC，如果不进行垃圾回收，说明可能存在内存泄露问题。这时需要告诉开发把方法调用后，做置空操作。但是这个工具是十分消耗系统资源的。
- cpu高
CPU消耗分析：CPU主要用于中断、内核、用户进程的任务处理，优先级为中断>内核>用户进程。
- 上下文切换：
每个线程分配一定的执行时间，当到达执行时间、线程中有IO阻塞或高优先级线程要执行时，将切换执行的线程。在切换时要存储目前线程的执行状态，并恢复要执行的线程的状态。
对于Java应用，典型的是在进行文件IO操作、网络IO操作、锁等待、线程Sleep时，当前线程会进入阻塞或休眠状态，从而触发上下文切换，上下文切换过多会造成内核占据较多的CPU的使用。
- 运行队列：
每个CPU核都维护一个可运行的线程队列。系统的load主要由CPU的运行队列来决定。
运行队列值越大，就意味着线程会要消耗越长的时间才能执行完成。
- 利用率：
CPU在用户进程、内核、中断处理、IO等待、空闲，这五个部分使用百分比。
充分利用cpu: 在能并行处理的场景中未使用足够的线程（线程增加：CPU资源消耗可接受且不会带来激烈竞争锁的场景下）.
分析步骤：
- 用top命令监控到程序的CPU占用很高，于是用JVISUALVM的抽样器对程序的CPU进行抽样，抽样完成后，在抽样的快照里根据CPU时间进行降序排列，找到消耗CPU时间较长的方法。
- 用top命令查找到占用cpu最高的服务，然后用top命令1top -p pid-H单独对子进程进行监视。找到占用cpu最高的进程ID。要想找到哪段具体的代码占用了较多的CPU资源，可以用jstack打印栈信息到文件里面。然后用jtgrep脚本把脚本中进程号的java线程抓出来。
- 对程序加压一段时间后，程序CPU消耗逐渐增高，可以用jprofiler工具进行监控。在cpu views视图中对消耗CPU时间较长的方法进行逐步分析，查找到耗用cpu时间比较长的方法。
1.2.1程序调优方案
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过高，所以合理设置线程数非常关键。
1.2.2数据库调优方案
MySQL处在高负载环境下，磁盘IO读写过多，肯定会占用很多资源，必然CPU会占用过高。占用CPU过高，可以做如下考虑：
1.打开慢查询日志，查询是否是某个SQL语句占用过多资源，如果是的话，可以对SQL语句进行优化，比如优化 insert 语句、优化 group by 语句、优化 order by 语句、优化 join 语句等等；
2.考虑索引问题；
3.定期分析表，使用optimize table；show processlist;
4.优化数据库对象；
5.考虑是否是锁问题；
6.调整一些MySQL Server参数，比如key_buffer_size、table_cache、innodb_buffer_pool_size、innodb_log_file_size等等；
7.如果数据量过大，可以考虑使用MySQL集群或者搭建高可用环境。
调优细节：http://coolshell.cn/articles/1846.html
http://www.searchdatabase.com.cn/showcontent_76438.htm
-
- I/O高
- 文件IO消耗分析
Linux在操作文件时，将数据放入文件缓存区，直到内存不够或系统要释放内存给用户进程使用。所以通常情况下只有写文件和第一次读取文件时会产生真正的文件IO。
对于Java应用，造成文件IO消耗高主要是多个线程需要进行大量内容写入（例如频繁的日志写入）的动作、磁盘设备本身的处理速度慢、文件系统慢、操作的文件本身已经很大。
- 网络IO消耗分析
对于分布式Java应用，网卡中断是不是均衡分配到各CPU(cat/proc/interrupts查看)。
文件IO消耗严重的解决方法
从程序的角度而言，造成文件IO消耗严重的原因主要是多个线程在写进行大量的数据到同一文件，导致文件很快变得很大，从而写入速度越来越慢，并造成各线程激烈争抢文件锁。 调优方法：1）异步写文件 2）批量读写 3）限流 4）限制文件大小
从程序的角度而言，造成网络IO消耗严重的原因主要是同时需要发送或接收的包太多。 调优方法：限流，限流通常是限制发送packet的频率，从而在网络IO消耗可接受的情况下来发送packget。
-
- 程序响应慢
程序执行慢原因分析
- 锁竞争激烈：很多线程竞争互斥资源，但资源有限， 造成其他线程都处于等待状态。
- 未充分使用硬件资源：线程操作被串行化。
- 数据量增长：单表数据量太大（如1个亿）造成数据库读写速度大幅下降（操作此表）。
资源消耗不多但程序执行慢的情况的解决方法
1） 降低锁竞争： 多线多了，锁竞争的状况会比较明显，这时候线程很容易处于等待锁的状况，从而导致性能下降以及CPU sy上升。
2） 使用并发包中的类：大多数采用了lock-free、nonblocking算法。使用Treiber算法：基于CAS以及AtomicReference。使用Michael-Scott非阻塞队列算法：基于CAS以及AtomicReference，典型ConcurrentLindkedQueue。（基于CAS和AtomicReference来实现无阻塞是不错的选择，但值得注意的是，lock-free算法需不断的循环比较来保证资源的一致性的，对于冲突较多的应用场景而言，会带来更高的CPU消耗，因此不一定采用CAS实现无阻塞的就一定比采用lock方式的性能好。 还有一些无阻塞算法的改进：MCAS、WSTM等）
3） 尽可能少用锁：尽可能只对需要控制的资源做加锁操作（通常没有必要对整个方法加锁，尽可能让锁最小化，只对互斥及原子操作的地方加锁，加锁时尽可能以保护资源的最小化粒度为单位--如只对需要保护的资源加锁而不是this）。
4） 拆分锁：独占锁拆分为多把锁（读写锁拆分、类似ConcurrentHashMap中默认拆分为16把锁），很多程度上能提高读写的性能，但需要注意在采用拆分锁后，全局性质的操作会变得比较复杂（如ConcurrentHashMap中size操作）。（拆分锁太多也会造成副作用，如CPU消耗明显增加）
5） 去除读写操作的互斥：在修改时加锁，并复制对象进行修改，修改完毕后切换对象的引用，从而读取时则不加锁。这种称为CopyOnWrite，CopyOnWriteArrayList是典型实现，好处是可以明显提升读的性能，适合读多写少的场景， 但由于写操作每次都要复制一份对象，会消耗更多的内存。
分析步骤：
- 首先查看系统资源是不是使用正常，如果cpu比较高的话，可以查看sql语句，查看是不是存在union连接，是不是有索引，左右连接，iN等查询效率比较低的sql.如果是两个表进行联合查询，可用小表做驱动表，使性能得到提升。
- 查看是否有线程池满的现象，如果有，重启tomcat能暂时解决这个问题，将不用的连接释放，但是不能从根本上解决。需要验证数据库连接请求完成后，关闭这个请求连接。查看连接没有被释放的脚本：其中数据库连接是有tomcat发布地址。
declare cur_spid cursor
for
select spid from sysprocesses where ipaddr='172.16.7.8'
go
declare @spid Integer
open cur_spid
fetch cur_spid into @spid
while @@sqlstatus=0
begin
print '%1!' , @spid
dbcc traceon(3604)
dbcc sqltext(@spid )
fetch cur_spid into @spid
end
close cur_spid