JVM內(nèi)存問題最佳實(shí)踐

JVM內(nèi)存問題最正確實(shí)踐

JVMBestPractice王超2010年03月JVM內(nèi)存問題最正確實(shí)踐本次技術(shù)交流，涵蓋范圍為：如何選擇適宜的Java虛擬機(jī)了解Java根本內(nèi)存管理根本概念了解發(fā)生內(nèi)存缺乏/內(nèi)存泄漏錯(cuò)誤的原因和病癥了解如何診斷內(nèi)存缺乏/內(nèi)存泄漏錯(cuò)誤了解如何解決內(nèi)存缺乏/內(nèi)存泄漏錯(cuò)誤MENU

選擇適宜的Java虛擬機(jī)Java內(nèi)存管理的根本概念GC次數(shù)過多消耗時(shí)間過長的原因和病癥內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤的原因和病癥診斷、定位和解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤使用分析工具解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤預(yù)防內(nèi)存缺乏和內(nèi)存泄漏OutOfMemory錯(cuò)誤實(shí)例3Java虛擬機(jī)的種類OracleJava虛擬機(jī)原SunJava虛擬機(jī)原BEAJRockit兩種Java虛擬機(jī)，都運(yùn)行在Windows、Linux、Solaris平臺(tái)HPJava虛擬機(jī)：與SUNJDK根本兼容，有自己獨(dú)特的啟動(dòng)參數(shù)運(yùn)行在HPUNIX上IBMJava虛擬機(jī)：與SunJDK根本兼容啟動(dòng)參數(shù)的寫法風(fēng)格與SunJDK、HPJDK非常不同主要用于WebSphere、跑在AIX上的中間件效勞器開源Java虛擬機(jī)：與SUNJDK兼容4如何選擇適宜的Java虛擬機(jī)選擇穩(wěn)定的JDK：安裝JDK之前，先看廠商的ReleaseNotes根據(jù)平臺(tái)和應(yīng)用，選擇適宜廠商的JDK：HP-UX只能選擇HPJDK，AIX只能選擇IBMJDKWindows、Linux可以選擇SUNJDK和JRockitSolaris平臺(tái)，最好使用SUNJDK開源JDK，目前生產(chǎn)環(huán)境中用的極少5Java虛擬機(jī)32VS64盡量選擇使用32位JDK：32位JDK在TPS測試中，結(jié)果比64位JDK要好;JDK6.0啟用指針壓縮技術(shù)后，64位略微領(lǐng)先32位JDK主要適用于內(nèi)存需求較小，CPU密集型應(yīng)用64位JDK主要用于大內(nèi)存應(yīng)用：

突破4G內(nèi)存限制吞吐量并沒有提高主要用于大內(nèi)存需求的系統(tǒng)盡量啟用指針壓縮技術(shù)IBM:-XcompressedrefsSUN:-d64-XX:+UseCompressedOopsBEA:-XXcompressedRefs=true6小節(jié)回憶Java虛擬機(jī)的種類如何選擇適宜的Java虛擬機(jī)32bitVS64bit在本小節(jié)中，我們講述了以下內(nèi)容：

7MENU

選擇適宜的Java虛擬機(jī)Java內(nèi)存管理的根本概念GC次數(shù)過多消耗時(shí)間過長的原因和病癥內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤的原因和病癥診斷、定位和解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤使用分析工具解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤預(yù)防內(nèi)存缺乏和內(nèi)存泄漏OutOfMemory錯(cuò)誤實(shí)例8Java內(nèi)存管理的根本概念Java內(nèi)存Java堆內(nèi)存〔heap〕Permanent區(qū)〔Sun/HpJDK〕Java堆內(nèi)存(heap)：是JVM用于分配Java對象的內(nèi)存，包含活動(dòng)對象

和不可用對象堆大小通常是在效勞器啟動(dòng)時(shí)使用java命令中的–Xms(最小)–Xmx〔最大〕標(biāo)志來定義。Permanent區(qū)：是SunJDK和HPJDK用來加載類(class)的專門的內(nèi)存區(qū)這個(gè)區(qū)域不歸屬Java堆內(nèi)存(heap)范圍如果Java應(yīng)用很大，例如類(class)很多，那么建議增大這個(gè)區(qū)域的大小來滿足加載這些類的內(nèi)存需求通過–XX:PermSize=***M–XX:MaxPermSize=***M調(diào)整9Java內(nèi)存管理的根本概念本地內(nèi)存(nativememory)：是JVM用于其內(nèi)部操作的本地內(nèi)存〔非Java內(nèi)存〕JNI代碼和第三方本地模塊〔例如，本地JDBC驅(qū)動(dòng)

程序〕也使用本地內(nèi)存最大本地內(nèi)存大小取決于以下因素：操作系統(tǒng)進(jìn)程內(nèi)存大小限制已經(jīng)指定用于Java堆的內(nèi)存進(jìn)程內(nèi)存大?。?2位操作系統(tǒng)，理論最大值2的32次方＝4G64位操作系統(tǒng)下使用64位的JDK，按照現(xiàn)在的硬件條件，可以看做無限制進(jìn)程內(nèi)存＝Java內(nèi)存＋本地內(nèi)存＋加載的可執(zhí)行文件和庫＋操作系統(tǒng)保存內(nèi)存10Java內(nèi)存管理的根本概念Java堆內(nèi)存大小的決定因素：進(jìn)程大小限制，<=4G“加載的可執(zhí)行文件和庫＋系統(tǒng)保存內(nèi)存”不同操作系統(tǒng)和應(yīng)用不一樣，通常在百M(fèi)到1G間JVM的本地內(nèi)存在不同的JDK之間也不一樣。JRockit相對SunJDK，做了非常好的JIT優(yōu)化，但是本地內(nèi)存要求更多的空間通常Java堆內(nèi)存大小推薦不大于2G目前Unix/Linux操作系統(tǒng)默認(rèn)已經(jīng)做了內(nèi)核調(diào)整--開啟了大內(nèi)存模式，可以上到2G以上Java堆內(nèi)存的大內(nèi)存模式：AIX上Java堆內(nèi)存有大內(nèi)存模式〔LAM〕，最大支持到3.25GWindow上有連續(xù)地址空間限制，通常不大于1.5G。WindowsAdvanceServer最大支持3G模式。其他操作系統(tǒng)請查看操作系統(tǒng)文檔和對應(yīng)JVM文檔11物理內(nèi)存和虛擬內(nèi)存

進(jìn)程的虛擬內(nèi)存由OS映射到物理內(nèi)存。

計(jì)算機(jī)的物理內(nèi)存

