3、性能調優

3.1JVM調優

3.1.1、代大小調優

① 避免新生代大小設置過小

1、避免頻繁進行minor GC;2、可能導致minor GC對象直接進入舊生代,占據舊生代空間,觸發FULL GC.

② 避免新生代設置過大

1、導致舊生代變小,可能導致FULL GC頻繁執行;2、導致minor GC的耗時大幅度增加.

③ 避免survivor space過小或者過大

④ 根據具體代碼合理設置新生代的存活周期.

3.2.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框架.

② 未充分使用內存

數據庫緩存、耗時資源緩存(數據庫連接的創建、網絡連接的創建等)、頁面片段的緩存等.

結束語：從純粹的軟件角度調優來講,充分而不過分的使用硬件資源,合理調整JVM以及合理使用JDK包是調優的三大有效原則,調優沒有“銀彈”.結合系統現狀和多嘗試不同的調優策略是找到合適調優辦法的唯一途徑.