JVM性能調優的一點收集

最近因項目存在內存泄漏，故進行大規模的JVM性能調優 ， 現把經驗作一記錄。

1、JVM內存模型及垃圾收集算法

 1.根據Java虛擬機規範，JVM將內存劃分爲：

• New（年輕代）

• Tenured（年老代）

• 永久代（Perm）

  其中New和Tenured屬於堆內存，堆內存會從JVM啓動參數（-Xmx:3G）指定的內存中分配，Perm不屬於堆內存，有虛擬機直接分配，但能夠經過-XX:PermSize -XX:MaxPermSize 等參數調整其大小。

 

• 年輕代（New）：年輕代用來存放JVM剛分配的Java對象

• 年老代（Tenured)：年輕代中通過垃圾回收沒有回收掉的對象將被Copy到年老代

• 永久代（Perm）：永久代存放Class、Method元信息，其大小跟項目的規模、類、方法的量有關，通常設置爲128M就足夠，設置原則是預留30%的空間。

New又分爲幾個部分：

• Eden：Eden用來存放JVM剛分配的對象

• Survivor1

• Survivro2：兩個Survivor空間同樣大，當Eden中的對象通過垃圾回收沒有被回收掉時，會在兩個Survivor之間來回Copy，當知足某個條件，好比Copy次數，就會被Copy到Tenured。顯然，Survivor只是增長了對象在年輕代中的逗留時間，增長了被垃圾回收的可能性。

 2.垃圾回收算法

  垃圾回收算法能夠分爲三類，都基於標記-清除（複製）算法：

• Serial算法（單線程）

• 並行算法

• 併發算法

  JVM會根據機器的硬件配置對每一個內存代選擇適合的回收算法，好比，若是機器多於1個核，會對年輕代選擇並行算法，關於選擇細節請參考JVM調優文檔。

  稍微解釋下的是，並行算法是用多線程進行垃圾回收，回收期間會暫停程序的執行，而併發算法，也是多線程回收，但期間不中止應用執行。因此，併發算法適用於交互性高的一些程序。通過觀察，併發算法會減小年輕代的大小，其實就是使用了一個大的年老代，這反過來跟並行算法相比吞吐量相對較低。

  還有一個問題是，垃圾回收動做什麼時候執行？

• 當年輕代內存滿時，會引起一次普通GC，該GC僅回收年輕代。須要強調的時，年輕代盡是指Eden代滿，Survivor滿不會引起GC

• 當年老代滿時會引起Full GC，Full GC將會同時回收年輕代、年老代

• 當永久代滿時也會引起Full GC，會致使Class、Method元信息的卸載

  另外一個問題是，什麼時候會拋出OutOfMemoryException，並非內存被耗空的時候才拋出

• JVM98%的時間都花費在內存回收

• 每次回收的內存小於2%

  知足這兩個條件將觸發OutOfMemoryException，這將會留給系統一個微小的間隙以作一些Down以前的操做，好比手動打印Heap Dump。

 

2、內存泄漏及解決方法

 1.系統崩潰前的一些現象：

• 每次垃圾回收的時間愈來愈長，由以前的10ms延長到50ms左右，FullGC的時間也有以前的0.5s延長到四、5s

• FullGC的次數愈來愈多，最頻繁時隔不到1分鐘就進行一次FullGC

• 年老代的內存愈來愈大而且每次FullGC後年老代沒有內存被釋放

 以後系統會沒法響應新的請求，逐漸到達OutOfMemoryError的臨界值。

 

 2.生成堆的dump文件

 經過JMX的MBean生成當前的Heap信息，大小爲一個3G（整個堆的大小）的hprof文件，若是沒有啓動JMX能夠經過Java的jmap命令來生成該文件。

 

 3.分析dump文件

 下面要考慮的是如何打開這個3G的堆信息文件，顯然通常的Window系統沒有這麼大的內存，必須藉助高配置的Linux。固然咱們能夠藉助X-Window把Linux上的圖形導入到Window。咱們考慮用下面幾種工具打開該文件：

1. Visual VM

2. IBM HeapAnalyzer

3. JDK 自帶的Hprof工具

 使用這些工具時爲了確保加載速度，建議設置最大內存爲6G。使用後發現，這些工具都沒法直觀地觀察到內存泄漏，Visual VM雖能觀察到對象大小，但看不到調用堆棧；HeapAnalyzer雖然能看到調用堆棧，卻沒法正確打開一個3G的文件。所以，咱們又選用了Eclipse專門的靜態內存分析工具：Mat。

 

 4.分析內存泄漏

 經過Mat咱們能清楚地看到，哪些對象被懷疑爲內存泄漏，哪些對象佔的空間最大及對象的調用關係。針對本案，在ThreadLocal中有不少的JbpmContext實例，通過調查是JBPM的Context沒有關閉所致。

 另，經過Mat或JMX咱們還能夠分析線程狀態，能夠觀察到線程被阻塞在哪一個對象上，從而判斷系統的瓶頸。

 

 5.迴歸問題

   Q：爲何崩潰前垃圾回收的時間愈來愈長？

   A:根據內存模型和垃圾回收算法，垃圾回收分兩部分：內存標記、清除（複製），標記部分只要內存大小固定時間是不變的，變的是複製部分，由於每次垃圾回收都有一些回收不掉的內存，因此增長了複製量，致使時間延長。因此，垃圾回收的時間也能夠做爲判斷內存泄漏的依據

   Q：爲何Full GC的次數愈來愈多？

   A：所以內存的積累，逐漸耗盡了年老代的內存，致使新對象分配沒有更多的空間，從而致使頻繁的垃圾回收

   Q:爲何年老代佔用的內存愈來愈大？

   A:由於年輕代的內存沒法被回收，愈來愈多地被Copy到年老代