=RAM+交換空間進(jìn)程

A的虛擬內(nèi)存

保留供

OS使用

Java堆

本地內(nèi)存

可執(zhí)行

文件/庫進(jìn)程

B的虛擬內(nèi)存

保留供

OS使用Java堆本地內(nèi)存可執(zhí)行

文件/庫

進(jìn)程的虛擬內(nèi)存受

OS進(jìn)程

大小的限制。

進(jìn)程

C的虛擬內(nèi)存

可執(zhí)行

文件/庫Java堆保留供

OS使用本地內(nèi)存

進(jìn)程

D的虛擬內(nèi)存

可執(zhí)行

文件/庫

Java堆保留供

OS使用本地內(nèi)存

RAM交換空間

JVM啟動(dòng)時(shí)將保存堆12Java內(nèi)存管理的根本概念垃圾回收(GarbageCollection,GC)：JVM自動(dòng)檢測和釋放不再使用的內(nèi)存。Java運(yùn)行時(shí)JVM會(huì)執(zhí)行GC，這樣程序員不再需要顯式釋放對象。通常在空閑內(nèi)存降低到某一水平或內(nèi)存分配到達(dá)某一

數(shù)量后自動(dòng)觸發(fā)。各種JDK的垃圾回收都有多種算法和策略以下OutOfMemory簡稱OOM以下MemoryLeak簡稱MLHeap簡稱“堆”13Java內(nèi)存問題的三種表現(xiàn)形式--1Java內(nèi)存問題的三種表現(xiàn)形式：GC次數(shù)過多，導(dǎo)致占用時(shí)間過長內(nèi)存缺乏錯(cuò)誤內(nèi)存泄漏錯(cuò)誤GC占用時(shí)間過長－－系統(tǒng)明顯感覺比較慢Heap區(qū)、Perm區(qū)分配內(nèi)存總量夠用通過verbosegc、jstat觀察，GC占用時(shí)間超過總時(shí)間的5%甚至更高內(nèi)存缺乏錯(cuò)誤－－明確顯示出沒有空閑內(nèi)存可供JVM或本地代碼用于分配新對象或內(nèi)存塊在Java堆或本地內(nèi)存中都可能發(fā)生14Java內(nèi)存問題的三種表現(xiàn)形式--2內(nèi)存泄漏錯(cuò)誤－－沒有錯(cuò)誤信息，但是內(nèi)存幾乎耗盡已經(jīng)分配好的內(nèi)存或?qū)ο?，?dāng)不再需要，沒有得到釋放內(nèi)存曲線是一條斜向上的曲線對Java堆或本地內(nèi)存都可能產(chǎn)生這個(gè)問題通常最終的狀態(tài)就會(huì)導(dǎo)致OOM錯(cuò)誤通常內(nèi)存泄漏ML會(huì)導(dǎo)致OOM錯(cuò)誤，因此兩者的探查方法完全相同！

15Java內(nèi)存問題的兩個(gè)主要發(fā)生區(qū)段Java內(nèi)存問題的兩個(gè)主要發(fā)生區(qū)段：Java內(nèi)存－－包括heap堆內(nèi)存和permanent區(qū)本地內(nèi)存－－包括JVM進(jìn)程內(nèi)存和java使用的第三方本地代碼Java內(nèi)存分配不合理Java堆內(nèi)存充足，但是S0、S1、Eden、Old區(qū)分配不合理Perm區(qū)-Xms缺乏-Xmx充足，類動(dòng)態(tài)加載引起Perm增長導(dǎo)致FULLGCJava內(nèi)存缺乏Java堆內(nèi)存heap缺乏，無法再分配新對象或內(nèi)存塊permanent區(qū)內(nèi)存缺乏，無法再加載類到內(nèi)存中〔Sun&HpJDK〕本地內(nèi)存缺乏物理內(nèi)存不夠，無法再得到內(nèi)存第三方本地代碼有內(nèi)存泄漏的Bug，例如oracleocidriver本地代碼JVM的JIT或者JVM本身的Bug16小節(jié)回憶Java進(jìn)程的內(nèi)存分類Java堆內(nèi)存(Heap)JavaPermanent區(qū)Java本地代碼Java內(nèi)存問題的三個(gè)表現(xiàn)類型Java內(nèi)存問題的兩個(gè)發(fā)生區(qū)段在本小節(jié)中，我們講述了以下內(nèi)容：

17MENU

