【正文】 以降低緩存限值來減少總體堆大小 – 如果應(yīng)用程序使用了活動(dòng)時(shí)間長的對象，請減少這些對象的數(shù)量或縮短它們的生命周期，例如，縮短 HTTP 會(huì)話的超時(shí)期間 – 調(diào)整垃圾回收策略，可能解決 OOM問題 – 查找內(nèi)存泄漏，例如，不正確的 JDBC 池連接處理 – 如果服務(wù)器只是對負(fù)載增加或添加應(yīng)用程序作出反應(yīng)，JVM 自然會(huì)需要更大的 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)象 – 這個(gè)問題多發(fā)生在 IBM JDK上，因?yàn)樗捎玫睦厥账惴ǜ鷦e的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(詳細(xì)參見 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日志中觀察到 – 這個(gè)問題發(fā)生在 Sun/HP JDK上，因?yàn)樗捎?Permanent區(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)。需要擴(kuò)展到大型計(jì)算機(jī)上的應(yīng)用程序可以從這種策略中受益。應(yīng)用程序停頓的時(shí)間更短。 – 各種 JDK的垃圾回收都有多種算法和策略 ?以下 OutOfMemory 簡稱 OOM ?以下 Memory Leak 簡稱 ML ?Heap簡稱 “ 堆 ” 14 Java內(nèi)存問題的三種表現(xiàn)形式 1 ? Java內(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)存總量夠用 – 通過 verbose gc、 jstat觀察， GC占用時(shí)間超過總時(shí)間的 5%甚至更高 ? 內(nèi)存不足錯(cuò)誤－－明確顯示出 – 沒有空閑內(nèi)存可供 JVM 或本地代碼用于分配新對象或內(nèi)存塊 – 在 Java 堆 或 本地內(nèi)存 中都可能發(fā)生 15 Java內(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ò)誤，因此兩者的探查方法完全相同！ 16 Java內(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、 S Eden、 Old區(qū)分配不合理 – Perm區(qū) Xms不足 Xmx充足，類動(dòng)態(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ū) – 這個(gè)區(qū)域不歸屬 Java 堆內(nèi)存 (heap)范圍 – 如果 Java應(yīng)用很大，例如類 (class)很多，那么建議增大這個(gè)區(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ū)動(dòng) 程序）也使用本地內(nèi)存 – 最大本地內(nèi)存大小取決于以下因素： ? 操作系統(tǒng)進(jìn)程內(nèi)存大小限制 ? 已經(jīng)指定用于 Java 堆的內(nèi)存 ?進(jìn)程內(nèi)存大小： – 32位操作系統(tǒng)，理論最大值 2的 32次方＝ 4G – 64位操作系統(tǒng)下使用 64位的 JDK，按照現(xiàn)在的硬件條件，可以看做無限制 – 進(jìn)程內(nèi)存 ＝ Java 內(nèi)存 ＋ 本地內(nèi)存 ＋ 加載的可執(zhí)行文件和庫 ＋ 操作系統(tǒng)保留內(nèi)存 11 Java內(nèi)存管理的基本概念 ? Java堆內(nèi)存大小的決定因素： – 進(jìn)程大小限制， =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)存 進(jìn)程的虛擬內(nèi)存由 OS 映射到物理內(nèi)存。 – Garbage First (G1) Garbage Collector XX:+UnlockExperimentalVMOptions XX:+UseG1GC SUN JDK Update14引入，實(shí)際生產(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 默認(rèn)算法，主要用于桌面應(yīng)用 – XgcPrio:pausetime XgcPrio:pausetime XpauseTarget:210ms 因?yàn)槊赓M(fèi)，所以最低只能設(shè)置到 200ms。 – Xgcpolicy:subpool 采用與默認(rèn)策略相似的算法，但是采用一種比較適合多處理器計(jì)算機(jī)的分配策略。 – 通常會(huì)導(dǎo)致 JVM異常退出，通常會(huì)產(chǎn)生 JVM 文本 Core文件和二進(jìn)制核心文件。 ? JRA 包括以下兩個(gè)部分： – 收集有關(guān) JVM 和當(dāng)前正在運(yùn)行的 Java 應(yīng)用程序的數(shù)據(jù)。 ? 升級 – 升級 JDK – 升級操作系統(tǒng) – 升級 Weblogic Server 56 小節(jié)回顧 ? 如何識別 Java 內(nèi)存錯(cuò)誤和本地內(nèi)存錯(cuò)誤 ? 根據(jù) GC日志解決內(nèi)存問題 ? 解決 Java 內(nèi)存問題的步驟 ? 解決本地內(nèi)存問題的步驟 在本小節(jié)中，我們講述了以下內(nèi)容： 57 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í)例 58 使用分析工具來分析 OOM問題 ?發(fā)生 Java Heap OOM 問題時(shí)，無法定位到問題，最終的辦法只能使用分析工具來做分析。039。239。239。14939。14239。12739。10739。9939。8139。 ?從 GC日志中看到， Heap區(qū)在極短時(shí)間內(nèi)被占光 ?物理系統(tǒng)足夠，空閑內(nèi)存足夠 94 OutOfMemory錯(cuò)誤實(shí)例（ 2）問題 收集什么信息？？？ 95 OutOfMemory錯(cuò)誤實(shí)例（ 2）答案 ?GC日志 ?系統(tǒng)參數(shù)，采用的第三方組件 ?用性能檢測工具分析 ?用 Eeclipse Memory Analyzer進(jìn)行離線分析 96 OutOfMemory錯(cuò)誤實(shí)例（ 3） － 分析 問題在哪里？？？ 97 OutOfMemory錯(cuò)誤實(shí)例（ 3）過程和結(jié)果 ?用 Eeclipse Memory Analyzer分析顯示： – 內(nèi)存中存在 apache的 poi excel處理組件 – 根據(jù)業(yè)務(wù)系統(tǒng)的需要，升級到 64位 WebLogic MP3，問題解決 98 小節(jié)回顧 ? 兩個(gè) OOM/ML解決實(shí)例 在本小節(jié)中，我們講述了以下內(nèi)容： 99 回顧 ? 內(nèi)存不足 /內(nèi)存泄漏的基本概念 ? 診斷和定位內(nèi)存問題 ? 故障排除步驟和方案 ? 應(yīng)用分析工具解決問題 ? OOM/ML實(shí)例 在本次 Webinar中，我們講述了以下內(nèi)容：