一、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。

二、記憶體洩漏及解決方法

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

• 每次垃圾回收的時間越來越長，由之前的10ms延長到50ms左右，FullGC的時間也有之前的0.5s延長到4、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到年老代

三、效能調優

 除了上述記憶體洩漏外，我們還發現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的不同選擇，執行緒池有完全不同的行為：

• 一個無容量的等待佇列，一個執行緒的insert操作必須等待另一執行緒的remove操作，採用這個Queue執行緒池將會為每個任務分配一個新執行緒
• 無界佇列，採用該Queue，執行緒池將忽略 maximumPoolSize引數，僅用corePoolSize的執行緒處理所有的任務，未處理的任務便在LinkedBlockingQueue中排隊
• 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.程式演算法調優：本次不作為重點

參考資料：