jvm內(nèi)存問題最佳實踐(更新版)

　　

【正文】 以降低緩存限值來減少總體堆大小 – 如果應(yīng)用程序使用了活動時間長的對象，請減少這些對象的數(shù)量或縮短它們的生命周期，例如，縮短 HTTP 會話的超時期間 – 調(diào)整垃圾回收策略，可能解決 OOM問題 – 查找內(nèi)存泄漏，例如，不正確的 JDBC 池連接處理 – 如果服務(wù)器只是對負載增加或添加應(yīng)用程序作出反應(yīng)，JVM 自然會需要更大的 Heap 46 分析 GC日志－－內(nèi)存緩慢增長 ?從 GC日志中看到內(nèi)存的緩慢增長 [GC 71678K61588K(98112K), secs] [GC 97999K87826K(98240K), secs] [GC 190603K170624K(191640K), secs] [GC 144325K121582K(225376K), secs] [GC 189537K162596K(257432K), secs] [GC 239766K210684K(277080K), secs] [GC 246611K208929K(359776K), secs] ??????? 47 分析 GC日志－－內(nèi)存碎片 ?從 GC日志中分析觀察到內(nèi)存碎片現(xiàn)象 – 這個問題多發(fā)生在 IBM JDK上，因為它采用的垃圾回收算法跟別的JDK不一致（注： IBM JDK GC輸入與上略有不同） – 在 Sun JDK / HP JDK不常見，很少出現(xiàn) ?調(diào)整策略 – IBM JDK： Xpactgc – Sun JDK：增加 young區(qū)大小 XX:NewRatio XX:NewSize XX:MaxNewSize XX:SurvivorRatio(詳細參見 Sun文檔 ) GC 減少了使用的堆，其大小已與最大 堆大小有明顯差距， OOM 卻依然出現(xiàn)！ 顯示在執(zhí)行 GC 后仍存在碎片的 GC 消息示例： [memory ] : GC 73043K72989K (131072K) in ms [memory ] : GC 72989K72905K (131072K) in ms [memory ] : GC 72905K72580K (131072K) in ms . . . 48 分析 GC日志－－ Permanent區(qū)不夠 ?從 GC日志中觀察到 – 這個問題發(fā)生在 Sun/HP JDK上，因為它采用 Permanent區(qū)來存放 Java的 class對象 – 這個問題的主要區(qū)別在于兩者發(fā)生的時間不一樣 ?調(diào)整策略 – 增加 Permanent區(qū)大小 – XX:MaxPermSize=256M（ 推薦 128M以上） OOM 卻依然出現(xiàn)！ 注意這種情況主要出現(xiàn) 在 WLS啟動不久，通常在 1－ 20分鐘內(nèi)。需要擴展到大型計算機上的應(yīng)用程序可以從這種策略中受益。應(yīng)用程序停頓的時間更短。 – 各種 JDK的垃圾回收都有多種算法和策略 ?以下 OutOfMemory 簡稱 OOM ?以下 Memory Leak 簡稱 ML ?Heap簡稱 “ 堆 ” 14 Java內(nèi)存問題的三種表現(xiàn)形式 1 ? Java內(nèi)存問題的三種表現(xiàn)形式： – GC次數(shù)過多，導(dǎo)致占用時間過長 – 內(nèi)存不足錯誤 – 內(nèi)存泄漏錯誤 ? GC占用時間過長－－系統(tǒng)明顯感覺比較慢 – Heap區(qū)、 Perm區(qū)分配內(nèi)存總量夠用 – 通過 verbose gc、 jstat觀察， GC占用時間超過總時間的 5%甚至更高 ? 內(nèi)存不足錯誤－－明確顯示出 – 沒有空閑內(nèi)存可供 JVM 或本地代碼用于分配新對象或內(nèi)存塊 – 在 Java 堆 或 本地內(nèi)存 中都可能發(fā)生 15 Java內(nèi)存問題的三種表現(xiàn)形式 2 ?內(nèi)存泄漏錯誤－－沒有錯誤信息，但是內(nèi)存幾乎耗盡 – 已經(jīng)分配好的內(nèi)存或?qū)ο螅敳辉傩枰?，沒有得到釋放 – 內(nèi)存曲線是一條斜向上的曲線 – 對 Java 堆 或 本地內(nèi)存 都可能產(chǎn)生這個問題 – 通常最終的狀態(tài)就會導(dǎo)致 OOM 錯誤 ?通常內(nèi)存泄漏 ML會導(dǎo)致 OOM錯誤，因此兩者的探查方法完全相同！ 16 Java內(nèi)存問題的兩個主要發(fā)生區(qū)段 ? Java內(nèi)存問題的兩個主要發(fā)生區(qū)段： – Java內(nèi)存－－包括 heap堆內(nèi)存和 permanent區(qū) – 本地內(nèi)存－－包括 JVM進程內(nèi)存和 java使用的第三方本地代碼 ? Java內(nèi)存分配不合理 – Java堆內(nèi)存充足，但是 S0、 S Eden、 Old區(qū)分配不合理 – Perm區(qū) Xms不足 Xmx充足，類動態(tài)加載引起 Perm增長導(dǎo)致 FULL GC ? Java內(nèi)存不足 – Java堆內(nèi)存 heap不足，無法再分配新對象或內(nèi)存塊 – permanent區(qū)內(nèi)存不足，無法再加載類到內(nèi)存中（ Sun amp。 ? Permanent區(qū)： – 是 Sun JDK和 HP JDK用來加載類 (class)的專門的內(nèi)存區(qū) – 這個區(qū)域不歸屬 Java 堆內(nèi)存 (heap)范圍 – 如果 Java應(yīng)用很大，例如類 (class)很多，那么建議增大這個區(qū)域的大小來滿足加載這些類的內(nèi)存需求 – 通過 – XX:PermSize=***M – XX:MaxPermSize=***M調(diào)整 10 Java內(nèi)存管理的基本概念 ?本地內(nèi)存 (native memory)： – 是 JVM 用于其內(nèi)部操作的本地內(nèi)存（非 Java內(nèi)存） – JNI 代碼和第三方本地模塊（例如，本地 JDBC 驅(qū)動 程序）也使用本地內(nèi)存 – 最大本地內(nèi)存大小取決于以下因素： ? 操作系統(tǒng)進程內(nèi)存大小限制 ? 已經(jīng)指定用于 Java 堆的內(nèi)存 ?進程內(nèi)存大?。? – 32位操作系統(tǒng)，理論最大值 2的 32次方＝ 4G – 64位操作系統(tǒng)下使用 64位的 JDK，按照現(xiàn)在的硬件條件，可以看做無限制 – 進程內(nèi)存 ＝ Java 內(nèi)存 ＋ 本地內(nèi)存 ＋ 加載的可執(zhí)行文件和庫 ＋ 操作系統(tǒng)保留內(nèi)存 11 Java內(nèi)存管理的基本概念 ? Java堆內(nèi)存大小的決定因素： – 進程大小限制， =4G – “ 加載的可執(zhí)行文件和庫＋系統(tǒng)保留內(nèi)存”不同操作系統(tǒng)和應(yīng)用不一樣，通常在百 M到 1G間 – JVM的本地內(nèi)存在不同的 JDK之間也不一樣。 – 其他操作系統(tǒng)請查看操作系統(tǒng)文檔和對應(yīng) JVM文檔 12 物理內(nèi)存和虛擬內(nèi)存 進程的虛擬內(nèi)存由 OS 映射到物理內(nèi)存。 – Garbage First (G1) Garbage Collector XX:+UnlockExperimentalVMOptions XX:+UseG1GC SUN JDK Update14引入，實際生產(chǎn)環(huán)境中還沒有采用 21 常見 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 =3600000 =3600000 verbose:gc XX:+PrintGCDetails XX:+PrintGCTimeStamps Xloggc:/tmp/server_gc$$.log 22 常見 GC算法 JRockit ?根據(jù)回收器，簡單分為： – XgcPrio:throughput 默認算法，主要用于桌面應(yīng)用 – XgcPrio:pausetime XgcPrio:pausetime XpauseTarget:210ms 因為免費，所以最低只能設(shè)置到 200ms。 – Xgcpolicy:subpool 采用與默認策略相似的算法，但是采用一種比較適合多處理器計算機的分配策略。 – 通常會導(dǎo)致 JVM異常退出，通常會產(chǎn)生 JVM 文本 Core文件和二進制核心文件。 ? JRA 包括以下兩個部分： – 收集有關(guān) JVM 和當前正在運行的 Java 應(yīng)用程序的數(shù)據(jù)。 ? 升級 – 升級 JDK – 升級操作系統(tǒng) – 升級 Weblogic Server 56 小節(jié)回顧 ? 如何識別 Java 內(nèi)存錯誤和本地內(nèi)存錯誤 ? 根據(jù) GC日志解決內(nèi)存問題 ? 解決 Java 內(nèi)存問題的步驟 ? 解決本地內(nèi)存問題的步驟 在本小節(jié)中，我們講述了以下內(nèi)容： 57 MENU ? 選擇合適的 Java虛擬機 ? Java內(nèi)存管理的基本概念 ? GC次數(shù)過多消耗時間過長的原因和癥狀 ? 內(nèi)存不足和內(nèi)存泄漏錯誤的原因和癥狀 ? 診斷、定位和解決內(nèi)存不足和內(nèi)存泄漏錯誤 ? 使用分析工具解決內(nèi)存不足和內(nèi)存泄漏錯誤 ? 預(yù)防內(nèi)存不足和內(nèi)存泄漏 ? OutOfMemory/Memory Leak錯誤實例 58 使用分析工具來分析 OOM問題 ?發(fā)生 Java Heap OOM 問題時，無法定位到問題，最終的辦法只能使用分析工具來做分析。039。239。239。14939。14239。12739。10739。9939。8139。 ?從 GC日志中看到， Heap區(qū)在極短時間內(nèi)被占光 ?物理系統(tǒng)足夠，空閑內(nèi)存足夠 94 OutOfMemory錯誤實例（ 2）問題 收集什么信息？？？ 95 OutOfMemory錯誤實例（ 2）答案 ?GC日志 ?系統(tǒng)參數(shù)，采用的第三方組件 ?用性能檢測工具分析 ?用 Eeclipse Memory Analyzer進行離線分析 96 OutOfMemory錯誤實例（ 3） － 分析 問題在哪里？？？ 97 OutOfMemory錯誤實例（ 3）過程和結(jié)果 ?用 Eeclipse Memory Analyzer分析顯示： – 內(nèi)存中存在 apache的 poi excel處理組件 – 根據(jù)業(yè)務(wù)系統(tǒng)的需要，升級到 64位 WebLogic MP3，問題解決 98 小節(jié)回顧 ? 兩個 OOM/ML解決實例 在本小節(jié)中，我們講述了以下內(nèi)容： 99 回顧 ? 內(nèi)存不足 /內(nèi)存泄漏的基本概念 ? 診斷和定位內(nèi)存問題 ? 故障排除步驟和方案 ? 應(yīng)用分析工具解決問題 ? OOM/ML實例 在本次 Webinar中，我們講述了以下內(nèi)容：