選擇適宜的Java虛擬機(jī)Java內(nèi)存管理的根本概念GC次數(shù)過多消耗時(shí)間過長的原因和病癥內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤的原因和病癥診斷、定位和解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤使用分析工具解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤預(yù)防內(nèi)存缺乏和內(nèi)存泄漏OutOfMemory/MemoryLeak錯(cuò)誤實(shí)例18常見GC概念調(diào)整GC前提：程序是健康的Heap區(qū)(-Xmx)夠大，日志中沒有OutOfMemory異?；ㄔ贕C上面的總時(shí)間占用太高，比方超過5%常見GC算法：SUN、HP的GC算法JRockit的GC算法IBMJDK的GC算法GC算法：選擇GC算法的指導(dǎo)思想19常見GC算法--SUN、HP〔1〕根據(jù)回收器，簡單分為：串行–XX:+UseSerialGCOutofBox算法，年輕代串行復(fù)制，年老代串行標(biāo)記整理，主要用于桌面應(yīng)用并行–XX:+UseParallelGC年輕代暫停應(yīng)用程序，多個(gè)垃圾收集線程并行的復(fù)制收集，年老代暫停應(yīng)用程序，與串行收集器一樣，單垃圾收集線程標(biāo)記整理。JDK6.0啟用該算法后，默認(rèn)啟用了-XX:+UseParallelOldGC，性能大為提高并發(fā)(ConcurrentLowPauseCollector)–XX:+UseConcMarkSweepGC啟用該參數(shù)，默認(rèn)啟用了-XX:+UseParNewGC；簡單的說，并發(fā)是指用戶線程與垃圾收集線程并發(fā)，程序在繼續(xù)運(yùn)行，而垃圾收集程序運(yùn)行于其他CPU上。GarbageFirst(G1)GarbageCollector-XX:+UnlockExperimentalVMOptions-XX:+UseG1GCSUNJDK6.0Update14引入，實(shí)際生產(chǎn)環(huán)境中還沒有采用20常見GC算法--SUN、HP〔2〕并行算法例如：-server-Xms1536m-Xmx1536m-XX:NewSize=512m-XX:MaxNewSize=512m-XX:PermSize=128m-XX:MaxPermSize=256m-XX:+UseParallelGC-XX:+UseParallelOldGC-XX:+UseAdaptiveSizePolicy-XX:SurvivorRatio=2-XX:+DisableExplicitGC-verbose:gc-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-Xloggc:/tmp/server_gc$$.log并發(fā)算法例如：-server-Xms1536m-Xmx1536m-XX:NewSize=1024m-XX:MaxNewSize=1024m-XX:PermSize=128m-XX:MaxPermSize=256m-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:SurvivorRatio=2-XX:MaxTenuringThreshold=16-XX:+DisableExplicitGC-XX:+CMSPermGenSweepingEnabled-XX:+UseCMSCompactAtFullCollection-XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=60-XX:+CMSParallelRemarkEnabled-Dsun.rmi.dgc.client.gcInterval=3600000-Dsun.rmi.dgc.server.gcInterval=3600000-verbose:gc-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-Xloggc:/tmp/server_gc$$.log21常見GC算法--JRockit根據(jù)回收器，簡單分為：-XgcPrio:throughput默認(rèn)算法，主要用于桌面應(yīng)用-XgcPrio:pausetime-XgcPrio:pausetime-XpauseTarget:210ms因?yàn)槊赓M(fèi)，所以最低只能設(shè)置到200ms。200ms是Real-TimeJDK的分界線-XgcPrio:deterministic動(dòng)態(tài)調(diào)整的垃圾收集策略例如：-Xms1024m-Xmx1024m-Xgcprio:pausetime-Xpausetarget=210ms-XgcReport-XgcPause-Xverbose:memory22常見GC算法--IBM根據(jù)回收器，簡單分為：-Xgcpolicy:optthruput默認(rèn)策略。對于吞吐量比短暫的GC停頓更重要的應(yīng)用程序，通常使用這種策略。每當(dāng)進(jìn)行垃圾收集時(shí)，應(yīng)用程序都會(huì)停頓。-Xgcpolicy:optavgpause通過并發(fā)地執(zhí)行一局部垃圾收集，在高吞吐量和短GC停頓之間進(jìn)行折中。應(yīng)用程序停頓的時(shí)間更短。-Xgcpolicy:gencon以不同方式處理短期存活的對象和長期存活的對象。采用這種策略時(shí)，具有許多短期存活對象的應(yīng)用程序會(huì)表現(xiàn)出更短的停頓時(shí)間，同時(shí)仍然產(chǎn)生很好的吞吐量。-Xgcpolicy:subpool采用與默認(rèn)策略相似的算法，但是采用一種比較適合多處理器計(jì)算機(jī)的分配策略。建議對于有16個(gè)或更多處理器的SMP計(jì)算機(jī)使用這種策略。這種策略只能在IBMpSeries?和zSeries?平臺(tái)上使用。需要擴(kuò)展到大型計(jì)算機(jī)上的應(yīng)用程序可以從這種策略中受益。例如：-Xms768m-Xmx1024m-Xmn256m-Xgcpolicy:gencon23選擇適宜的GC算法選擇GC算法，遵循以下原那么：評估程序類型桌面應(yīng)用還是效勞器端應(yīng)用吞吐量優(yōu)先還是響應(yīng)時(shí)間優(yōu)先僅適用64位JDK的算法比方在IBMAIX64位JDK環(huán)境下，當(dāng)heap區(qū)大于16G后，subpool明顯性能提高確定GC算法之后，再逐步調(diào)整小參數(shù)-Xmn(-XX:NewSize-XX:MaxNewSize)-XX:SurvivorRatio-XX:MaxTenuringThreshold.......測試期間實(shí)時(shí)監(jiān)控SUN、HP、JRockit都可以通過jstat命令進(jìn)行實(shí)時(shí)監(jiān)控防止使用jmap-histo，原因是可能會(huì)造成FullGC24小節(jié)回憶GC概念常見GC算法選擇適宜的GC算法在本小節(jié)中，我們講述了以下內(nèi)容：

25MENU

選擇適宜的Java虛擬機(jī)Java內(nèi)存管理的根本概念GC次數(shù)過多消耗時(shí)間過長的原因和病癥內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤的原因和病癥診斷、定位和解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤使用分析工具解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤預(yù)防內(nèi)存缺乏和內(nèi)存泄漏OutOfMemory/MemoryLeak錯(cuò)誤實(shí)例26Java內(nèi)存問題的主要發(fā)生在操作系統(tǒng)本身Java內(nèi)存區(qū)：heap堆內(nèi)存permanent區(qū)本地內(nèi)存區(qū)：JVM進(jìn)程內(nèi)存Java使用的第三方本地代碼27內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤的典型原因〔1〕物理內(nèi)存缺乏物理內(nèi)存有限，例如只有1G物理內(nèi)存很大，但是應(yīng)用很多，占用太多內(nèi)存Swap區(qū)大小不夠WeblogicServer壓力太大并發(fā)用戶太多大數(shù)據(jù)量分配應(yīng)用，例如統(tǒng)計(jì)報(bào)表Permanent區(qū)太小用戶代碼內(nèi)存不釋放session放置了大量對象在內(nèi)存分配大量數(shù)據(jù)用戶自己創(chuàng)立太多線程調(diào)用AWT等畫圖接口用戶代碼內(nèi)存泄漏問題jdbc連接沒有close分配好的對象沒有close和釋放28內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤的典型原因〔2〕WeblogicServer配置不當(dāng)給heap分配的內(nèi)存太多sessiontimeout時(shí)間太長EJBpool和Cache的太大JMS配置Java內(nèi)存碎片尤其在IBMJDK上表現(xiàn)明顯第三方Java應(yīng)用的內(nèi)存問題第三方Java應(yīng)用也存在內(nèi)存缺乏或者泄漏問題第三方本地代碼的內(nèi)存泄漏問題第二類JDBC驅(qū)動(dòng)的內(nèi)存泄漏，例如OracleOciDriver其他第三方本地代碼的內(nèi)存泄漏JVM本身的內(nèi)存問題JIT技術(shù)需要消耗更多的本地內(nèi)存JVM本身的Bug，例如GC的Bug29在Java堆中發(fā)生的OOM的故障病癥如果Java堆發(fā)生OOM/ML：WeblogicServer運(yùn)行緩慢，響應(yīng)速度很慢〔JVM在頻繁的做GC，Java進(jìn)程占用比較多的CPU〕從console的內(nèi)存監(jiān)控曲線看，一直徘徊在頂部最終JVM拋出異常，stdout或stderr中將顯示這那么消息通過threaddump可以看到大局部時(shí)間所有線程都在wait，只有GC線程在工作很多線程都在申請內(nèi)存線程可能會(huì)異常退出〔即在ThreadDump中看不到這個(gè)線程，線程喪失〕持續(xù)的Java堆OOM/ML錯(cuò)誤偶爾也會(huì)導(dǎo)致JVM進(jìn)程退出效勞，通常伴隨會(huì)產(chǎn)生一個(gè)文本Core文件30在本地內(nèi)存中發(fā)生的OOM的故障病癥如果本地內(nèi)存OOM/ML：WeblogicServer運(yùn)行緩慢，響應(yīng)速度很慢通過操作系統(tǒng)觀察可以看到，Java進(jìn)程內(nèi)存很大，而且一直在增長通過console或者GClog可以看到，heap內(nèi)存通常還有充裕JVM的通常做法是：處理OOM狀態(tài)，記錄消息，然后退出進(jìn)程。如果JVM或任何其它已加載的模塊〔例如，libc或第