3、性能調優

 除了上述內存泄漏外，咱們還發現CPU長期不足3%，系統吞吐量不夠，針對8core×16G、64bit的Linux服務器來講，是嚴重的資源浪費。

 在CPU負載不足的同時，偶爾會有用戶反映請求的時間過長，咱們意識到必須對程序及JVM進行調優。從如下幾個方面進行：

• 線程池：解決用戶響應時間長的問題

• 鏈接池

• JVM啓動參數：調整各代的內存比例和垃圾回收算法，提升吞吐量

• 程序算法：改進程序邏輯算法提升性能

  1.Java線程池（java.util.concurrent.ThreadPoolExecutor）

    大多數JVM6上的應用採用的線程池都是JDK自帶的線程池，之因此把成熟的Java線程池進行羅嗦說明，是由於該線程池的行爲與咱們想象的有點出入。Java線程池有幾個重要的配置參數：

• corePoolSize：核心線程數（最新線程數）

• maximumPoolSize：最大線程數，超過這個數量的任務會被拒絕，用戶能夠經過RejectedExecutionHandler接口自定義處理方式

• keepAliveTime：線程保持活動的時間

• workQueue：工做隊列，存放執行的任務

    Java線程池須要傳入一個Queue參數（workQueue）用來存放執行的任務，而對Queue的不一樣選擇，線程池有徹底不一樣的行爲：

• SynchronousQueue： 一個無容量的等待隊列，一個線程的insert操做必須等待另外一線程的remove操做，採用這個Queue線程池將會爲每一個任務分配一個新線程

• LinkedBlockingQueue ： 無界隊列，採用該Queue，線程池將忽略 maximumPoolSize參數，僅用corePoolSize的線程處理全部的任務，未處理的任務便在LinkedBlockingQueue中排隊

• ArrayBlockingQueue： 有界隊列，在有界隊列和 maximumPoolSize的做用下，程序將很難被調優：更大的Queue和小的maximumPoolSize將致使CPU的低負載；小的Queue和大的池，Queue就沒起動應有的做用。

    其實咱們的要求很簡單，但願線程池能跟鏈接池同樣，能設置最小線程數、最大線程數，當最小數<任務<最大數時，應該分配新的線程處理；當任務>最大數時，應該等待有空閒線程再處理該任務。

    但線程池的設計思路是，任務應該放到Queue中，當Queue放不下時再考慮用新線程處理，若是Queue滿且沒法派生新線程，就拒絕該任務。設計致使「先放等執行」、「放不下再執行」、「拒毫不等待」。因此，根據不一樣的Queue參數，要提升吞吐量不能一味地增大maximumPoolSize。

    固然，要達到咱們的目標，必須對線程池進行必定的封裝，幸運的是ThreadPoolExecutor中留了足夠的自定義接口以幫助咱們達到目標。咱們封裝的方式是：

• 以SynchronousQueue做爲參數，使maximumPoolSize發揮做用，以防止線程被無限制的分配，同時能夠經過提升maximumPoolSize來提升系統吞吐量

• 自定義一個RejectedExecutionHandler，當線程數超過maximumPoolSize時進行處理，處理方式爲隔一段時間檢查線程池是否能夠執行新Task，若是能夠把拒絕的Task從新放入到線程池，檢查的時間依賴keepAliveTime的大小。

  2.鏈接池（org.apache.commons.dbcp.BasicDataSource）

    在使用org.apache.commons.dbcp.BasicDataSource的時候，由於以前採用了默認配置，因此當訪問量大時，經過JMX觀察到不少Tomcat線程都阻塞在BasicDataSource使用的Apache ObjectPool的鎖上，直接緣由當時是由於BasicDataSource鏈接池的最大鏈接數設置的過小，默認的BasicDataSource配置，僅使用8個最大鏈接。

    我還觀察到一個問題，當較長的時間不訪問系統，好比2天，DB上的Mysql會斷掉因此的鏈接，致使鏈接池中緩存的鏈接不能用。爲了解決這些問題，咱們充分研究了BasicDataSource，發現了一些優化的點：

• Mysql默認支持100個連接，因此每一個鏈接池的配置要根據集羣中的機器數進行，若有2臺服務器，可每一個設置爲60

• initialSize：參數是一直打開的鏈接數

• minEvictableIdleTimeMillis：該參數設置每一個鏈接的空閒時間，超過這個時間鏈接將被關閉

