JAVA內(nèi)存分析指引201007V02

1、JAVA內(nèi)存分析指引2010-071 環(huán)境說明根據(jù)一般項目部署情況，生產(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/server1WebSphe

2、re6安裝目錄 (默認(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)存過多，最終使得程序運行要用到的內(nèi)存大于虛擬機能提供的最

3、大內(nèi)存。為了解決Java中內(nèi)存溢出問題，我們首先必須了解Java是如何管理內(nèi)存的。Java的內(nèi)存管理就是對象的分配和釋放問題。在Java中，內(nèi)存的分配是由程序完成的，而內(nèi)存的釋放是由垃圾收集器(Garbage Collection，GC)完成的。Java的內(nèi)存垃圾回收機制是從程序的主要運行對象開始檢查引用鏈，當(dāng)遍歷一遍后發(fā)現(xiàn)沒有被引用的孤立對象就作為垃圾回收。GC為了能夠正確釋放對象，必須監(jiān)控每一個對象的運行狀態(tài)，包括對象的申請、引用、被引用、賦值等，GC都需要進(jìn)行監(jiān)控。監(jiān)視對象狀態(tài)是為了更加準(zhǔn)確地、及時地釋放對象，而釋放對象的根本原則就是該對象不再被引用。在Java中，這些無用的對象都由GC

4、負(fù)責(zé)回收，因此程序員不需要考慮這部分的內(nèi)存泄露。雖然，我們有幾個函數(shù)可以訪問GC，例如運行GC的函數(shù)System.gc()，但是根據(jù)Java語言規(guī)范定義，該函數(shù)不保證JVM的垃圾收集器一定會執(zhí)行。因為不同的JVM實現(xiàn)者可能使用不同的算法管理GC。同時JVM調(diào)用GC的策略也有很多種，有的是內(nèi)存使用到達(dá)一定程度時，GC才開始工作，也有定時執(zhí)行的，有的是平緩執(zhí)行GC，有的是中斷式執(zhí)行GC。若GC連續(xù)回收不能解決內(nèi)存堆不足的問題時，就會報 out of memory 錯誤。PS：顯示調(diào)用System.GC() 只能建議 JVM 需要在內(nèi)存中對垃圾對象進(jìn)行回收，不能馬上對內(nèi)存進(jìn)行回收。需慎用System

5、.GC()，一個是并不能解決內(nèi)存資源耗空的局面，另外頻繁調(diào)用也會增加 GC對內(nèi)存的消耗。3 內(nèi)存溢出現(xiàn)象在WebSphere的日志路徑下的SystemOut.log日志文件中會出現(xiàn)如下異常信息，系統(tǒng)的可用內(nèi)存和性能持續(xù)下降，最終導(dǎo)致應(yīng)用服務(wù)器系統(tǒng)down掉，不能響應(yīng)任何請求。當(dāng)出現(xiàn)內(nèi)存溢出時，在IBM WebSphere平臺，如果在性能診斷顧問程序配置里面選中了"啟用自動堆轉(zhuǎn)儲收，在WebSphere的安裝目錄下（WebSphere6在%安裝目錄%profiles AppSrv01下）將會生成javacore*、heapdump*之類的文件。其中，javacore文件記錄cpu線程相

6、關(guān)信息，heapdump文件記錄內(nèi)存使用信息。4 內(nèi)存溢出原因內(nèi)存溢出主要有以下四個方面的原因：1) 內(nèi)存中加載的數(shù)據(jù)量過于龐大。案例一：在我們的項目中很多都用到了Excel導(dǎo)出功能，當(dāng)一次導(dǎo)出的數(shù)據(jù)量過大時可能出現(xiàn)內(nèi)存溢出的情況。案例二：在查詢數(shù)據(jù)時，如果查詢的數(shù)據(jù)量過于龐大，也可能會導(dǎo)致內(nèi)存溢出的情況。一般可以考慮通過分頁機制來減少每次數(shù)據(jù)加載量。2) 在代碼中出現(xiàn)死循環(huán)和死遞歸3) JVM的內(nèi)存值設(shè)置過小。生產(chǎn)環(huán)境一般建議初始值512M，最大值1024M。最好不要超過1.5G4) 集合類和數(shù)組的使用不規(guī)范，存在對象的引用未消除，導(dǎo)致JVM不能回收或內(nèi)存泄露的情況。5 內(nèi)存溢出分析與診斷內(nèi)

