JAVA內(nèi)存分析指引201007_V0.2.doc

JAVA內(nèi)存分析指引2010-071 環(huán)境說明根據(jù)一般項(xiàng)目部署情況，生產(chǎn)環(huán)境以WebSphere5和WebSphere6為主，本文中所涉及環(huán)境變量也主要采用WebSphere的相關(guān)環(huán)境變量。WebSphere5安裝目錄（默認(rèn)）：Windows：C:Program FilesWebSphereAppServerAIX：/usr/WebSphere/ AppServerWebSphere5日志路徑Windows:C:Program FilesWebSphereAppServerlogsserver1AIX: /usr/WebSphere/ AppServer/logs/server1WebSphere6安裝目錄 (默認(rèn))：Windows：C:Program FilesIBMWebSphereAppServerAIX：/usr/IBM/WebSphere/AppServerWebSphere6日志路徑：Windows:C:Program FilesIBMWebSphereAppServerprofilesAppSrv01logsserver1AIX: /usr/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/server12 內(nèi)存溢出原理內(nèi)存溢出是指應(yīng)用系統(tǒng)中存在無法回收的內(nèi)存或使用的內(nèi)存過多，最終使得程序運(yùn)行要用到的內(nèi)存大于虛擬機(jī)能提供的最大內(nèi)存。為了解決Java中內(nèi)存溢出問題，我們首先必須了解Java是如何管理內(nèi)存的。Java的內(nèi)存管理就是對(duì)象的分配和釋放問題。在Java中，內(nèi)存的分配是由程序完成的，而內(nèi)存的釋放是由垃圾收集器(Garbage Collection，GC)完成的。Java的內(nèi)存垃圾回收機(jī)制是從程序的主要運(yùn)行對(duì)象開始檢查引用鏈，當(dāng)遍歷一遍后發(fā)現(xiàn)沒有被引用的孤立對(duì)象就作為垃圾回收。GC為了能夠正確釋放對(duì)象，必須監(jiān)控每一個(gè)對(duì)象的運(yùn)行狀態(tài)，包括對(duì)象的申請(qǐng)、引用、被引用、賦值等，GC都需要進(jìn)行監(jiān)控。監(jiān)視對(duì)象狀態(tài)是為了更加準(zhǔn)確地、及時(shí)地釋放對(duì)象，而釋放對(duì)象的根本原則就是該對(duì)象不再被引用。在Java中，這些無用的對(duì)象都由GC負(fù)責(zé)回收，因此程序員不需要考慮這部分的內(nèi)存泄露。雖然，我們有幾個(gè)函數(shù)可以訪問GC，例如運(yùn)行GC的函數(shù)System.gc()，但是根據(jù)Java語(yǔ)言規(guī)范定義，該函數(shù)不保證JVM的垃圾收集器一定會(huì)執(zhí)行。因?yàn)椴煌腏VM實(shí)現(xiàn)者可能使用不同的算法管理GC。同時(shí)JVM調(diào)用GC的策略也有很多種，有的是內(nèi)存使用到達(dá)一定程度時(shí)，GC才開始工作，也有定時(shí)執(zhí)行的，有的是平緩執(zhí)行GC，有的是中斷式執(zhí)行GC。若GC連續(xù)回收不能解決內(nèi)存堆不足的問題時(shí)，就會(huì)報(bào) out of memory 錯(cuò)誤。PS：顯示調(diào)用System.GC() 只能建議 JVM 需要在內(nèi)存中對(duì)垃圾對(duì)象進(jìn)行回收，不能馬上對(duì)內(nèi)存進(jìn)行回收。需慎用System.GC()，一個(gè)是并不能解決內(nèi)存資源耗空的局面，另外頻繁調(diào)用也會(huì)增加 GC對(duì)內(nèi)存的消耗。3 內(nèi)存溢出現(xiàn)象在WebSphere的日志路徑下的SystemOut.log日志文件中會(huì)出現(xiàn)如下異常信息，系統(tǒng)的可用內(nèi)存和性能持續(xù)下降，最終導(dǎo)致應(yīng)用服務(wù)器系統(tǒng)down掉，不能響應(yīng)任何請(qǐng)求。當(dāng)出現(xiàn)內(nèi)存溢出時(shí)，在IBM WebSphere平臺(tái)，如果在性能診斷顧問程序配置里面選中了啟用自動(dòng)堆轉(zhuǎn)儲(chǔ)收，在WebSphere的安裝目錄下（WebSphere6在%安裝目錄%profiles AppSrv01下）將會(huì)生成javacore*、heapdump*之類的文件。其中，javacore文件記錄cpu線程相關(guān)信息，heapdump文件記錄內(nèi)存使用信息。4 內(nèi)存溢出原因內(nèi)存溢出主要有以下四個(gè)方面的原因：1) 內(nèi)存中加載的數(shù)據(jù)量過于龐大。案例一：在我們的項(xiàng)目中很多都用到了Excel導(dǎo)出功能，當(dāng)一次導(dǎo)出的數(shù)據(jù)量過大時(shí)可能出現(xiàn)內(nèi)存溢出的情況。案例二：在查詢數(shù)據(jù)時(shí)，如果查詢的數(shù)據(jù)量過于龐大，也可能會(huì)導(dǎo)致內(nèi)存溢出的情況。一般可以考慮通過分頁(yè)機(jī)制來減少每次數(shù)據(jù)加載量。2) 在代碼中出現(xiàn)死循環(huán)和死遞歸3) JVM的內(nèi)存值設(shè)置過小。生產(chǎn)環(huán)境一般建議初始值512M，最大值1024M。最好不要超過1.5G4) 集合類和數(shù)組的使用不規(guī)范，存在對(duì)象的引用未消除，導(dǎo)致JVM不能回收或內(nèi)存泄露的情況。5 內(nèi)存溢出分析與診斷內(nèi)存分析與診斷一般步驟：檢查JVM參數(shù)配置-檢查系統(tǒng)日志-收集內(nèi)存溢出信息-代碼走查-內(nèi)存工具分析5.1檢查JVM參數(shù)配置檢查WAS配置的JVM啟動(dòng)內(nèi)存參數(shù)，確認(rèn)該參數(shù)是否配置合理。在一些項(xiàng)目中由于本身的業(yè)務(wù)邏輯復(fù)雜，需要較大的內(nèi)存開銷，而內(nèi)存參數(shù)設(shè)置過小，導(dǎo)致內(nèi)存溢。WAS配置方法：應(yīng)用程序服務(wù)器 server1 進(jìn)程定義 Java 虛擬機(jī)，將最大堆大小（默認(rèn)為256M）修改為一個(gè)合理的值，一般設(shè)為1024M，最好不要超過1.5G。PS：在配置該參數(shù)時(shí)不能盲目的配置，如果配置過小，JVM的GC過于頻繁，開銷過大導(dǎo)致系統(tǒng)運(yùn)行緩慢，內(nèi)存溢出的概率會(huì)較大。如果配置過大，JVM在GC的時(shí)候，耗費(fèi)時(shí)間過長(zhǎng)。也會(huì)影響系統(tǒng)的性能和使用效果。 5.2檢查錯(cuò)誤日志檢查WebSphere日志路徑下的SystemOut.log和SystemErr.log文件。查看在出現(xiàn)“OutOfMemory”錯(cuò)誤前是否有其它異?；蝈e(cuò)誤。對(duì)于前面所描述程序上的一些死循環(huán)、死遞歸的BUG可以很快根據(jù)拋出的異常信息進(jìn)行定位。例如在EHR的動(dòng)態(tài)報(bào)表系統(tǒng)，一個(gè)構(gòu)造指標(biāo)樹的程序中，由于沒有控制指標(biāo)選擇，在樹的節(jié)點(diǎn)上出現(xiàn)了相同的ID的同一個(gè)指標(biāo)，因致死遞歸導(dǎo)致內(nèi)存溢出使系統(tǒng)宕機(jī)。通過在指標(biāo)選擇時(shí)加以控制，不讓添加重復(fù)指標(biāo)，解決了內(nèi)存溢出的錯(cuò)誤。 查看日志對(duì)于分析內(nèi)存溢出是非常重要的，通過仔細(xì)查看日志，分析內(nèi)存溢出前做過哪些操作，可以大致定位有問題的模塊。5.3收集內(nèi)存溢出信息WAS中自帶了一些內(nèi)存泄漏的探測(cè)工具，啟動(dòng)這些工具WAS就可以對(duì)內(nèi)存溢出發(fā)生警報(bào)。例如：1） 性能診斷顧問，可以將輸出信息顯示在WebSphere的管理控制臺(tái)，并記錄在WebSphere應(yīng)用服務(wù)器的SystemOut.log日志文件里面。2） 啟用JVMTI，可以使用 PMI 定制選項(xiàng)來啟用所選統(tǒng)計(jì)信息以收集特定數(shù)據(jù)。在WebSphere應(yīng)用服務(wù)器的日志目錄下，native_stderr.log文件就是內(nèi)存回收分析文件。PMAT工具解析JAVA SDK的詳細(xì)內(nèi)存回收(GC)日志，并提供統(tǒng)計(jì)信息，圖表，分析并推薦Java堆配置。PMAT提供了豐富的圖形界面來顯示Java堆的使用狀況，從而更輕松地判斷是否有內(nèi)存問題發(fā)生。3） 啟用自動(dòng)堆轉(zhuǎn)儲(chǔ)收集，可以自動(dòng)在WebSphere profile所在的路徑下生成heapdump文件?？梢允褂肐BM HeapAnalyzer、MDD4J等內(nèi)存泄露分析工具對(duì)heapdump文件進(jìn)行分析。顯示主內(nèi)存轉(zhuǎn)儲(chǔ)中 Java 堆占用量的主要組成部分的擁有關(guān)系上下文圖，根據(jù)對(duì)對(duì)象引用圖執(zhí)行的深度優(yōu)先遍歷，用樹形視圖顯示主內(nèi)存轉(zhuǎn)儲(chǔ)的所有內(nèi)容。這是我們比較常用的分析內(nèi)存溢出的方法。5.4代碼走查對(duì)代碼進(jìn)行走查和分析，找出可能發(fā)生內(nèi)存溢出的位置。重點(diǎn)排查以下幾點(diǎn)： 1） 檢查代碼中是否有死循環(huán)或遞歸調(diào)用 2） 檢查是否有大循環(huán)重復(fù)產(chǎn)生新對(duì)象實(shí)體。3） 檢查對(duì)數(shù)據(jù)庫(kù)查詢中，是否有一次獲得全部數(shù)據(jù)的查詢。一般來說，如果一次取十萬條記錄到內(nèi)存，就可能引起內(nèi)存溢出。這個(gè)問題比較隱蔽，在上線前，數(shù)據(jù)庫(kù)中數(shù)據(jù)較少，不容易出問題，上線后，數(shù)據(jù)庫(kù)中數(shù)據(jù)多了，一次查詢就有可能引起內(nèi)存溢出。對(duì)于數(shù)據(jù)庫(kù)查詢建議盡量采用分頁(yè)的方式查詢。4） 檢查L(zhǎng)ist、MAP等集合對(duì)象是否有使用完后，未清除的問題。List、MAP等集合對(duì)象會(huì)始終存有對(duì)對(duì)象的引用，使得這些對(duì)象不能被GC回收。5.5內(nèi)存工具分析使用內(nèi)存查看工具動(dòng)態(tài)查看內(nèi)存使用情況。監(jiān)測(cè)Java程序運(yùn)行時(shí)所有對(duì)象的申請(qǐng)、釋放等動(dòng)作，將內(nèi)存管理的所有信息進(jìn)行統(tǒng)計(jì)、分析、可視化。根據(jù)這些信息判斷程序是否有內(nèi)存泄漏問題。一般來說，一個(gè)正常的系統(tǒng)在其啟動(dòng)完成后其內(nèi)存的占用量是基本穩(wěn)定的，而不應(yīng)該是無限制的增長(zhǎng)的。對(duì)內(nèi)存快照中對(duì)象的使用與引用等信息進(jìn)行比對(duì)與分析，可以找出是哪個(gè)類的對(duì)象在泄漏。6 內(nèi)存分析工具6.1內(nèi)存監(jiān)控工具Jprobe通過Jprobe的JProbe Memory Debugger的功能能夠快速查找Java代碼的內(nèi)存泄露和對(duì)象循環(huán)。JProbe Memory Debugger內(nèi)置的圖形化實(shí)時(shí)內(nèi)存使用和對(duì)象視圖，有助于我們來理解應(yīng)用的內(nèi)存使用，設(shè)法減少內(nèi)存消耗以提高應(yīng)用性能。主要功能如下：1） 識(shí)別內(nèi)存泄漏：通過易用的兩步分析，跟蹤運(yùn)行時(shí)的內(nèi)存增長(zhǎng)；2） Memory Instance Calculator：計(jì)算內(nèi)存泄露量；3） 智能化內(nèi)存分析：通過Leak Doctor發(fā)現(xiàn)可能的內(nèi)存泄露源；4） Aggregate Memory Footprint：理解對(duì)象創(chuàng)建的實(shí)際開銷；5） Reference Graph 和 Instance Detail：跟蹤內(nèi)存使用和對(duì)象引用；6） 垃圾回收分析：檢測(cè)過多的短期對(duì)象和垃圾收集詳情；7） Snapshot 比對(duì)：確定代碼改變對(duì)內(nèi)存使用的影響PS:最新版的8.1對(duì)WAS5不支持，如需要監(jiān)控WAS5的內(nèi)存使用情況，需要低版本如Jprobe5破解版下載地址: /Crack/2009/05/JProbe.Suite.v8.1.0.Cracked-FALLEN.rarJprobe使用簡(jiǎn)介：1） 啟動(dòng)Jprobe，配置需要監(jiān)控的web容器，以Tomcat為例說明。Welcome界面中點(diǎn)擊Create/Edit Setting2） 選擇Apache，點(diǎn)擊Add按鈕，根據(jù)提示，點(diǎn)擊next，選擇Tomcat安裝目錄，啟動(dòng)腳本，Analysis Type選擇Memory，保存配置。3） 選擇配置好的web容器名，點(diǎn)擊Run，啟動(dòng)需要監(jiān)控的Tomcat。4） Welcome界面，點(diǎn)擊，可看到Tomcat初始化內(nèi)存使用情況。記錄當(dāng)前內(nèi)存的總體使用情況，點(diǎn)擊圖表，生成一個(gè)當(dāng)前的快照（Take a Snapshot）5） 快照分析，雙擊左邊樹結(jié)構(gòu)上生成的snapshot，可看到當(dāng)前加載的類的內(nèi)存使用情況，右鍵可導(dǎo)出結(jié)果到CSV文件6） 執(zhí)行需要監(jiān)控的程序，再生成一個(gè)snapshot，記錄snapshot分析結(jié)果，跟初始snapshot對(duì)比分析可看到新加載了哪些類，每個(gè)類的內(nèi)存使用情況。7） 點(diǎn)擊圖標(biāo)，手動(dòng)GC。手動(dòng)GC后再記錄一個(gè)snapshot,記錄snapshot分析結(jié)果，對(duì)比GC后snapshot與程序執(zhí)行后的snapshot中各個(gè)類的內(nèi)存使用情況，可檢查看哪些類的內(nèi)存使用在GC后沒有回收。多次執(zhí)行，對(duì)比分析結(jié)果。8） 根據(jù)以上的分析snapshot過程，可初步確定程序執(zhí)行過程中類的內(nèi)存使用情況，是否存在內(nèi)存泄漏的風(fēng)險(xiǎn)。9） 具體分析過程，可參考OCRM報(bào)表內(nèi)存使用分析報(bào)告6.2 Javacore分析工具IBM Thread and Monitor Dump Analyzer for Java Technology參考：Was問題分析培訓(xùn)資料.ppt-劉楊培訓(xùn)資料；/tech/jca6.3Heapdump分析工具IBM HeapAnalyzer參考Was問題分析培訓(xùn)資料.ppt，通過ha進(jìn)行分析，運(yùn)行ha時(shí)所需要設(shè)置的JVM內(nèi)存大小與dump文件生成的機(jī)器上was設(shè)置有關(guān)。如was設(shè)置為1.5G，則至少需要設(shè)置-Xmx參數(shù)1500M以上或更大。如有條件，建議在AIX的環(huán)境上進(jìn)行分析。以反洗錢系統(tǒng)產(chǎn)生的hepdump文件為例說明1） 啟動(dòng)ha: java Xmx2000M jar ha26.jar2） 打開heapdump文件進(jìn)行分析：File-Open選擇需要分析的heapdump文件3） 分析完成后，查看分析結(jié)果 Analysis Tree View,點(diǎn)擊Leak Suspects如下圖所示可看到有四個(gè)可疑泄漏對(duì)象。4） 分別檢查各可疑泄漏對(duì)象進(jìn)行進(jìn)一步分析,可發(fā)現(xiàn)：占用內(nèi)存達(dá)54%的為com/sun/rowset/CachedRowSetImpl(JSR中報(bào)表結(jié)果集所使用)占用內(nèi)存15%和13%的為org/logicalcobwebs/proxool/ProxyConnection(反洗錢中使用到的開源數(shù)據(jù)庫(kù)連接池)占用內(nèi)存6%的為項(xiàng)目相關(guān)對(duì)象:com/lonton/fxq/v3-2/servlet/RepeatLargeDetailServlet5） 根據(jù)以上分析的結(jié)果，我們基本可以從以下幾個(gè)方面去定位問題：l 檢查是否存在大的結(jié)果集的查詢報(bào)表（重點(diǎn)，占用了500多M，206827個(gè)com/sun/rowset/internal/Row對(duì)象）或?qū)С龃髷?shù)據(jù)量。l 開源的數(shù)據(jù)庫(kù)連接池的使用是否有問題。l 代碼走查，檢查項(xiàng)目相關(guān)的類中是否存在申請(qǐng)未釋放的大對(duì)象。6.4Heapdump分析工具IBM Monitoring and Diagnostic Tools for JavaIBM Monitoring and Diagnostic Tools for Java和MDD4J可以從IBM 技術(shù)支持站點(diǎn)/software/support/isa/ 下載Support Assistant工具，然后選擇更新程序，獨(dú)立安裝相關(guān)插件。IBM Monitoring and Diagnostic Tools for Java使用簡(jiǎn)介：1） 啟動(dòng)IBM Support Assistant Workbench 4.1，主頁(yè)點(diǎn)擊分析問題2） 選擇IBM Monitoring and Diagnostic Tools for Java插件3） 啟動(dòng)，選擇需要分析的heapdump文件（仍以反洗錢系統(tǒng)產(chǎn)生的heapdump文件分析）4） 分析完成，會(huì)生成一個(gè)類似heapdump.20100719.162930.6380.0011_Leak_Suspects.zip的分析報(bào)告壓縮包5） 查看分析報(bào)告。可查看到有三個(gè)可疑泄露對(duì)象com.sun.rowset.CachedRowSetImpl 53.51%com.sybase.jdbc3.tds.TdsProtocolContext 16.78%byte 12.29%同時(shí)可查看到內(nèi)存使用前幾位的相關(guān)包和類根據(jù)以上的分析結(jié)果，結(jié)合IBM HeapAnalyzer分析結(jié)果，可重點(diǎn)關(guān)注com.sun.rowset.CachedRowSetImpl，看是否JSR報(bào)表訪問中存在大結(jié)果集的情況或?qū)С龃髷?shù)據(jù)量的情況。6） 分析報(bào)告參考6.5Heapdump分析工具M(jìn)DD4J（Memory Dump Diagnostic for Java）MDD4J使用參考參考資料中的WebSphere應(yīng)用服務(wù)器內(nèi)存泄漏探測(cè)與診斷工具選擇最佳實(shí)踐中的MDD4J相關(guān)章節(jié)。PS:32位機(jī)器下，MDD4J對(duì)分析對(duì)象大小有限制7 項(xiàng)目開發(fā)指引1） 盡早釋放無用對(duì)象的引用。特別是大對(duì)象和集合對(duì)象，通過置為NULL，暗示垃圾收集器來收集