三方模塊〕不處理異常，OS將通過sigabort強(qiáng)制JVM退出。通常會(huì)導(dǎo)致JVM異常退出，通常會(huì)產(chǎn)生JVM文本Core文件和二進(jìn)制核心文件。31JVM退出時(shí)產(chǎn)生的文本Core文件通常JVM異常退出伴隨會(huì)產(chǎn)生一個(gè)文本Core文件除了OOM，JVM也會(huì)因?yàn)槠渌虍惓Ｍ顺鯥BMJDK--javacore****.txt文件Sun&HpJDK--hs_err_pid****.log文件JRockitJDK–jrockit.****.dump文件文本Core文件包含JVM退出時(shí)收到的信號量，并會(huì)用*標(biāo)識(shí)導(dǎo)致退出的lib庫文件Signal-1Signal0Signal4Signal10Signal11實(shí)踐說明，收到以上的信號量，通常但不絕對，說明JVM的內(nèi)存出現(xiàn)問題需要結(jié)合threaddump或者GC日志來分析32小節(jié)回憶內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤的典型原因OOM錯(cuò)誤的類型及相關(guān)故障病癥文本Core文件在本小節(jié)中，我們講述了以下內(nèi)容：

33MENU

選擇適宜的Java虛擬機(jī)Java內(nèi)存管理的根本概念GC次數(shù)過多消耗時(shí)間過長的原因和病癥內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤的原因和病癥診斷、定位和解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤使用分析工具解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤預(yù)防內(nèi)存缺乏和內(nèi)存泄漏OutOfMemory/MemoryLeak錯(cuò)誤實(shí)例34說在診斷和定位OOM/ML錯(cuò)誤之前第一所有JDK的OOM/ML都是類似的，原理是一樣的診斷定位方法根本一致，除非特殊說明針對那個(gè)JDK這里提及的診斷定位方法以weblogicserver為主，但是適用于任何應(yīng)用效勞器〔包括tomcat,resin,IAS,websphere〕第二OOM/ML發(fā)生時(shí)間跨度大：短的1個(gè)小時(shí)之內(nèi)，長的10天甚至1個(gè)月問題解決可能需要消耗大量時(shí)間和精力問題解決經(jīng)常會(huì)反復(fù)很屢次檢查和跟蹤注意保護(hù)現(xiàn)場，收集足夠多的信息第三統(tǒng)計(jì)顯示：OOM/ML問題占2.54%，但平均處理時(shí)間38.5天，數(shù)倍于問題平均處理時(shí)間35探查OOM/ML問題根本步驟1〕確定是否OOM/ML錯(cuò)誤2〕如果保存現(xiàn)場，立即查看物理內(nèi)存大小Java進(jìn)程內(nèi)存大小剩余可用內(nèi)存大小Swap區(qū)大小查看GClog或進(jìn)console查看內(nèi)存使用曲線并發(fā)用戶數(shù)量/主要業(yè)務(wù)類型分析立即做threaddump幫助分析3〕如果沒有保存現(xiàn)場，那么加上GCFlag，收集垃圾回收日志直到再次發(fā)生OOM/ML，分析GC日志4〕根本確定內(nèi)存問題類型物理內(nèi)存缺乏并發(fā)太多/Java堆內(nèi)存缺乏本地泄漏其他原因5〕采取相應(yīng)措施6〕觀察，問題是否重現(xiàn)7〕重復(fù)定位/問題解決36確定是否OOM/ML錯(cuò)誤明確的OOM/ML錯(cuò)誤是否有明確的OutOfMemory錯(cuò)誤信息顯示是否明確的看到內(nèi)存曲線一直在頂部是否GC日志明確顯示內(nèi)存緊張不明確的信息，但是可以歸到OOM/ML錯(cuò)誤需要更多信息來證實(shí)GC日志ThreadDump文本Core文件通?？梢詺w到OOM/ML錯(cuò)誤的可能病癥：WeblogicServer不響應(yīng)，很慢GC異常，例如heap使用到頂，GC時(shí)間很長ThreadDump顯示幾乎所有的線程都在等待，只有GC線程在工作Core文件指出信號量為-1/0/4/10/1137查看現(xiàn)場/收集信息(1)物理內(nèi)存大小如果物理內(nèi)存不夠，請?jiān)黾游锢韮?nèi)存Java進(jìn)程內(nèi)存大小如果Java進(jìn)程內(nèi)存不大，只有幾百M(fèi)或者1G左右，要結(jié)合并發(fā)用戶和GC日志來考慮如果Java進(jìn)程內(nèi)存特別大，例如到2.5G以上，結(jié)合heap設(shè)置綜合考慮。如果heap設(shè)置不大1G左右，那么需要考慮本地內(nèi)存泄漏的可能剩余可用內(nèi)存結(jié)合物理總內(nèi)存，Java進(jìn)程內(nèi)存綜合考慮是否合理Swap區(qū)大小Swap區(qū)通常建議是物理內(nèi)存的2－3倍38查看現(xiàn)場/收集信息(2)查看GClog或進(jìn)console查看內(nèi)存使用曲線并發(fā)用戶數(shù)量/主要業(yè)務(wù)類型分析當(dāng)時(shí)并發(fā)用戶數(shù)量以及session大小分析主要業(yè)務(wù)類型分析，是否有大內(nèi)存占用的業(yè)務(wù)，例如統(tǒng)計(jì)報(bào)表等等立即做threaddump幫助分析每隔30秒做一次，做3次Unix/Linux:kill-3pidWindows:Ctrl+break收集操作系統(tǒng)/JDK/WLS信息操作系統(tǒng)版本信息JDK版本信息WebLogicServer版本信息是否使用了第三方本地代碼39查看現(xiàn)場/收集信息－－措施調(diào)整措施增加物理內(nèi)存調(diào)整合理的Heap設(shè)置調(diào)整Swap區(qū)大小繼續(xù)跟蹤通過Java進(jìn)程內(nèi)存大小和Heap大小判斷Java堆內(nèi)存問題本地內(nèi)存問題加上GCFlag來分析IBMJDK-verbose:gc-Xverbosegclog:<path_GC_log_file_name>HPJDK-Xverbosegc[:help]|[0|1][:file=[stdout|stderr|<filename>]]-XloggcSunJDK/BEAJrockit-verbose:gc繼續(xù)下一步–分析GC日志40分析GC日志－－完整GC

