Java性能调优

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消耗严重的缘由主要是多个线程在写进行大量的数据到同一文件，致使文件很快变得很大，从而写入速度愈来愈慢，并形成各线程激烈争抢文件锁。

经常使用调优方法：

异步写文件

批量读写

限流

限制文件大小

 

内存消耗严重的解决方法

释放没必要要的引用：代码持有了不须要的对象引用，形成这些对象没法被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是典型实现，好处是能够明显提高读的性能，适合读多写少的场景， 但因为写操做每次都要复制一份对象，会消耗更多的内存。