【正文】 35 說在診斷和定位 OOM/ML錯(cuò)誤 之前 ? 第一 – 所有 JDK的 OOM/ML都是類似的，原理是一樣的 – 診斷定位方法基本一致，除非特殊說明針對(duì)那個(gè) JDK – 這里提及的診斷定位方法以 weblogic server為主，但是適用于任何應(yīng)用服務(wù)器（包括 tomcat,resin,IAS,websphere） ? 第二 – OOM/ML發(fā)生時(shí)間跨度大：短的 1個(gè)小時(shí)之內(nèi)，長的 10天甚至 1個(gè)月 – 問題解決可能需要耗費(fèi)大量時(shí)間和精力 – 問題解決經(jīng)常會(huì)反復(fù)很多次檢查和跟蹤 – 注意保護(hù)現(xiàn)場，收集足夠多的信息 ? 第三 – 統(tǒng)計(jì)顯示 ： – OOM/ML 問題占 %， – 但平均處理時(shí)間 ，數(shù)倍于問題平均處理時(shí)間 36 探查 OOM/ML問題基本步驟 ? 1）確定是否 OOM/ML錯(cuò)誤 ? 2）如果保留現(xiàn)場，立即查看 – 物理內(nèi)存大小 – Java進(jìn)程內(nèi)存大小 – 剩余可用內(nèi)存大小 – Swap區(qū)大小 – 查看 GC log 或 進(jìn) console查看內(nèi)存使用曲線 – 并發(fā)用戶數(shù)量 /主要業(yè)務(wù)類型分析 – 立即做 thread dump幫助分析 ? 3）如果沒有保留現(xiàn)場，那么 – 加上 GC Flag，收集垃圾回收日志 – 直到再次發(fā)生 OOM/ML，分析 GC日志 ? 4）基本確定內(nèi)存問題類型 – 物理內(nèi)存不足 – 并發(fā)太多 /Java堆內(nèi)存不足 – 本地泄漏 – 其他原因 ? 5）采取相應(yīng)措施 ? 6）觀察，問題是否重現(xiàn) ? 7）重復(fù)定位 /問題解決 37 確定是否 OOM/ML錯(cuò)誤 ? 明確的 OOM/ML錯(cuò)誤 – 是否有明確的 OutOfMemory錯(cuò)誤信息顯示 – 是否明確的看到內(nèi)存曲線一直在頂部 – 是否 GC日志明確顯示內(nèi)存緊張 ? 不明確的信息，但是可以歸到 OOM/ML錯(cuò)誤 – 需要更多信息來證實(shí) – GC日志 – Thread Dump – 文本 Core文件 – 通常可以歸到 OOM/ML錯(cuò)誤的可能癥狀： – Weblogic Server不響應(yīng)，很慢 – GC異常，例如 heap使用到頂， GC時(shí)間很長 – Thread Dump顯示幾乎所有的線程都在等待，只有 GC線程在工作 – Core文件指出信號(hào)量為 1/0/4/10/11 38 查看現(xiàn)場 /收集信息 (1) ?物理內(nèi)存大小 – 如果物理內(nèi)存不夠，請?jiān)黾游锢韮?nèi)存 ?Java進(jìn)程內(nèi)存大小 – 如果 Java進(jìn)程內(nèi)存不大，只有幾百 M或者 1G左右，要結(jié)合并發(fā)用戶和 GC日志來考慮 – 如果 Java進(jìn)程內(nèi)存特別大，例如到 ，結(jié)合 heap設(shè)置綜合考慮。MDD4J －離線分析 59 YourKit（ 1） ? YourKit是一款輕量級(jí)的 Java運(yùn)行時(shí)分析工具 ? ? 特性： – 性能好，對(duì)生產(chǎn)系統(tǒng)造成的影響相對(duì)其他工具比較小 – 支持多種平臺(tái)（ windows/linux/mac/solaris） – 支持多種 JDK（理論上） – 界面友好 ? 啟動(dòng)方式： – 安裝 YourKit，啟動(dòng)并加載 license – 拷貝 domain下的啟動(dòng)腳本 ，并重命名為– 在 YourKit中找到 ，得到新的啟動(dòng)腳本– 使用 ，記住啟動(dòng)時(shí) YourKit在 weblogic server上得到的監(jiān)聽端口 – 在 YourKit中連接到這個(gè)監(jiān)聽端口，并開始監(jiān)控和分析 weblogic server的運(yùn)行情況 60 YourKit（ 2） ? 啟動(dòng)和配置 YourKit 1 2 3 4 61 YourKit（ 3） ?使用收集到的數(shù)據(jù)來解決 OOM 錯(cuò)誤 ?如果 YourKit跟 WebLogic Server本機(jī)運(yùn)行，選第一項(xiàng) ?如果 YourKit連接遠(yuǎn)程的 WebLogic Server，選第二項(xiàng) 需要 IP和 Port 62 YourKit（ 4） ?抓取內(nèi)存鏡像 SnapShot ，做分析 63 Eclipse Memory Analyzer（ 1） ? Eclipse Memory Analyzer原名 SAP Memory Analyzer，后 SA公司捐獻(xiàn)給 Eclipse社區(qū)，現(xiàn)在 IBM也加入進(jìn)來，是目前最實(shí)用的免費(fèi)離線內(nèi)存診斷工具 ? 特性： – 離線分析，不影響生產(chǎn)系統(tǒng) – 需要得到 JDK內(nèi)存鏡像 – 支持 SUN、 HP( ) – 最新版本支持 IBM JDK ? 啟動(dòng)方式： – 啟動(dòng)參數(shù)增加 XX:+HeapDumpOnCtrlBreak XX:+HeapDumpOnOutOfMemoryError – Kill 3 pid得到 heapdump文件 – jmap heap:format=b pidofjava – jmap dump:live,format=b,file=/tmp/ pidofjava – 啟動(dòng) Eclipse Memory Analyzer，加載 heapdump文件 – 圖形化分析 64 Eclipse Memory Analyzer（ 2） ? 啟動(dòng)界面 65 Eclipse Memory Analyzer（ 3） ? Overview視圖 66 Eclipse Memory Analyzer（ 4） ? Leak Suspects視圖 67 Eclipse Memory Analyzer（ 5） ? Dominator tree視圖 68 Eclipse Memory Analyzer（ 6） ? 結(jié)合使用 Leak Suspects和 Dominator tree視圖 69 HeapAnalyzer（ 1） ? HeapAnalyzer是一款針對(duì) IBM JDK的內(nèi)存文本鏡像 HeapDump的分析工具 ? 特性： – 離線分析，不影響生產(chǎn)系統(tǒng) – 需要得到 IBM JDK內(nèi)存鏡像 – 只支持 IBM JDK – 只能靜態(tài)分析，要求得到現(xiàn)場數(shù)據(jù) ? 啟動(dòng)方式： – Kill 3 pid得到 heapdump文件 – 啟動(dòng) HeapAnalyzer，加載 heapdump文件 – 圖形化分析 70 HeapAnalyzer（ 2） ? HeapDump是 IBM JDK Heap內(nèi)存的一個(gè)文本鏡像，默認(rèn)生成位置在 Weblogic Server啟動(dòng)目錄下，通常是 Domain目錄 ? 如果得不到 HeapDump，可能是禁止生成 ? HeapDump的生成開關(guān) – export IBM_HEAPDUMP=true – export IBM_HEAP_DUMP=true – export IBM_HEAPDUMP_OUTOFMEMORY=true – export IBM_JAVADUMP_OUTOFMEMORY=true – export IBM_JAVACORE_OUTOFMEMORY=true – export IBM_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ù) 71 HeapAnalyzer（ 3） ?啟動(dòng)界面 72 HeapAnalyzer（ 4） ?內(nèi)存按樹狀引用關(guān)系顯示 73 HeapAnalyzer（ 5） ?內(nèi)存按對(duì)象和類型顯示 74 HeapAnalyzer（ 6） ?找到懷疑泄漏的內(nèi)存對(duì)象 75 HeapAnalyzer（ 7） ?內(nèi)存碎片分析 76 小節(jié)回顧 ? 內(nèi)存分析工具 ? YourKit ? Eeclipse Memory Analyzer ? IBM HeapAnalyzeramp。39。39。39。39。39。39。39。39。39。 53 處理本地內(nèi)存 OOM（ 3） ?使用收集到的數(shù)據(jù)來解決 OOM 錯(cuò)誤 ?如果懷疑發(fā)生了內(nèi)存泄漏，集中精力查找泄漏源 – 第三方代碼（例如， JDBC 驅(qū)動(dòng)程序）或 JNI 代碼 可能會(huì)發(fā)生泄漏 – 排除法，不使用第三方代碼 – 可能的情況下嘗試替換純 Java 實(shí)現(xiàn)，以確認(rèn)泄漏源。 ? 示例： – Xms768m Xmx1024m Xmn256m Xgcpolicy:gencon 24 選擇合適的 GC算法 ? 選擇 GC算法，遵循以下原則： – 評(píng)估程序類型 桌面應(yīng)用還是服務(wù)器端應(yīng)用 吞吐量優(yōu)先還是響應(yīng)時(shí)間優(yōu)先 – 僅適用 64位 JDK的算法 比如在 IBM AIX 64位 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ì)造成 Full GC 25 小節(jié)回顧 ? GC概念 ? 常見 GC算法 ? 選擇合適的 GC算法 在本小節(jié)中，我們講述了以下內(nèi)容： 26 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/Memory Leak錯(cuò)誤實(shí)例 27 Java內(nèi)存問題的主要發(fā)生在 ?操作系統(tǒng)本身 ?Java內(nèi)存區(qū)： – heap堆內(nèi)存 – permanent區(qū) ?本地內(nèi)存區(qū)： – JVM進(jìn)程內(nèi)存 – Java使用的第三方本地代碼 28 內(nèi)存不足和內(nèi)存泄漏錯(cuò)誤的典型原因（ 1） ? 物理內(nèi)存不足 – 物理內(nèi)存有限，例如只有 1G – 物理內(nèi)存很大，但是應(yīng)用很多，占用太多內(nèi)存 ? Swap區(qū)大小不夠 ? Weblogic Server壓力太大 – 并發(fā)用戶太多 – 大數(shù)據(jù)量分配應(yīng)用，例如統(tǒng)計(jì)報(bào)表 ? Permanent區(qū)太小 ? 用戶代碼內(nèi)存不釋放 – session放置了大量對(duì)象 – 在內(nèi)存分配大量數(shù)據(jù) – 用戶自己創(chuàng)建太多線程 – 調(diào)用 AWT等畫圖接口 ? 用戶代碼內(nèi)存泄漏問題 – jdbc連接沒有 close – 分配好的對(duì)象沒有 close和釋放 29 內(nèi)存不足和內(nèi)存泄漏錯(cuò)誤的典型原因（ 2） ? Weblogic Server配置不當(dāng) – 給 heap分配的內(nèi)存太多 – session timeout時(shí)間太長 – EJB pool和 Cache的太大 – JMS配置 ? Java內(nèi)存碎片 – 尤其在 IBM JDK上表現(xiàn)明顯 ? 第三方 Java應(yīng)用的內(nèi)存問題 – 第三方 Java應(yīng)用也存在內(nèi)存不足或者泄漏問題 ? 第三方本地代碼的內(nèi)存泄漏問題 – 第二類 JDBC驅(qū)動(dòng)的內(nèi)存泄漏，例如 Oracle Oci Driver – 其他第三方本地代碼的內(nèi)存泄漏 ? JVM本身的內(nèi)存問題 – JIT技術(shù)需要消耗更多的本地內(nèi)存 – JV