jvm內存問題最佳實踐(存儲版)

　　

【正文】 in 1068 ms ? GC(13): freed 36543728 bytes, 3% free (36543728/1073674752), in 1096 ms ? GC(14): freed 35539080 bytes, 6% free (72082808/1073674752), in 1154 ms ? ******************************************** ? GC(25): freed 36172752 bytes, 3% free (36172752/1073674752), in 1209 ms ? GC(26): freed 35313152 bytes, 6% free (71485904/1073674752), in 1186 ms ? GC(27): freed 1602776 bytes, 0% free (1602776/1073674752), in 934 ms ? GC(44): freed 17638904 bytes, 3% free (36564840/1073674752), in 1375 ms ? GC(45): freed 73536 bytes, 0% free (73536/1073674752), in 734 ms ? GC(47): freed 17252248 bytes, 1% free (17252248/1073674752), in 1425 ms ? GC(48): freed 9550608 bytes, 0% free (9550608/1073674752), in 1443 ms ? GC(49): freed 1014816904 bytes, 94% free (1014816904/1073674752), in 101 ms ? GC(50): freed 758913488 bytes, 91% free (979761952/1073674752), in 155 ms 88 OutOfMemory錯誤實例（ 1） － Thread Dump ? 1TISIGINFO OUTOFMEMORY received ? 1TIDATETIME Date: 2022/05/11 at 15:56:13 ? 1TIFILENAME Javacore filename: /bea/user_projects/domains/mydomain/ ? 1XHTIME Wed May 11 15:56:13 2022 ? 1XHSIGRECV Unexpected signal 1 received at 0x0 in unknown. Processing terminated. ? 1XHFULLVERSION J2RE IBM AIX build ca142020220626 ? 2CIUSERARG Xms1024m ? 2CIUSERARG Xmx1024m ? 2CIUSERARG verbose:gc ? 2CIUSERARG Xverbosegclog:/bea/ ? 1STHEAPFREE Bytes of Heap Space Free: 45b8 (17,848) ? 1STHEAPALLOC Bytes of Heap Space Allocated: 3ffefa00 (1,073,674,752) ? 2LKREGMON Heap lock (0x30071788): owner ExecuteThread: 39。 ?如果存在本地內存泄漏 – 增加物理內存，只能夠延緩故障發生，無法根除問題 54 處理本地內存 OOM（ 4） ? 從 GC日志中看到 Heap實際使用大小遠小于最大值，可以減少這個最大值，提供更多可用的本地內存 ? 如果 RAM 和交換空間不足，添加內存或者升級計算機 ? JVM 使用本地內存： – 加載類和生成代碼，但在啟動幾小時后，內存使用量通常會穩定下來 – 可能會發生運行時類加載和代碼優化（ JIT） – 禁用 JIT功能： ? 如果使用的是 JRockit， Xnoopt ? 如果使用的是 Sun/HP的 JDK， Xint ? 如果使用的是 IBM JDK， =NONE 55 處理本地內存 OOM（ 5） ? 最后，如果無法查明本地內存 OOM 錯誤的成因： – 請與 JVM 供應商聯系，找到跟蹤本地內存分配調用的方法 – 請與第三方模塊或 JNI 代碼供應商聯系，是否有調試 /跟蹤功能 ? 繼續收集和分析有關 OOM 錯誤發生時間和發生原因的信息 ? 如果存在多個成因，縮小探查范圍可能需要一些時間。 50 JRockit 功能 ? JRockit 支持 Java 運行時分析器 (Java Runtime Analyzer, JRA)： – 該分析器對 JRockit JVM 及 JRockit 上運行的 Java 應用程序都能夠進行運行時性能分析。 – 如果 JVM 或任何其它已加載的模塊（例如， libc 或第 三方模塊）不處理異常， OS 將通過 sigabort 強制 JVM 退出。采用這種策略時，具有許多短期存活對象的應用程序會表現出更短的停頓時間，同時仍然產生很好的吞吐量。 JDK ，默認啟用了 XX:+UseParallelOldGC，性能大為提高 – 并發 (Concurrent Low Pause Collector) – XX:+UseConcMarkSweepGC 啟用該參數，默認啟用了 XX:+UseParNewGC；簡單的說，并發是指用戶線程與垃圾收集線程并發，程序在繼續運行，而垃圾收集程序運行于其他 CPU上。 Windows Advance Server最大支持 3G模式。 JRockit相對 Sun JDK，做了非常好的 JIT優化，但是本地內存要求更多的空間 – 通常 Java堆內存大小推薦不大于 2G – 目前 Unix/Linux操作系統默認已經做了內核調整 開啟了大內存模式，可以上到 2G以上 ? Java堆內存的大內存模式： – AIX上 Java堆內存有大內存模式（ LAM），最大支持到 – Window上有連續地址空間限制，通常不大于 。 Hp JDK） ? 本地內存不足 – 物理內存不夠，無法再得到內存 – 第三方本地代碼有內存泄漏的 Bug，例如 oracle oci driver本地代碼 – JVM的 JIT或者 JVM本身的 Bug 17 小節回顧 ? Java進程的內存分類 ? Java堆內存 (Heap) ? Java Permanent區 ? Java本地代碼 ? Java內存問題的三個表現類型 ? Java內存問題的兩個發生區段 在本小節中，我們講述了以下內容： 18 MENU ? 選擇合適的 Java虛擬機 ? Java內存管理的基本概念 ? GC次數過多消耗時間過長的原因和癥狀 ? 內存不足和內存泄漏錯誤的原因和癥狀 ? 診斷、定位和解決內存不足和內存泄漏錯誤 ? 使用分析工具解決內存不足和內存泄漏錯誤 ? 預防內存不足和內存泄漏 ? OutOfMemory/Memory Leak錯誤實例 19 常見 GC概念 ?調整 GC前提： – 程序是健康的 – Heap區 (Xmx)夠大，日志中沒有 OutOfMemory異常 – 花在 GC上面的總時間占用太高，比如超過 5% ?常見 GC算法： – SUN、 HP的 GC算法 – JRockit的 GC算法 – IBM JDK的 GC算法 ?GC算法： – 選擇 GC算法的指導思想 20 常見 GC算法 SUN、 HP（ 1） ? 根據回收器，簡單分為： – 串行 – XX:+UseSerialGC Out of Box算法，年輕代串行復制，年老代串行標記整理，主要用于桌面應用 – 并行 – XX:+UseParallelGC 年輕代暫停應用程序，多個垃圾收集線程并行的復制收集，年老代暫停應用程序，與串行收集器一樣，單垃圾收集線程標記整理。 – Xgcpolicy:gencon 以不同方式處理短期存活的對象和長期存活的對象。 ? 示例： – Xms768m Xmx1024m Xmn256m Xgcpolicy:gencon 24 選擇合適的 GC算法 ? 選擇 GC算法，遵循以下原則： – 評估程序類型 桌面應用還是服務器端應用 吞吐量優先還是響應時間優先 – 僅適用 64位 JDK的算法 比如在 IBM AIX 64位 JDK環境下，當 heap區大于 16G后， subpool明顯性能提高 – 確定 GC算法之后，再逐步調整小參數 Xmn(XX:NewSize XX:MaxNewSize) XX:SurvivorRatio XX:MaxTenuringThreshold ....... – 測試期間實時監控 SUN、 HP、 JRockit都可以通過 jstat命令進行實時監控 避免使用 jmap histo，原因是可能會造成 Full GC 25 小節回顧 ? GC概念 ? 常見 GC算法 ? 選擇合適的 GC算法 在本小節中，我們講述了以下內容： 26 MENU ? 選擇合適的 Java虛擬機 ? Java內存管理的基本概念 ? GC次數過多消耗時間過長的原因和癥狀 ? 內存不足和內存泄漏錯誤的原因和癥狀 ? 診斷、定位和解決內存不足和內存泄漏錯誤 ? 使用分析工具解決內存不足和內存泄漏錯誤 ? 預防內存不足和內存泄漏 ? OutOfMemory/Memory Leak錯誤實例 27 Java內存問題的主要發生在 ?操作系統本身 ?Java內存區： – heap堆內存 – permanent區 ?本地內存區： – JVM進程內存 – Java使用的第三方本地代碼 28 內存不足和內存泄漏錯誤的典型原因（ 1） ? 物理內存不足 – 物理內存有限，例如只有 1G – 物理內存很大，但是應用很多，占用太多內存 ? Swap區大小不夠 ? Weblogic Server壓力太大 – 并發用戶太多 – 大數據量分配應用，例如統計報表 ? Permanent區太小 ? 用戶代碼內存不釋放 – session放置了大量對象 – 在內存分配大量數據 – 用戶自己創建太多線程 – 調用 AWT等畫圖接口 ? 用戶代碼內存泄漏問題 – jdbc連接沒有 close – 分配好的對象沒有 close和釋放 29 內存不足和內存泄漏錯誤的典型原因（ 2） ? Weblogic Server配置不當 – 給 heap分配的內存太多 – session timeout時間太長 – EJB pool和 Cache的太大 – JMS配置 ? Java內存碎片 – 尤其在 IBM JDK上表現明顯 ? 第三方 Java應用的內存問題 – 第三方 Java應用也存在內存不足或者泄漏問題 ? 第三方本地代碼的內存泄漏問題 – 第二類 JDBC驅動的內存泄漏，例如 Oracle Oci Driver – 其他第三方本地代碼的內存泄漏 ? JVM本身的內存問題 – JIT技術需要消耗更多的本地內存 – JV