前言的前言:本文是自2005年8月以來,首次在一個月之內(nèi)發(fā)布三篇文章。謹以此文獻給這么多年始終不濟的我。所謂少不入川,而今已非年少。北漂快兩年了,何時能回到故鄉(xiāng),回去后又會怎樣,也許永遠是個未知……
前言
在平時工作過程中,有時會遇到OutOfMemoryError,我們知道遇到Error一般表明程序存在著嚴重問題,可能是災難性的。所以找出是什么原因造成OutOfMemoryError非常重要。現(xiàn)在向大家引薦Eclipse Memory Analyzer tool(MAT),來化解我們遇到的難題。如未說明,本文均使用Java 5.0 on Windows XP SP3環(huán)境。
為什么用MAT
之前的觀點,我認為使用實時profiling/monitoring之類的工具,用一種非常實時的方式來分析哪里存在內(nèi)存泄漏是很正確的。年初使用了某profiler工具測試消息中間件中存在的內(nèi)存泄漏,發(fā)現(xiàn)在吞吐量很高的時候profiler工具自己也無法響應,這讓人很頭痛。后來了解到這樣的工具本身就要消耗性能,且在某些條件下還發(fā)現(xiàn)不了泄漏。所以,分析離線數(shù)據(jù)就非常重要了,MAT正是這樣一款工具。
為何會內(nèi)存溢出
我們知道JVM根據(jù)generation(代)來進行GC,根據(jù)下圖所示,一共被分為young generation(年輕代)、tenured generation(老年代)、permanent generation(永久代, perm gen),perm gen(或稱Non-Heap 非堆)是個異類,稍后會講到。注意,heap空間不包括perm gen。
絕大多數(shù)的對象都在young generation被分配,也在young generation被收回,當young generation的空間被填滿,GC會進行minor collection(次回收),這次回收不涉及到heap中的其他generation,minor collection根據(jù)weak generational hypothesis(弱年代假設)來假設young generation中大量的對象都是垃圾需要回收,minor collection的過程會非常快。young generation中未被回收的對象被轉(zhuǎn)移到tenured generation,然而tenured generation也會被填滿,最終觸發(fā)major collection(主回收),這次回收針對整個heap,由于涉及到大量對象,所以比minor collection慢得多。
JVM有三種垃圾回收器,分別是throughput collector,用來做并行young generation回收,由參數(shù)-XX:+UseParallelGC啟動;concurrent low pause collector,用來做tenured generation并發(fā)回收,由參數(shù)-XX:+UseConcMarkSweepGC啟動;incremental low pause collector,可以認為是默認的垃圾回收器。不建議直接使用某種垃圾回收器,最好讓JVM自己決斷,除非自己有足夠的把握。
Heap中各generation空間是如何劃分的?通過JVM的-Xmx=n參數(shù)可指定最大heap空間,而-Xms=n則是指定最小heap空間。在JVM初始化的時候,如果最小heap空間小于最大heap空間的話,如上圖所示JVM會把未用到的空間標注為Virtual。除了這兩個參數(shù)還有-XX:MinHeapFreeRatio=n和 -XX:MaxHeapFreeRatio=n來分別控制最大、最小的剩余空間與活動對象之比例。在32位Solaris SPARC操作系統(tǒng)下,默認值如下,在32位windows xp下,默認值也差不多。
-Xms=n
則是指定
參數(shù)
默認值
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參數(shù)來控制,而Client JVM默認的-XX:NewRatio是8。至于調(diào)整young generation空間大小的NewSize=n和MaxNewSize=n參數(shù)就不講了,請參考后面的資料。
young generation中幸存的對象被轉(zhuǎn)移到tenured generation,但不幸的是concurrent collector線程在這里進行major collection,而在回收任務結(jié)束前空間被耗盡了,這時將會發(fā)生Full Collections(Full GC),整個應用程序都會停止下來直到回收完成。Full GC是高負載生產(chǎn)環(huán)境的噩夢……
現(xiàn)在來說說異類perm gen,它是JVM用來存儲無法在Java語言級描述的對象,這些對象分別是類和方法數(shù)據(jù)(與class loader有關(guān))以及interned strings(字符串駐留)。一般32位OS下perm gen默認64m,可通過參數(shù)-XX:MaxPermSize=n指定,JVM Memory Structure一文說,對于這塊區(qū)域,沒有更詳細的文獻了,神秘。
回到問題“為何會內(nèi)存溢出?”。
要回答這個問題又要引出另外一個話題,既什么樣的對象GC才會回收?當然是GC發(fā)現(xiàn)通過任何reference chain(引用鏈)無法訪問某個對象的時候,該對象即被回收。名詞GC Roots正是分析這一過程的起點,例如JVM自己確保了對象的可到達性(那么JVM就是GC Roots),所以GC Roots就是這樣在內(nèi)存中保持對象可到達性的,一旦不可到達,即被回收。通常GC Roots是一個在current thread(當前線程)的call stack(調(diào)用棧)上的對象(例如方法參數(shù)和局部變量),或者是線程自身或者是system class loader(系統(tǒng)類加載器)加載的類以及native code(本地代碼)保留的活動對象。所以GC Roots是分析對象為何還存活于內(nèi)存中的利器。知道了什么樣的對象GC才會回收后,再來學習下對象引用都包含哪些吧。
從最強到最弱,不同的引用(可到達性)級別反映了對象的生命周期。
l Strong Ref(強引用):通常我們編寫的代碼都是Strong Ref,于此對應的是強可達性,只有去掉強可達,對象才被回收。
l Soft Ref(軟引用):對應軟可達性,只要有足夠的內(nèi)存,就一直保持對象,直到發(fā)現(xiàn)內(nèi)存吃緊且沒有Strong Ref時才回收對象。一般可用來實現(xiàn)緩存,通過java.lang.ref.SoftReference類實現(xiàn)。
l Weak Ref(弱引用):比Soft Ref更弱,當發(fā)現(xiàn)不存在Strong Ref時,立刻回收對象而不必等到內(nèi)存吃緊的時候。通過java.lang.ref.WeakReference和java.util.WeakHashMap類實現(xiàn)。
l Phantom Ref(虛引用):根本不會在內(nèi)存中保持任何對象,你只能使用Phantom Ref本身。一般用于在進入finalize()方法后進行特殊的清理過程,通過 java.lang.ref.PhantomReference實現(xiàn)。
有了上面的種種我相信很容易就能把heap和perm gen撐破了吧,是的利用Strong Ref,存儲大量數(shù)據(jù),直到heap撐破;利用interned strings(或者class loader加載大量的類)把perm gen撐破。
關(guān)于shallow size、retained size
Shallow size就是對象本身占用內(nèi)存的大小,不包含對其他對象的引用,也就是對象頭加成員變量(不是成員變量的值)的總和。在32位系統(tǒng)上,對象頭占用8字節(jié),int占用4字節(jié),不管成員變量(對象或數(shù)組)是否引用了其他對象(實例)或者賦值為null它始終占用4字節(jié)。故此,對于String對象實例來說,它有三個int成員(3*4=12字節(jié))、一個char[]成員(1*4=4字節(jié))以及一個對象頭(8字節(jié)),總共3*4 +1*4+8=24字節(jié)。根據(jù)這一原則,對String a=”rosen jiang”來說,實例a的shallow size也是24字節(jié)(很多人對此有爭議,請看官甄別并留言給我)。
Retained size是該對象自己的shallow size,加上從該對象能直接或間接訪問到對象的shallow size之和。換句話說,retained size是該對象被GC之后所能回收到內(nèi)存的總和。為了更好的理解retained size,不妨看個例子。
把內(nèi)存中的對象看成下圖中的節(jié)點,并且對象和對象之間互相引用。這里有一個特殊的節(jié)點GC Roots,正解!這就是reference chain的起點。
從obj1入手,上圖中藍色節(jié)點代表僅僅只有通過obj1才能直接或間接訪問的對象。因為可以通過GC Roots訪問,所以左圖的obj3不是藍色節(jié)點;而在右圖卻是藍色,因為它已經(jīng)被包含在retained集合內(nèi)。
所以對于左圖,obj1的retained size是obj1、obj2、obj4的shallow size總和;右圖的retained size是obj1、obj2、obj3、obj4的shallow size總和。obj2的retained size可以通過相同的方式計算。
Heap Dump
heap dump是特定時間點,java進程的內(nèi)存快照。有不同的格式來存儲這些數(shù)據(jù),總的來說包含了快照被觸發(fā)時java對象和類在heap中的情況。由于快照只是一瞬間的事情,所以heap dump中無法包含一個對象在何時、何地(哪個方法中)被分配這樣的信息。
在不同平臺和不同java版本有不同的方式獲取heap dump,而MAT需要的是HPROF格式的heap dump二進制文件。想無需人工干預的話,要這樣配置JVM參數(shù):-XX:-HeapDumpOnOutOfMemoryError,當錯誤發(fā)生時,會自動生成heap dump,在生產(chǎn)環(huán)境中,只有用這種方式。如果你想自己控制什么時候生成heap dump,在Windows+JDK6環(huán)境中可利用JConsole工具,而在Linux或者Mac OS X環(huán)境下均可使用JDK5、6自帶的jmap工具。當然,還可以配置JVM參數(shù):-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
請注意!引用、轉(zhuǎn)貼本文應注明原作者:Rosen Jiang 以及出處: http://www.tkk7.com/rosen
Powered by: BlogJava Copyright © Rosen