使用Memory Analyzer tool(MAT)分析内存泄漏
http://www.blogjava.net/rosen/archive/2010/05/21/321575.html
http://www.blogjava.net/rosen/archive/2010/06/13/323522.html
前言的前言：本文是自2005年8月以來，首次在一個月之內發布三篇文章。謹以此文獻給這么多年始終不濟的我。所謂少不入川，而今已非年少。北漂快兩年了，何時能回到故鄉，回去后又會怎樣，也許永遠是個未知……
?
前言
?
在平時工作過程中，有時會遇到OutOfMemoryError，我們知道遇到Error一般表明程序存在著嚴重問題，可能是災難性的。所以找出是什么原因造成OutOfMemoryError非常重要。現在向大家引薦Eclipse Memory Analyzer tool(MAT)，來化解我們遇到的難題。如未說明，本文均使用Java 5.0 on Windows XP SP3環境。
?
為什么用MAT
?
之前的觀點，我認為使用實時profiling/monitoring之類的工具，用一種非常實時的方式來分析哪里存在內存泄漏是很正確的。年初使用了某profiler工具測試消息中間件中存在的內存泄漏，發現在吞吐量很高的時候profiler工具自己也無法響應，這讓人很頭痛。后來了解到這樣的工具本身就要消耗性能，且在某些條件下還發現不了泄漏。所以，分析離線數據就非常重要了，MAT正是這樣一款工具。
?
為何會內存溢出
?
我們知道JVM根據generation(代)來進行GC，根據下圖所示，一共被分為young generation(年輕代)、tenured generation(老年代)、permanent generation(永久代, perm gen)，perm gen（或稱Non-Heap 非堆）是個異類，稍后會講到。注意，heap空間不包括perm gen。
<!--[if !vml]-->
<!--[endif]-->
絕大多數的對象都在young generation被分配，也在young generation被收回，當young generation的空間被填滿，GC會進行minor collection(次回收)，這次回收不涉及到heap中的其他generation，minor collection根據weak generational hypothesis(弱年代假設)來假設young generation中大量的對象都是垃圾需要回收，minor collection的過程會非常快。young generation中未被回收的對象被轉移到tenured generation，然而tenured generation也會被填滿，最終觸發major collection(主回收)，這次回收針對整個heap，由于涉及到大量對象，所以比minor collection慢得多。
?
JVM有三種垃圾回收器，分別是throughput collector，用來做并行young generation回收，由參數-XX:+UseParallelGC啟動；concurrent low pause collector，用來做tenured generation并發回收，由參數-XX:+UseConcMarkSweepGC啟動；incremental low pause collector，可以認為是默認的垃圾回收器。不建議直接使用某種垃圾回收器，最好讓JVM自己決斷，除非自己有足夠的把握。
?
Heap中各generation空間是如何劃分的？通過JVM的-Xmx=n參數可指定最大heap空間，而-Xms=n則是指定最小heap空間。在JVM初始化的時候，如果最小heap空間小于最大heap空間的話，如上圖所示JVM會把未用到的空間標注為Virtual。除了這兩個參數還有-XX:MinHeapFreeRatio=n和 -XX:MaxHeapFreeRatio=n來分別控制最大、最小的剩余空間與活動對象之比例。在32位Solaris SPARC操作系統下，默認值如下，在32位windows xp下，默認值也差不多。
| 參數 | 默認值 |
| MinHeapFreeRatio | 40 |
| MaxHeapFreeRatio | 70 |
| -Xms | 3670k |
| -Xmx | 64m |
由于tenured generation的major collection較慢，所以tenured generation空間小于young generation的話，會造成頻繁的major collection，影響效率。Server JVM默認的young generation和tenured generation空間比例為1:2，也就是說young generation的eden和survivor空間之和是整個heap（當然不包括perm gen）的三分之一，該比例可以通過-XX:NewRatio=n參數來控制，而Client JVM默認的-XX:NewRatio是8。至于調整young generation空間大小的NewSize=n和MaxNewSize=n參數就不講了，請參考后面的資料。
?
young generation中幸存的對象被轉移到tenured generation，但不幸的是concurrent collector線程在這里進行major collection，而在回收任務結束前空間被耗盡了，這時將會發生Full Collections(Full GC)，整個應用程序都會停止下來直到回收完成。Full GC是高負載生產環境的噩夢……
?
現在來說說異類perm gen，它是JVM用來存儲無法在Java語言級描述的對象，這些對象分別是類和方法數據（與class loader有關）以及interned strings(字符串駐留)。一般32位OS下perm gen默認64m，可通過參數-XX:MaxPermSize=n指定，JVM Memory Structure一文說，對于這塊區域，沒有更詳細的文獻了，神秘。
?
回到問題“為何會內存溢出？”。
要回答這個問題又要引出另外一個話題，既什么樣的對象GC才會回收？當然是GC發現通過任何reference chain(引用鏈)無法訪問某個對象的時候，該對象即被回收。名詞GC Roots正是分析這一過程的起點，例如JVM自己確保了對象的可到達性(那么JVM就是GC Roots)，所以GC Roots就是這樣在內存中保持對象可到達性的，一旦不可到達，即被回收。通常GC Roots是一個在current thread(當前線程)的call stack(調用棧)上的對象（例如方法參數和局部變量），或者是線程自身或者是system class loader(系統類加載器)加載的類以及native code(本地代碼)保留的活動對象。所以GC Roots是分析對象為何還存活于內存中的利器。知道了什么樣的對象GC才會回收后，再來學習下對象引用都包含哪些吧。
?
從最強到最弱，不同的引用（可到達性）級別反映了對象的生命周期。
<!--[if !supportLists]-->l? <!--[endif]-->Strong Ref(強引用)：通常我們編寫的代碼都是Strong Ref，于此對應的是強可達性，只有去掉強可達，對象才被回收。
<!--[if !supportLists]-->l? <!--[endif]-->Soft Ref(軟引用)：對應軟可達性，只要有足夠的內存，就一直保持對象，直到發現內存吃緊且沒有Strong Ref時才回收對象。一般可用來實現緩存，通過java.lang.ref.SoftReference類實現。
<!--[if !supportLists]-->l? <!--[endif]-->Weak Ref(弱引用)：比Soft Ref更弱，當發現不存在Strong Ref時，立刻回收對象而不必等到內存吃緊的時候。通過java.lang.ref.WeakReference和java.util.WeakHashMap類實現。
<!--[if !supportLists]-->l? <!--[endif]-->Phantom Ref(虛引用)：根本不會在內存中保持任何對象，你只能使用Phantom Ref本身。一般用于在進入finalize()方法后進行特殊的清理過程，通過 java.lang.ref.PhantomReference實現。
?
有了上面的種種我相信很容易就能把heap和perm gen撐破了吧，是的利用Strong Ref，存儲大量數據，直到heap撐破；利用interned strings（或者class loader加載大量的類）把perm gen撐破。
?
關于shallow size、retained size
?
Shallow size就是對象本身占用內存的大小，不包含對其他對象的引用，也就是對象頭加成員變量（不是成員變量的值）的總和。在32位系統上，對象頭占用8字節，int占用4字節，不管成員變量（對象或數組）是否引用了其他對象（實例）或者賦值為null它始終占用4字節。故此，對于String對象實例來說，它有三個int成員（3*4=12字節）、一個char[]成員（1*4=4字節）以及一個對象頭（8字節），總共3*4 +1*4+8=24字節。根據這一原則，對String a=”rosen jiang”來說，實例a的shallow size也是24字節（很多人對此有爭議，請看官甄別并留言給我）。
?
Retained size是該對象自己的shallow size，加上從該對象能直接或間接訪問到對象的shallow size之和。換句話說，retained size是該對象被GC之后所能回收到內存的總和。為了更好的理解retained size，不妨看個例子。
?
把內存中的對象看成下圖中的節點，并且對象和對象之間互相引用。這里有一個特殊的節點GC Roots，正解！這就是reference chain的起點。
<!--[if !vml]--><!--[endif]--> <!--[if !vml]--><!--[endif]-->
從obj1入手，上圖中藍色節點代表僅僅只有通過obj1才能直接或間接訪問的對象。因為可以通過GC Roots訪問，所以左圖的obj3不是藍色節點；而在右圖卻是藍色，因為它已經被包含在retained集合內。
所以對于左圖，obj1的retained size是obj1、obj2、obj4的shallow size總和；右圖的retained size是obj1、obj2、obj3、obj4的shallow size總和。obj2的retained size可以通過相同的方式計算。
?
Heap Dump
?
heap dump是特定時間點，java進程的內存快照。有不同的格式來存儲這些數據，總的來說包含了快照被觸發時java對象和類在heap中的情況。由于快照只是一瞬間的事情，所以heap dump中無法包含一個對象在何時、何地（哪個方法中）被分配這樣的信息。
?
在不同平臺和不同java版本有不同的方式獲取heap dump，而MAT需要的是HPROF格式的heap dump二進制文件。想無需人工干預的話，要這樣配置JVM參數：-XX:-HeapDumpOnOutOfMemoryError，當錯誤發生時，會自動生成heap dump，在生產環境中，只有用這種方式。如果你想自己控制什么時候生成heap dump，在Windows+JDK6環境中可利用JConsole工具，而在Linux或者Mac OS X環境下均可使用JDK5、6自帶的jmap工具。當然，還可以配置JVM參數：-XX:+HeapDumpOnCtrlBreak，也就是在控制臺使用Ctrl+Break鍵來生成heap dump。由于我是windows+JDK5，所以選擇了-XX:-HeapDumpOnOutOfMemoryError這種方式，更多配置請參考MAT Wiki。
?
參考資料
?
MAT Wiki
Interned Strings
Strong,Soft,Weak,Phantom Reference
Tuning Garbage Collection with the 5.0 Java[tm] Virtual Machine
Permanent Generation
Understanding Weak References譯文
Java HotSpot VM Options
Shallow and retained sizes
JVM Memory Structure
GC roots
?
使用Memory Analyzer tool(MAT)分析內存泄漏（二） 前言的前言寫blog就是好，在大前提下可以想說什么寫什么，不像投稿那么字字斟酌。上周末回了趟成都辦事，所以本文來遲了。K117從達州經由達成線往成都方向走的時候，發現鐵路邊有條河，盡管我現在也不知道其名字，但已被其深深的陶醉。河很寬且水流平緩，河邊山丘森林密布，民房星星點點的分布在河邊，河里偶爾些小船。當時我就在想，在這里生活是多么的愜意，夏天還可以下去暢游一番，閑來無事也可垂釣。唉，越來越討厭北漂了。
前言
在使用Memory Analyzer tool(MAT)分析內存泄漏（一）中，我介紹了內存泄漏的前因后果。在本文中，將介紹MAT如何根據heap dump分析泄漏根源。由于測試范例可能過于簡單，很容易找出問題，但我期待借此舉一反三。
一開始不得不說說ClassLoader，本質上，它的工作就是把磁盤上的類文件讀入內存，然后調用java.lang.ClassLoader.defineClass方法告訴系統把內存鏡像處理成合法的字節碼。Java提供了抽象類ClassLoader，所有用戶自定義類裝載器都實例化自ClassLoader的子類。system class loader在沒有指定裝載器的情況下默認裝載用戶類，在Sun Java 1.5中既sun.misc.Launcher$AppClassLoader。更詳細的內容請參看下面的資料。
準備heap dump
請看下面的Pilot類，沒啥特殊的。
總結
以上是生活随笔為你收集整理的使用Memory Analyzer tool(MAT)分析内存泄漏的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： maven优化-repositories
- 下一篇： CVS服务器迁移记