3、性能调优

3.1JVM调优

3.1.1、代大小调优            ① 避免新生代大小设置过小

1、避免频繁进行minor GC；

2、可能导致minor GC对象直接进入旧生代，占据旧生代空间，触发FULL GC。          

  ②避免新生代设置过大

1、导致旧生代变小，可能导致FULL GC频繁执行；

2、导致minor GC的耗时大幅度增加。          

  ③避免survivor space过小或者过大                       

 ④根据具体代码合理设置新生代的存活周期。

3.1.1、GC策略调优串行GC性能太差，因此实际应用时主要是应用并行和并发GC，大部分Web应用在处理请求时设置了一个最大可同时处理的请求数，当超出此请求数时，会将之后的请求放             入等待队列中，而这个等待队列也限制了大小。当等待队列满了后，仍然有请求进入，那么这些请求将丢弃，所有的请求又都是有超时限制度。在这种情况下如果触发了FULL GC造成应用暂停时间较长的FULL GC，则有可能等这次FULL GC之后，应用中很多请求就超时或者被丢弃了。从上面可以看出，Web应用非常需要一个对应用造成暂停时间较短的GC，再加上大部分Web应用的瓶颈都不在CPU上。因此对于Web应用而言，在G1还不够成熟的情况下，CMS GC是不错的选择。  

  3.2、程序调优

3.2.1、CPU us高的解决方法        

    ① 执行线程无任何挂起动作，且一直运行，导致CPU没有机会去调度执行其他的线程，造成线程饿死的现象。解决：对这种线程的动作增加Thread.sleep(int)，以释放CPU的执行权，降低CPU的消耗。原理：以损失单次执行性能为代价，但由于降低了CPU消耗，在多线程的情况下，反而提高了平均性能。           

 ② 状态扫描。如：某线程要等其他线程改变了值才可以继续执行。解决：改为采用wait/notify机制。         

   ③循环次数过多、正则、计算等造成CPU us过高的情况。结合业务需求进行调优。code review是王道。       

     ④频繁GC造成us高的情况，通过JVM调优或程序调优，降低GC的执行次数。      

  3.2.2、CPU sy高的解决方法       

     ① 线程运行状态经常切换解决：减少线程数，且使用线程池                      

  ② 线程之间锁竞争激烈解决：尽可能降低锁的竞争。

1、使用并发包中的类（java.util.concurrent.*）

2、使用Treiber算法

3、使用Michael-Scott非阻塞队列算法（ConcurrentLinkedQueue就是典型的该算法的非阻塞队列）

4、通常没必要对整个方法加锁，只对需要控制资源的地方做加锁操作。

5、拆分锁，把独占锁拆分为多把锁，如：ConcurrentHashMap。很大程度上可以提高读写速度。

6、去除读写操作的互斥锁            

③较多网络IO操作或者确实需要一些锁竞争机制（如数据库连接池），但为了能够支持高的并发量，在Java应用中又只能借助更多的线程来支撑。解决：采用协程（Coroutine）来支持更高的并发量，避免并发量上涨之后造成CPU sy消耗严重、系统load迅速上涨和系统性能下降。Java中目前主要可用于实现协程的框架为Kilim，早使用Kilim执行一项任务，并不创建Thread，而是采用Task。

3.3、文件IO消耗严重的解决方法从程序角度看，造成文件IO消耗严重的原因主要是多个线程在写大量的数据到同一文件。导致文件很快变大。从而写入速度越来越慢，并造成各线程激烈争抢文件锁，对于这种情况解决方法：

1、异步写入文件；

2、批量读写；

3、限流；

4、限制文件大小；

5、尽可能采用缓冲区等方式来读取文件内容   

 3.4、网络IO消耗严重的解决方法从程序角度而言，造成网络IO消耗严重的主要原因是同时需要发送或接受的包太多。可采用限流。限流通常是限制发送packet的频率，从而在网络IO消耗可接受的情况下来发送packet。

3.5、内存消耗严重的情况

1、对JVM调优；

2、代码调优；代码调优的方式：           

 ① 释放不必要的引用。如使用ThreadLocal，由于线程复用，ThreadLocal中存放的对象如未主动释放的话，不会被GC。应该在执行完毕执行ThreadLocal.set把对象清除，避免此有不必要的对象引用。           

 ② 使用对象缓存池（享元模式）            

③采用合理的缓存失效算法（FIFO、LRU、LFU等）当缓存池达到最大容量后，如果再加入新对象时采用FIFO、LRU、LFU等失效算法。            

④对于占据内存但又不是必须存在的对象使用SoftReference、WeakReference的方式进行缓存。SoftReference在内存不够用的情况进行回收；WeakReference在FULL GC的情况下进行回收。

3.6、对于资源消耗不多，但程序执行慢的情况

3.6.1、锁竞争激烈—见3.2.2②        

3.6.2、未充分利用硬件资源。            

① 未充分利用CPU启动多线程，但是单线程演变为多线程要加锁，如：单线程计算，拆分为多线程分别计算，最后合并结果                 如：JDK7的fork-join框架。          

②未充分使用内存数据库缓存、耗时资源缓存（数据库连接的创建、网络连接的创建等）、页面片段的缓存等。