• timeBetweenEvictionRunsMillis：後臺線程的運行週期，用來檢測過時鏈接

• maxActive：最大能分配的鏈接數

• maxIdle：最大空閒數，當鏈接使用完畢後發現鏈接數大於maxIdle，鏈接將被直接關閉。只有initialSize < x < maxIdle的鏈接將被按期檢測是否超期。這個參數主要用來在峯值訪問時提升吞吐量。

• initialSize是如何保持的？通過研究代碼發現，BasicDataSource會關閉全部超期的鏈接，而後再打開initialSize數量的鏈接，這個特性與minEvictableIdleTimeMillis、timeBetweenEvictionRunsMillis一塊兒保證了全部超期的initialSize鏈接都會被從新鏈接，從而避免了Mysql長時間無動做會斷掉鏈接的問題。

  3.JVM參數

    在JVM啓動參數中，能夠設置跟內存、垃圾回收相關的一些參數設置，默認狀況不作任何設置JVM會工做的很好，但對一些配置很好的Server和具體的應用必須仔細調優才能得到最佳性能。經過設置咱們但願達到一些目標：

• GC的時間足夠的小

• GC的次數足夠的少

• 發生Full GC的週期足夠的長

  前兩個目前是相悖的，要想GC時間小必需要一個更小的堆，要保證GC次數足夠少，必須保證一個更大的堆，咱們只能取其平衡。

   （1）針對JVM堆的設置通常，能夠經過-Xms -Xmx限定其最小、最大值，爲了防止垃圾收集器在最小、最大之間收縮堆而產生額外的時間，咱們一般把最大、最小設置爲相同的值
   （2）年輕代和年老代將根據默認的比例（1：2）分配堆內存，能夠經過調整兩者之間的比率NewRadio來調整兩者之間的大小，也能夠針對回收代，好比年輕代，經過 -XX:newSize -XX:MaxNewSize來設置其絕對大小。一樣，爲了防止年輕代的堆收縮，咱們一般會把-XX:newSize -XX:MaxNewSize設置爲一樣大小

   （3）年輕代和年老代設置多大才算合理？這個我問題毫無疑問是沒有答案的，不然也就不會有調優。咱們觀察一下兩者大小變化有哪些影響

• 更大的年輕代必然致使更小的年老代，大的年輕代會延長普通GC的週期，但會增長每次GC的時間；小的年老代會致使更頻繁的Full GC

• 更小的年輕代必然致使更大年老代，小的年輕代會致使普通GC很頻繁，但每次的GC時間會更短；大的年老代會減小Full GC的頻率

• 如何選擇應該依賴應用程序對象生命週期的分佈狀況：若是應用存在大量的臨時對象，應該選擇更大的年輕代；若是存在相對較多的持久對象，年老代應該適當增大。但不少應用都沒有這樣明顯的特性，在抉擇時應該根據如下兩點：（A）本着Full GC儘可能少的原則，讓年老代儘可能緩存經常使用對象，JVM的默認比例1：2也是這個道理 （B）經過觀察應用一段時間，看其餘在峯值時年老代會佔多少內存，在不影響Full GC的前提下，根據實際狀況加大年輕代，好比能夠把比例控制在1：1。但應該給年老代至少預留1/3的增加空間

  （4）在配置較好的機器上（好比多核、大內存），能夠爲年老代選擇並行收集算法： -XX:+UseParallelOldGC ，默認爲Serial收集

  （5）線程堆棧的設置：每一個線程默認會開啓1M的堆棧，用於存放棧幀、調用參數、局部變量等，對大多數應用而言這個默認值太了，通常256K就足用。理論上，在內存不變的狀況下，減小每一個線程的堆棧，能夠產生更多的線程，但這實際上還受限於操做系統。

  （4）能夠經過下面的參數打Heap Dump信息

• -XX:HeapDumpPath

• -XX:+PrintGCDetails

• -XX:+PrintGCTimeStamps

• -Xloggc:/usr/aaa/dump/heap_trace.txt

    經過下面參數能夠控制OutOfMemoryError時打印堆的信息

• -XX:+HeapDumpOnOutOfMemoryError

 請看一下一個時間的Java參數配置：（服務器：Linux 64Bit，8Core×16G）

 

 JAVA_OPTS="$JAVA_OPTS -server -Xms3G -Xmx3G -Xss256k -XX:PermSize=128m -XX:MaxPermSize=128m -XX:+UseParallelOldGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/aaa/dump -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:/usr/aaa/dump/heap_trace.txt -XX:NewSize=1G -XX:MaxNewSize=1G"

通過觀察該配置很是穩定，每次普通GC的時間在10ms左右，Full GC基本不發生，或隔很長很長的時間才發生一次

經過分析dump文件能夠發現，每一個1小時都會發生一次Full GC，通過多方求證，只要在JVM中開啓了JMX服務，JMX將會1小時執行一次Full GC以清除引用，關於這點請參考附件文檔。

 4.程序算法調優：本次不做爲重點

 

參考資料：

http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html