的輸出

不同的JDK將產(chǎn)生不同格式GC日志，以下分析以SunJDK標(biāo)準(zhǔn)GC日志為準(zhǔn)不同的JDK有各自的其他豐富信息的GC開關(guān)選項(xiàng)完整GC將產(chǎn)生類似如下內(nèi)容的消息：[memory]<start>:GC<before>K-><after>K(<heap>K),<total>ms

其中：<start>GC的開始時(shí)間〔秒〕，從JVM啟動(dòng)開始計(jì)算<before>回收前對象所使用的內(nèi)存(KB)<after>回收后對象所使用的內(nèi)存(KB)<size>回收后的堆大小(KB)<total>執(zhí)行回收的總時(shí)間〔毫秒〕。完整GC消息例如：[memory]7.160:GC131072K->130052K(131072K)in1057.359ms41分析GC日志－－分析GC

輸出

GC輸出可以反映以下情況：OOM錯(cuò)誤是否發(fā)生在運(yùn)行完整GC之后GC返回了多少空閑空間，GC運(yùn)行了多長時(shí)間內(nèi)存使用量是否增加緩慢〔即說明發(fā)生了內(nèi)存泄漏，通常需要觀察長時(shí)間/大量的GC日志〕是否存在內(nèi)存碎片結(jié)合JVM進(jìn)程內(nèi)存大小，判斷Javaheap內(nèi)存問題還是本地內(nèi)存問題42分析GC日志－－確定內(nèi)存問題類型根本確定內(nèi)存問題類型Java堆內(nèi)存缺乏本地內(nèi)存泄漏不同內(nèi)存問題類型，解決方案有所不同如何確定：Java堆內(nèi)存缺乏Java進(jìn)程內(nèi)存比較穩(wěn)定GC日志顯示，heap區(qū)內(nèi)存不夠，GC很頻繁本地內(nèi)存泄漏GC日志顯示，heap內(nèi)存尚有足夠空間但是Java進(jìn)程卻隨時(shí)間一直在增長〔需要長時(shí)間觀察積累〕43處理

JavaHeap

OOM錯(cuò)誤

對于JavaHeapOOM錯(cuò)誤：請確保啟用verboseGC，也就是在啟動(dòng)效勞器時(shí)使用java-verbosegc開關(guān)檢查OOM錯(cuò)誤是否發(fā)生在運(yùn)行了完整的GC之后檢查是否執(zhí)行了內(nèi)存壓縮以減少內(nèi)存碎片還要留意初始〔和周期〕JVM堆可用性/占用率。44針對

Java堆

OOM的應(yīng)用程序分析

如果JVM正確執(zhí)行了GC，那么應(yīng)該是應(yīng)用程序問題所致：如果應(yīng)用程序使用了緩存對象：請確保對緩存對象數(shù)量施加了限制或許可以降低緩存限值來減少總體堆大小如果應(yīng)用程序使用了活動(dòng)時(shí)間長的對象，請減少這些對象的數(shù)量或縮短它們的生命周期，例如，縮短HTTP會(huì)話的超時(shí)期間調(diào)整垃圾回收策略，可能解決OOM問題查找內(nèi)存泄漏，例如，不正確的JDBC池連接處理如果效勞器只是對負(fù)載增加或添加應(yīng)用程序作出反響，JVM自然會(huì)需要更大的Heap45分析GC日志－－內(nèi)存緩慢增長從GC日志中看到內(nèi)存的緩慢增長[GC71678K->61588K(98112K),0.0073410secs][GC97999K->87826K(98240K),0.0073438secs][GC190603K->170624K(191640K),0.0196674secs][GC144325K->121582K(225376K),0.0850580secs][GC189537K->162596K(257432K),0.0170420secs][GC239766K->210684K(277080K),0.0299292secs][GC246611K->208929K(359776K),0.0172918secs]

…46分析GC日志－－內(nèi)存碎片從GC日志中分析觀察到內(nèi)存碎片現(xiàn)象這個(gè)問題多發(fā)生在IBMJDK上，因?yàn)樗捎玫睦厥账惴ǜ鷦e的JDK不一致〔注：IBMJDKGC輸入與上略有不同〕在SunJDK/HPJDK不常見，很少出現(xiàn)調(diào)整策略IBMJDK：-XcompactgcSunJDK：增加young區(qū)大小-XX:NewRatio-XX:NewSize-XX:MaxNewSize-XX:SurvivorRatio(詳細(xì)參見Sun文檔)GC減少了使用的堆，其大小已與最大

堆大小有明顯差距，OOM卻依然出現(xiàn)！

顯示在執(zhí)行GC后仍存在碎片的GC消息示例：

[memory]8.162:GC73043K->72989K(131072K)in12.938ms

[memory]8.172:GC72989K->72905K(131072K)in12.000ms

[memory]8.182:GC72905K->72580K(131072K)in13.509ms...

java.lang.OutOfMemoryError47分析GC日志－－Permanent區(qū)不夠從GC日志中觀察到這個(gè)問題發(fā)生在Sun/HPJDK上，因?yàn)樗捎肞ermanent區(qū)來存放Java的class對象這個(gè)問題的主要區(qū)別在于兩者發(fā)生的時(shí)間不一樣調(diào)整策略增加Permanent區(qū)大小-XX:MaxPermSize=256M〔推薦128M以上〕OOM卻依然出現(xiàn)！注意這種情況主要出現(xiàn)在WLS啟動(dòng)不久，通常在1－20分鐘內(nèi)。GC日志顯示內(nèi)存還充足[memory]8.162:GC73043K->72989K(131072K)in12.938ms

[memory]8.172:GC72989K->72905K(131072K)in12.000ms

[memory]8.182:GC72905K->72580K(131072K)in13.509ms...

java.lang.OutOfMemoryError48進(jìn)一步分析Java堆OOM