7、存分析與診斷一般步驟：檢查JVM參數(shù)配置->檢查系統(tǒng)日志->收集內(nèi)存溢出信息->代碼走查->內(nèi)存工具分析5.1檢查JVM參數(shù)配置檢查WAS配置的JVM啟動內(nèi)存參數(shù)，確認(rèn)該參數(shù)是否配置合理。在一些項目中由于本身的業(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）修改為一個合理的值，一般設(shè)為1024M，最好不要超過1.5G。PS：在配置該參數(shù)時不能盲目的配置，如果配置過小，JVM的GC過于頻繁，開銷過大導(dǎo)致系統(tǒng)運行緩慢，內(nèi)存

8、溢出的概率會較大。如果配置過大，JVM在GC的時候，耗費時間過長。也會影響系統(tǒng)的性能和使用效果。 5.2檢查錯誤日志檢查WebSphere日志路徑下的SystemOut.log和SystemErr.log文件。查看在出現(xiàn)“OutOfMemory”錯誤前是否有其它異?；蝈e誤。對于前面所描述程序上的一些死循環(huán)、死遞歸的BUG可以很快根據(jù)拋出的異常信息進(jìn)行定位。例如在EHR的動態(tài)報表系統(tǒng)，一個構(gòu)造指標(biāo)樹的程序中，由于沒有控制指標(biāo)選擇，在樹的節(jié)點上出現(xiàn)了相同的ID的同一個指標(biāo)，因致死遞歸導(dǎo)致內(nèi)存溢出使系統(tǒng)宕機。通過在指標(biāo)選擇時加以控制，不讓添加重復(fù)指標(biāo)，解決了內(nèi)存溢出的錯誤。 查看日志對于分析內(nèi)存溢出

9、是非常重要的，通過仔細(xì)查看日志，分析內(nèi)存溢出前做過哪些操作，可以大致定位有問題的模塊。5.3收集內(nèi)存溢出信息WAS中自帶了一些內(nèi)存泄漏的探測工具，啟動這些工具WAS就可以對內(nèi)存溢出發(fā)生警報。例如：1） 性能診斷顧問，可以將輸出信息顯示在WebSphere的管理控制臺，并記錄在WebSphere應(yīng)用服務(wù)器的SystemOut.log日志文件里面。2） 啟用JVMTI，可以使用 PMI 定制選項來啟用所選統(tǒng)計信息以收集特定數(shù)據(jù)。在WebSphere應(yīng)用服務(wù)器的日志目錄下，native_stderr.log文件就是內(nèi)存回收分析文件。PMAT工具解析JAVA SDK的詳細(xì)內(nèi)存回收(GC)日志，并提供統(tǒng)

10、計信息，圖表，分析并推薦Java堆配置。PMAT提供了豐富的圖形界面來顯示Java堆的使用狀況，從而更輕松地判斷是否有內(nèi)存問題發(fā)生。3） 啟用自動堆轉(zhuǎn)儲收集，可以自動在WebSphere profile所在的路徑下生成heapdump文件?？梢允褂肐BM HeapAnalyzer、MDD4J等內(nèi)存泄露分析工具對heapdump文件進(jìn)行分析。顯示主內(nèi)存轉(zhuǎn)儲中 Java 堆占用量的主要組成部分的擁有關(guān)系上下文圖，根據(jù)對對象引用圖執(zhí)行的深度優(yōu)先遍歷，用樹形視圖顯示主內(nèi)存轉(zhuǎn)儲的所有內(nèi)容。這是我們比較常用的分析內(nèi)存溢出的方法。5.4代碼走查對代碼進(jìn)行走查和分析，找出可能發(fā)生內(nèi)存溢出的位置。重點排查以下幾

11、點： 1） 檢查代碼中是否有死循環(huán)或遞歸調(diào)用 2） 檢查是否有大循環(huán)重復(fù)產(chǎn)生新對象實體。3） 檢查對數(shù)據(jù)庫查詢中，是否有一次獲得全部數(shù)據(jù)的查詢。一般來說，如果一次取十萬條記錄到內(nèi)存，就可能引起內(nèi)存溢出。這個問題比較隱蔽，在上線前，數(shù)據(jù)庫中數(shù)據(jù)較少，不容易出問題，上線后，數(shù)據(jù)庫中數(shù)據(jù)多了，一次查詢就有可能引起內(nèi)存溢出。對于數(shù)據(jù)庫查詢建議盡量采用分頁的方式查詢。4） 檢查List、MAP等集合對象是否有使用完后，未清除的問題。List、MAP等集合對象會始終存有對對象的引用，使得這些對象不能被GC回收。5.5內(nèi)存工具分析使用內(nèi)存查看工具動態(tài)查看內(nèi)存使用情況。監(jiān)測Java程序運行時所有對象的申請、釋

12、放等動作，將內(nèi)存管理的所有信息進(jìn)行統(tǒng)計、分析、可視化。根據(jù)這些信息判斷程序是否有內(nèi)存泄漏問題。一般來說，一個正常的系統(tǒng)在其啟動完成后其內(nèi)存的占用量是基本穩(wěn)定的，而不應(yīng)該是無限制的增長的。對內(nèi)存快照中對象的使用與引用等信息進(jìn)行比對與分析，可以找出是哪個類的對象在泄漏。6 內(nèi)存分析工具6.1內(nèi)存監(jiān)控工具Jprobe通過Jprobe的JProbe Memory Debugger的功能能夠快速查找Java代碼的內(nèi)存泄露和對象循環(huán)。JProbe Memory Debugger內(nèi)置的圖形化實時內(nèi)存使用和對象視圖，有助于我們來理解應(yīng)用的內(nèi)存使用，設(shè)法減少內(nèi)存消耗以提高應(yīng)用性能。主要功能如下：1） 識別內(nèi)存泄

13、漏：通過易用的兩步分析，跟蹤運行時的內(nèi)存增長；2） Memory Instance Calculator：計算內(nèi)存泄露量；3） 智能化內(nèi)存分析：通過Leak Doctor發(fā)現(xiàn)可能的內(nèi)存泄露源；4） Aggregate Memory Footprint：理解對象創(chuàng)建的實際開銷；5） Reference Graph 和 Instance Detail：跟蹤內(nèi)存使用和對象引用；6） 垃圾回收分析：檢測過多的短期對象和垃圾收集詳情；7） Snapshot 比對：確定代碼改變對內(nèi)存使用的影響PS:最新版的8.1對WAS5不支持，如需要監(jiān)控WAS5的內(nèi)存使用情況，需要低版本如Jprobe5破解版下載地址:

14、 Jprobe使用簡介：1） 啟動Jprobe，配置需要監(jiān)控的web容器，以Tomcat為例說明。Welcome界面中點擊Create/Edit Setting2） 選擇Apache，點擊Add按鈕，根據(jù)提示，點擊next，選擇Tomcat安裝目錄，啟動腳本，Analysis Type選擇Memory，保存配置。3） 選擇配置好的web容器名，點擊Run，啟動需要監(jiān)控的Tomcat。4） Welcome界面，點擊，可看到Tomcat初始化內(nèi)存使用情況。記錄當(dāng)前內(nèi)存的總體使用情況，點擊圖表，生成一個當(dāng)前的快照（Take a Snapshot）5） 快照分析，雙擊左邊樹結(jié)構(gòu)上生成的snapshot

15、，可看到當(dāng)前加載的類的內(nèi)存使用情況，右鍵可導(dǎo)出結(jié)果到CSV文件6） 執(zhí)行需要監(jiān)控的程序，再生成一個snapshot，記錄snapshot分析結(jié)果，跟初始snapshot對比分析可看到新加載了哪些類，每個類的內(nèi)存使用情況。7） 點擊圖標(biāo)，手動GC。手動GC后再記錄一個snapshot,記錄snapshot分析結(jié)果，對比GC后snapshot與程序執(zhí)行后的snapshot中各個類的內(nèi)存使用情況，可檢查看哪些類的內(nèi)存使用在GC后沒有回收。多次執(zhí)行，對比分析結(jié)果。8） 根據(jù)以上的分析snapshot過程，可初步確定程序執(zhí)行過程中類的內(nèi)存使用情況，是否存在內(nèi)存泄漏的風(fēng)險。9） 具體分析過程，可參考OCR

16、M報表內(nèi)存使用分析報告6.2 Javacore分析工具IBM Thread and Monitor Dump Analyzer for Java Technology參考：Was問題分析培訓(xùn)資料.ppt-劉楊培訓(xùn)資料；6.3Heapdump分析工具IBM HeapAnalyzer參考Was問題分析培訓(xùn)資料.ppt，通過ha進(jìn)行分析，運行ha時所需要設(shè)置的JVM內(nèi)存大小與dump文件生成的機器上was設(shè)置有關(guān)。如was設(shè)置為1.5G，則至少需要設(shè)置-Xmx參數(shù)1500M以上或更大。如有條件，建議在AIX的環(huán)境上進(jìn)行分析。以反洗錢系統(tǒng)產(chǎn)生的hepdump文件為例說明1） 啟動ha: java Xm

17、x2000M jar ha26.jar2） 打開heapdump文件進(jìn)行分析：File->Open選擇需要分析的heapdump文件3） 分析完成后，查看分析結(jié)果 Analysis >Tree View,點擊Leak Suspects如下圖所示可看到有四個可疑泄漏對象。4） 分別檢查各可疑泄漏對象進(jìn)行進(jìn)一步分析,可發(fā)現(xiàn)：占用內(nèi)存達(dá)54%的為com/sun/rowset/CachedRowSetImpl(JSR中報表結(jié)果集所使用)占用內(nèi)存15%和13%的為org/logicalcobwebs/proxool/ProxyConnection(反洗錢中使用到的開源數(shù)據(jù)庫連接池)占用內(nèi)存6

18、%的為項目相關(guān)對象:com/lonton/fxq/v3-2/servlet/RepeatLargeDetailServlet5） 根據(jù)以上分析的結(jié)果，我們基本可以從以下幾個方面去定位問題：l 檢查是否存在大的結(jié)果集的查詢報表（重點，占用了500多M，206827個com/sun/rowset/internal/Row對象）或?qū)С龃髷?shù)據(jù)量。l 開源的數(shù)據(jù)庫連接池的使用是否有問題。l 代碼走查，檢查項目相關(guān)的類中是否存在申請未釋放的大對象。6.4Heapdump分析工具IBM Monitoring and Diagnostic Tools for JavaIBM Monitoring and Di

