一、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。我們考慮用下面幾種工具打開該文件：
- Visual VM
- IBM HeapAnalyzer
- 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 的不同選擇，線程池有完全不同的行爲：
-
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 就足用。理論上，在內存不變的情況下，減少每個線程的堆棧，可以產生更多的線程，但這實際上還受限於操作系統。
案例分析：
|
請看一下一個時間的 Java 參數配置：（服務器：Linux 64Bit，8Core×16G） JAVAOPTS=“$JAVAOPTS -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 基本不發生，或隔很長很長的時間才發生一次； |
調優方法
一切都是爲了這一步，調優，在調優之前，我們需要記住下面的原則：
1、多數的 Java 應用不需要在服務器上進行 GC 優化；
2、多數導致 GC 問題的 Java 應用，都不是因爲我們參數設置錯誤，而是代碼問題；
3、在應用上線之前，先考慮將機器的 JVM 參數設置到最優（最適合）；
4、減少創建對象的數量；
5、減少使用全局變量和大對象；
6、GC 優化是到最後不得已才採用的手段；
7、在實際使用中，分析 GC 情況優化代碼比優化 GC 參數要多得多；
GC 優化的目的有兩個（http://www.360doc.com/content/13/0305/10/15643_269388816.shtml）：
1、將轉移到老年代的對象數量降低到最小；
2、減少 full GC 的執行時間；
爲了達到上面的目的，一般地，你需要做的事情有：
1、減少使用全局變量和大對象；
2、調整新生代的大小到最合適；
3、設置老年代的大小爲最合適；
4、選擇合適的 GC 收集器；
在上面的 4 條方法中，用了幾個“合適”，那究竟什麼纔算合適，一般的，請參考上面“收集器搭配”和“啓動內存分配”兩節中的建議。但這些建議不是萬能的，需要根據您的機器和應用情況進行發展和變化，實際操作中，可以將兩臺機器分別設置成不同的 GC 參數，並且進行對比，選用那些確實提高了性能或減少了 GC 時間的參數。
真正熟練的使用 GC 調優，是建立在多次進行 GC 監控和調優的實戰經驗上的，進行監控和調優的一般步驟爲：
1，監控 GC 的狀態
使用各種 JVM 工具，查看當前日誌，分析當前 JVM 參數設置，並且分析當前堆內存快照和 gc 日誌，根據實際的各區域內存劃分和 GC 執行時間，覺得是否進行優化；
2，分析結果，判斷是否需要優化
如果各項參數設置合理，系統沒有超時日誌出現，GC 頻率不高，GC 耗時不高，那麼沒有必要進行 GC 優化；如果 GC 時間超過 1-3 秒，或者頻繁 GC，則必須優化；
注：如果滿足下面的指標，則一般不需要進行 GC：
Minor GC 執行時間不到 50ms；
Minor GC 執行不頻繁，約 10 秒一次；
Full GC 執行時間不到 1s；
Full GC 執行頻率不算頻繁，不低於 10 分鐘 1 次；
3，調整 GC 類型和內存分配
如果內存分配過大或過小，或者採用的 GC 收集器比較慢，則應該優先調整這些參數，並且先找 1 臺或幾臺機器進行 beta，然後比較優化過的機器和沒有優化的機器的性能對比，並有針對性的做出最後選擇；
4，不斷的分析和調整
通過不斷的試驗和試錯，分析並找到最合適的參數
5，全面應用參數
如果找到了最合適的參數，則將這些參數應用到所有服務器，並進行後續跟蹤。
調優實例
實例 1：GC 爲了釋放很小的空間卻耗費了太多的時間，其原因一般有兩個：1，堆太小，2，有死循環或大對象；
實例 2：（http://www.360doc.com/content/13/0305/10/15643_269388816.shtml）
一個服務系統，經常出現卡頓，分析原因，發現 Full GC 時間太長：
jstat -gcutil:
| S0 | S1 | E | O | P | YGC | YGCT | FGC | FGCT | GCT |
| 12.16 | 0.00 | 5.18 | 63.78 | 20.32 | 54 | 2.047 | 5 | 6.946 | 8.993 |
分析上面的數據，發現 Young GC 執行了 54 次，耗時 2.047 秒，每次 Young GC 耗時 37ms，在正常範圍，而 Full GC 執行了 5 次，耗時 6.946 秒，每次平均 1.389s，數據顯示出來的問題是：Full GC 耗時較長，分析該系統的數據發現，NewRatio=9，也就是說，新生代和老生代大小之比爲 1:9，這就是問題的原因：
1，新生代太小，導致對象提前進入老年代，觸發老年代發生 Full GC；
2，老年代較大，進行 Full GC 時耗時較大；
優化的方法是調整 NewRatio 的值，調整到 4，發現 Full GC 沒有再發生，只有 Young GC 在執行。這就是把對象控制在新生代就清理掉，沒有進入老年代（這種做法對一些應用是很有用的，但並不是對所有應用都要這麼做）