如果迄今為止所進(jìn)行的分析不起作用，請使用JVM性能探查工具：該探查工具將實(shí)現(xiàn)JVM事件探查器接口(JVMProfilerInterface,JVMPI)，如Jprobe或OptimizeIt或者YourKit確定占用堆的對象的類型、數(shù)量和大小確定對象在代碼中的創(chuàng)立位置其用法的詳細(xì)信息，請參考相應(yīng)的JVM性能探查工具文檔不過，JVM事件探查器通常需要較高的系統(tǒng)開銷，

因此建議一定不要在生產(chǎn)環(huán)境中使用！與應(yīng)用程序團(tuán)隊(duì)合作，查明可能存在的內(nèi)存泄漏或

改進(jìn)對象的使用和/或生命周期狀況。49JRockit功能

JRockit1.4.2支持Java運(yùn)行時(shí)分析器

(JavaRuntimeAnalyzer,JRA)：該分析器對JRockitJVM及JRockit上運(yùn)行的Java應(yīng)用程序都能夠進(jìn)行運(yùn)行時(shí)性能分析。JRA包括以下兩個(gè)局部：收集有關(guān)JVM和當(dāng)前正在運(yùn)行的Java應(yīng)用程序的數(shù)據(jù)。使用分析器工具來查看收集到的信息。執(zhí)行幾分鐘的記錄，然后對數(shù)據(jù)進(jìn)行分析，以確定具

體的JVM問題JRockit1.4.2_05的JRA支持MemoryLeak檢測功能50處理本地內(nèi)存OOM〔1〕對于本地內(nèi)存OOM錯(cuò)誤：采用的探查方法與對Java堆OOM采用的探查方法

相同：通過-verbosegc開關(guān)收集GC信息確認(rèn)GC的運(yùn)行符合預(yù)期，例如，是在OOM發(fā)生前運(yùn)行留意JVM堆的初始〔和周期〕可用性/占用率。定期監(jiān)視進(jìn)程內(nèi)存大?。涸赨nix/Linux上，使用ps-p<PID>-ovsz或者top命令在Windows上，使用perfmon工具。確定是否使用了任何本地模塊或JNI代碼。還要檢查計(jì)算機(jī)的物理內(nèi)存總量〔RAM和交換空間

之和〕是否足以滿足所有正在運(yùn)行的進(jìn)程的需要51處理本地內(nèi)存OOM〔2〕請記住，進(jìn)程內(nèi)存大小：是進(jìn)程運(yùn)行時(shí)所占用的地址空間受OS進(jìn)程大小值的限制：32位Unix：進(jìn)程大小限值為4GB，保存1-2GB供OS自己使用RedHatLinuxAS2.1：可供給用程序使用的進(jìn)程大小為3GBWindows：進(jìn)程大小限值為2GB〔缺省值〕，但可以增加到3GB包括Java堆內(nèi)存，JVM在效勞器啟動(dòng)時(shí)會(huì)保存指定的最大值還可能由JNI代碼或本地模塊〔例如，本地JDBC驅(qū)動(dòng)程序〕

進(jìn)行分配還會(huì)受計(jì)算機(jī)物理內(nèi)存及計(jì)算機(jī)中運(yùn)行的其它進(jìn)程的限制。52處理本地內(nèi)存OOM〔3〕使用收集到的數(shù)據(jù)來解決OOM錯(cuò)誤如果疑心發(fā)生了內(nèi)存泄漏，集中精力查找泄漏源第三方代碼〔例如，JDBC驅(qū)動(dòng)程序〕或JNI代碼

可能會(huì)發(fā)生泄漏排除法，不使用第三方代碼可能的情況下嘗試替換純Java實(shí)現(xiàn)，以確認(rèn)泄漏源。如果存在本地內(nèi)存泄漏增加物理內(nèi)存，只能夠延緩故障發(fā)生，無法鏟除問題53處理本地內(nèi)存OOM〔4〕從GC日志中看到Heap實(shí)際使用大小遠(yuǎn)小于最大值，可以減少這個(gè)最大值，提供更多可用的本地內(nèi)存如果RAM和交換空間缺乏，添加內(nèi)存或者升級計(jì)算機(jī)JVM使用本地內(nèi)存：加載類和生成代碼，但在啟動(dòng)幾小時(shí)后，內(nèi)存使用量通常會(huì)穩(wěn)定下來可能會(huì)發(fā)生運(yùn)行時(shí)類加載和代碼優(yōu)化〔JIT〕禁用JIT功能：如果使用的是JRockit，-Xnoopt如果使用的是Sun/HP的JDK，-Xint如果使用的是IBMJDK，-Djavapiler=NONE54處理本地內(nèi)存OOM〔5〕最后，如果無法查明本地內(nèi)存OOM錯(cuò)誤的成因：請與JVM供給商聯(lián)系，找到跟蹤本地內(nèi)存分配調(diào)用的方法請與第三方模塊或JNI代碼供給商聯(lián)系，是否有調(diào)試/跟蹤功能繼續(xù)收集和分析有關(guān)OOM錯(cuò)誤發(fā)生時(shí)間和發(fā)生原因的信息如果存在多個(gè)成因，縮小探查范圍可能需要一些時(shí)間。升級升級JDK升級操作系統(tǒng)升級WeblogicServer55小節(jié)回憶如何識(shí)別Java內(nèi)存錯(cuò)誤和本地內(nèi)存錯(cuò)誤根據(jù)GC日志解決內(nèi)存問題解決Java內(nèi)存問題的步驟解決本地內(nèi)存問題的步驟在本小節(jié)中，我們講述了以下內(nèi)容：56MENU

選擇適宜的Java虛擬機(jī)Java內(nèi)存管理的根本概念GC次數(shù)過多消耗時(shí)間過長的原因和病癥內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤的原因和病癥診斷、定位和解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤使用分析工具解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤預(yù)防內(nèi)存缺乏和內(nèi)存泄漏OutOfMemory/MemoryLeak錯(cuò)誤實(shí)例57使用分析工具來分析OOM問題發(fā)生JavaHeapOOM問題時(shí)，無法定位到問題，最終的方法只能使用分析工具來做分析。常用內(nèi)存分析工具此類工具非常多，推薦使用輕量級分析工具YourKit－輕量級EeclipseMemoryAnalyzer－離線分析IBMHeapAnalyzer&MDD4J－離線分析58YourKit〔1〕YourKit是一款輕量級的Java運(yùn)行時(shí)分析工具特性：性能好，對生產(chǎn)系統(tǒng)造成的影響相對其他工具比較小支持多種平臺(tái)〔windows/linux/mac/solaris〕支持多種JDK〔理論上〕界面友好啟動(dòng)方式：安裝YourKit，啟動(dòng)并加載license拷貝domain下的啟動(dòng)腳本startWebLogicd或startWebLogic.sh，并重命名為startWLSd/startWLS.sh在YourKit中找到startWLSd/startWLS.sh，得到新的啟動(dòng)腳本startWLS_with_yjp.bat/startWLS_with_yjp.sh使用startWLS_with_yjp.bat/startWLS_with_yjp.sh啟動(dòng)weblogicserver，記住啟動(dòng)時(shí)YourKit在weblogicserver上得到的監(jiān)聽端口在YourKit中連接到這個(gè)監(jiān)聽端口，并開始監(jiān)控和分析weblogicserver的運(yùn)行情況59YourKit〔2〕