19、agnostic Tools for Java和MDD4J可以從IBM 技術(shù)支持站點 下載Support Assistant工具，然后選擇更新程序，獨立安裝相關(guān)插件。IBM Monitoring and Diagnostic Tools for Java使用簡介：1） 啟動IBM Support Assistant Workbench 4.1，主頁點擊分析問題2） 選擇IBM Monitoring and Diagnostic Tools for Java插件3） 啟動，選擇需要分析的heapdump文件（仍以反洗錢系統(tǒng)產(chǎn)生的heapdump文件分析）4） 分析完成，會生成一個類似heapdu

20、mp.201007的分析報告壓縮包5） 查看分析報告。可查看到有三個可疑泄露對象 53.51%com.sy 16.78%byte 12.29%同時可查看到內(nèi)存使用前幾位的相關(guān)包和類根據(jù)以上的分析結(jié)果，結(jié)合IBM HeapAnalyzer分析結(jié)果，可重點關(guān)注，看是否JSR報表訪問中存在大結(jié)果集的情況或?qū)С龃髷?shù)據(jù)量的情況。6） 分析報告參考6.5Heapdump分析工具M(jìn)DD4J（Memory Dump Diagnostic for Java）MDD4J使用參考參考資料中的WebSphere應(yīng)用服務(wù)器內(nèi)存泄漏探測與診斷工具選擇最佳實踐中的MDD4J相關(guān)章節(jié)。PS:32位機器下，MDD4J對分析對象大小有限制7 項目開發(fā)指引1） 盡早釋放無用對象的引