啟動(dòng)和配置YourKit123460YourKit〔3〕使用收集到的數(shù)據(jù)來解決OOM錯(cuò)誤如果YourKit跟WebLogicServer本機(jī)運(yùn)行，選第一項(xiàng)如果YourKit連接遠(yuǎn)程的WebLogicServer，選第二項(xiàng)需要IP和Port61YourKit〔4〕抓取內(nèi)存鏡像SnapShot，做分析62EclipseMemoryAnalyzer〔1〕EclipseMemoryAnalyzer原名SAPMemoryAnalyzer，后SA公司捐獻(xiàn)給Eclipse社區(qū)，現(xiàn)在IBM也參加進(jìn)來，是目前最實(shí)用的免費(fèi)離線內(nèi)存診斷工具特性：離線分析，不影響生產(chǎn)系統(tǒng)需要得到JDK內(nèi)存鏡像支持SUN、HP(1.4.2_121.5.0_07及以后版本)最新版本支持IBMJDK啟動(dòng)方式：啟動(dòng)參數(shù)增加-XX:+HeapDumpOnCtrlBreak-XX:+HeapDumpOnOutOfMemoryErrorKill-3<pid>得到heapdump文件JDK5.0可以采用jmap-heap:format=bpidofjavaJDK6.0可以采用jmap-dump:live,format=b,file=/tmp/xxx.hprofpidofjava啟動(dòng)EclipseMemoryAnalyzer，加載heapdump文件圖形化分析63EclipseMemoryAnalyzer〔2〕啟動(dòng)界面64EclipseMemoryAnalyzer〔3〕Overview視圖65EclipseMemoryAnalyzer〔4〕LeakSuspects視圖66EclipseMemoryAnalyzer〔5〕Dominatortree視圖67EclipseMemoryAnalyzer〔6〕結(jié)合使用LeakSuspects和Dominatortree視圖68HeapAnalyzer〔1〕HeapAnalyzer是一款針對IBMJDK的內(nèi)存文本鏡像HeapDump的分析工具特性：離線分析，不影響生產(chǎn)系統(tǒng)需要得到IBMJDK內(nèi)存鏡像只支持IBMJDK只能靜態(tài)分析，要求得到現(xiàn)場數(shù)據(jù)啟動(dòng)方式：Kill-3<pid>得到heapdump文件啟動(dòng)HeapAnalyzer，加載heapdump文件圖形化分析69HeapAnalyzer〔2〕HeapDump是IBMJDKHeap內(nèi)存的一個(gè)文本鏡像，默認(rèn)生成位置在WeblogicServer啟動(dòng)目錄下，通常是Domain目錄如果得不到HeapDump，可能是禁止生成HeapDump的生成開關(guān)exportIBM_HEAPDUMP=trueexportIBM_HEAP_DUMP=trueexportIBM_HEAPDUMP_OUTOFMEMORY=trueexportIBM_JAVADUMP_OUTOFMEMORY=trueexportIBM_JAVACORE_OUTOFMEMORY=trueexportIBM_HEAPDUMPDIR=<directory_path>注意：通常HeapDump會(huì)比較大，尤其是在Heap內(nèi)存設(shè)置很大的情況下為了重現(xiàn)問題，得到現(xiàn)場數(shù)據(jù)，建議先把HeapDump調(diào)小，推薦1G以下在Window上，如果HeapDump大于1G，可能會(huì)無法翻開，出現(xiàn)OOM錯(cuò)誤啟動(dòng)HeapAnalyzer需要指定-Xmx參數(shù)70HeapAnalyzer〔3〕啟動(dòng)界面71HeapAnalyzer〔4〕內(nèi)存按樹狀引用關(guān)系顯示72HeapAnalyzer〔5〕內(nèi)存按對象和類型顯示73HeapAnalyzer〔6〕找到疑心泄漏的內(nèi)存對象74HeapAnalyzer〔7〕內(nèi)存碎片分析75小節(jié)回憶內(nèi)存分析工具YourKitEeclipseMemoryAnalyzerIBMHeapAnalyzer&MDD4J在本小節(jié)中，我們學(xué)習(xí)了以下內(nèi)容：76MENU

選擇適宜的Java虛擬機(jī)Java內(nèi)存管理的根本概念GC次數(shù)過多消耗時(shí)間過長的原因和病癥內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤的原因和病癥診斷、定位和解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤使用分析工具解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤預(yù)防內(nèi)存缺乏和內(nèi)存泄漏OutOfMemory/MemoryLeak錯(cuò)誤實(shí)例77預(yù)防內(nèi)存缺乏和內(nèi)存泄漏最好的補(bǔ)救不如事先的預(yù)防預(yù)防內(nèi)存缺乏和內(nèi)存泄漏系統(tǒng)管理代碼編寫78預(yù)防內(nèi)存缺乏和內(nèi)存泄漏－系統(tǒng)管理系統(tǒng)管理足夠的物理內(nèi)存，適當(dāng)?shù)腟wap區(qū)大小最正確的HEAP內(nèi)存設(shè)置使用最新的操作系統(tǒng)/最新的JDK/最新版本的WLS使用WeblogicServer認(rèn)證的JDK盡量少使用第三方本地代碼，或使用Java替代方案對SunJDK，適宜的Permanent區(qū)大小適當(dāng)?shù)睦厥账惴ê筒呗赃m當(dāng)?shù)腍ttpSessionTimeout時(shí)間適當(dāng)?shù)腅JBPool/Cache適當(dāng)?shù)膚eblogicserver調(diào)優(yōu)79預(yù)防內(nèi)存缺乏和內(nèi)存泄漏－代碼編寫代碼編寫不要放置大量對象到Session中不要緩存太多數(shù)據(jù)用完的資源一定要close()，例如IO，F(xiàn)ile，JDBC連接不要違反J2EE標(biāo)準(zhǔn)。例如在EJB里開Socket合理的從數(shù)據(jù)庫取得適量數(shù)據(jù)XML解析對大內(nèi)存的需求統(tǒng)計(jì)和報(bào)表業(yè)務(wù)的負(fù)荷問題良好的代碼習(xí)慣80小節(jié)回憶預(yù)防內(nèi)存缺乏和內(nèi)存泄漏系統(tǒng)管理代碼編寫在本小節(jié)中，我們講述了以下內(nèi)容：

81MENU

選擇適宜的Java虛擬機(jī)Java內(nèi)存管理的根本概念GC次數(shù)過多消耗時(shí)間過長的原因和病癥內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤的原因和病癥診斷、定位和解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤使用分析工具解決內(nèi)存缺乏和內(nèi)存泄漏錯(cuò)誤預(yù)防內(nèi)存缺乏和內(nèi)存泄漏OutOfMemory/MemoryLeak錯(cuò)誤實(shí)例82OutOfMemory錯(cuò)誤實(shí)例案例一83OutOfMemory錯(cuò)誤實(shí)例〔1〕現(xiàn)象環(huán)境IBMAIX5.2，，WeblogicServer813剛啟動(dòng)很好，過了一段時(shí)間，用戶數(shù)上來，就發(fā)生OOM。自動(dòng)產(chǎn)生heapdump和javacore文件只能重啟。重啟過了一段時(shí)間又是這樣。84OutOfMemory錯(cuò)誤實(shí)例〔1〕問題收集什么信息？？？85OutOfMemory錯(cuò)誤實(shí)例〔1〕答案GC日志JavaCore文件分析ThreadDumpHeapDump用HeapAnalyser86OutOfMemory錯(cuò)誤實(shí)例〔1〕－GC日志<GC(1):freed30618248bytes,97%free(1048443192/1073674752),in44ms><GC(7):freed915866016bytes,88%free(948327168/1073674752),in151ms><GC(8):freed637378736bytes,63%free(680325728/1073674752),in290ms><GC(9):freed78799496bytes,10%free(111009736/1073674752),in550ms><GC(10):freed2988992bytes,10%free(113998728/1073674752),in514ms><GC(11):freed2616648bytes,0%free(2616648/1073674752),in570ms><GC(12):freed33508896bytes,3%free(36125544/1073674752),in1068ms><GC(13):freed36543728bytes,3%free(36543728/1073674752),in1096ms><GC(14):freed35539080bytes,6%free(72082808/1073674752),in1154ms>********************************************<GC(25):freed36172752bytes,3%free(36172752/1073674752),in1209ms><GC(26):freed35313152bytes,6%free(71485904/1073674752),in1186ms><GC(27):freed1602776bytes,0%free(1602776/1073674752),in934ms><GC(44):freed17638904bytes,3%free(36564840/1073674752),in1375ms><GC(45):freed73536bytes,0%free(73536/1073674752),in734ms><GC(47):freed17252248bytes,1%free(17252248/1073674752),in1425ms><GC(48):freed9550608bytes,0%free(9550608/1073674752),in1443ms><GC(49):freed1014816904bytes,94%free(1014816904/1073674752),in101ms><GC(50):freed758913488bytes,91%free(979761952/1073674752),in155ms>87OutOfMemory錯(cuò)誤實(shí)例〔1〕－ThreadDump1TISIGINFOOUTOFMEMORYreceived

1TIDATETIMEDate:2005/05/11at15:56:131XHTIMEWedMay1115:56:1320051XHSIGRECVUnexpectedsignal-1receivedat0x0in<unknown>.Processingterminated.1XHFULLVERSIONJ2RE1.4.2IBMAIXbuildca1420-200406262CIUSERARG-Xms1024m2CIUSERARG-Xmx1024m2CIUSERARG-verbose:gc2CIUSERARG-Xverbosegclog:/bea/gc.log1STHEAPFREEBytesofHeapSpaceFree:45b8(17,848)1STHEAPALLOCBytesofHeapSpaceAllocated:3ffefa00(1,073,674,752)2LKREGMONHeaplock(0x30071788):owner"ExecuteThread:'0'forqueue:'weblogic.socket.Muxer'"(0x7BA1EC20),entrycount23LKWAITERQWaitingtoenter:3LKWAITER"ExecuteThread:'2'forqueue:'weblogic.kernel.Non-Blocking'"(0x7DF83CA0)3LKWAITER"ListenThread.Default"(0x7D9D78A0)3LKWAITER"weblogic.health.CoreHealthMonitor"(0x7C6E3320)3LKWAITER"Thread-5"(0x7C25BC20)3LKWAITER"ExecuteThread:'2'forqueue:'weblogic.admin.RMI'"(0x7BD332A0)3LKWAITER"ExecuteThread:'0'forqueue:'weblogic.admin.RMI'"(0x7BD298A0)3LKWAITER"ExecuteThread:'2'forqueue:'weblogic.socket.Muxer'"(0x7BA1FEA0)3LKWAITER"ExecuteThread:'1'forqueue:'weblogic.socket.Muxer'"(0x7BA1F8A0)3LKWAITER"ExecuteThread:'149'forqueue:'weblogic.kernel.Default'"(0x7B4AE3A0)3LKWAITER"ExecuteThread:'143'forqueue:'weblogic.kernel.Default'"(0x7B180920)3LKWAITER"ExecuteThread:'142'forqueue:'weblogic.kernel.Default'"(0x7B0F8F20)3LKWAITER"ExecuteThread:'128'forqueue:'weblogic.kernel.Default'"(0x7A98E6A0)3LKWAITER"ExecuteThread:'127'forqueue:'weblogic.kernel.Default'"(0x7A906D20)3LKWAITER"ExecuteThread:'122'forqueue:'weblogic.kernel.Default'"(0x7A660C20)3LKWAITER"ExecuteThread:'107'forqueue:'weblogic.kernel.Default'"(0x79E6EA20)3LKWAITER"ExecuteThread:'100'forqueue:'weblogic.kernel.Default'"(0x79AB6420)3LKWAITER"ExecuteThread:'99'forqueue:'weblogic.kernel.Default'"(0x79A2EA20)3LKWAITER"ExecuteThread:'98'forqueue:'weblogic.kernel.Default'"(0x799A70A0)88OutOfMemory錯(cuò)誤實(shí)例〔1〕－ThreadDump3XMTHREADINFO"ExecuteThread:'81'forqueue:'weblogic.kernel.Default'"(TID:0x30106330,sys_thread_t:0x790A5AA0,state:CW,nativeID:0x5B5C)prio=54