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

　　

【正文】 8139。10739。14239。239。039。 ? JRA 包括以下兩個部分： – 收集有關 JVM 和當前正在運行的 Java 應用程序的數據。 – Xgcpolicy:subpool 采用與默認策略相似的算法，但是采用一種比較適合多處理器計算機的分配策略。 – 其他操作系統請查看操作系統文檔和對應 JVM文檔 12 物理內存和虛擬內存 進程的虛擬內存由 OS 映射到物理內存。 – 各種 JDK的垃圾回收都有多種算法和策略 ?以下 OutOfMemory 簡稱 OOM ?以下 Memory Leak 簡稱 ML ?Heap簡稱 “ 堆 ” 14 Java內存問題的三種表現形式 1 ? Java內存問題的三種表現形式： – GC次數過多，導致占用時間過長 – 內存不足錯誤 – 內存泄漏錯誤 ? GC占用時間過長－－系統明顯感覺比較慢 – Heap區、 Perm區分配內存總量夠用 – 通過 verbose gc、 jstat觀察， GC占用時間超過總時間的 5%甚至更高 ? 內存不足錯誤－－明確顯示出 – 沒有空閑內存可供 JVM 或本地代碼用于分配新對象或內存塊 – 在 Java 堆 或 本地內存 中都可能發生 15 Java內存問題的三種表現形式 2 ?內存泄漏錯誤－－沒有錯誤信息，但是內存幾乎耗盡 – 已經分配好的內存或對象，當不再需要，沒有得到釋放 – 內存曲線是一條斜向上的曲線 – 對 Java 堆 或 本地內存 都可能產生這個問題 – 通常最終的狀態就會導致 OOM 錯誤 ?通常內存泄漏 ML會導致 OOM錯誤，因此兩者的探查方法完全相同！ 16 Java內存問題的兩個主要發生區段 ? Java內存問題的兩個主要發生區段： – Java內存－－包括 heap堆內存和 permanent區 – 本地內存－－包括 JVM進程內存和 java使用的第三方本地代碼 ? Java內存分配不合理 – Java堆內存充足，但是 S0、 S Eden、 Old區分配不合理 – Perm區 Xms不足 Xmx充足，類動態加載引起 Perm增長導致 FULL GC ? Java內存不足 – Java堆內存 heap不足，無法再分配新對象或內存塊 – permanent區內存不足，無法再加載類到內存中（ Sun amp。需要擴展到大型計算機上的應用程序可以從這種策略中受益。 – 還要檢查計算機的物理內存總量（ RAM 和交換空間 之和）是否足以滿足所有正在運行的進程的需要 52 處理本地內存 OOM（ 2） ? 請記住，進程內存大小： – 是進程運行時所占用的地址空間 – 受 OS 進程大小值的限制： ? 32 位 Unix：進程大小限值為 4GB，保留 12GB 供 OS 自己使用 ? Red Hat Linux AS ：可供應用程序使用的進程大小為 3GB ? Windows：進程大小限值為 2GB（缺省值），但可以增加到 3GB – 包括 Java 堆內存， JVM 在服務器啟動時會保留指定的最大值 – 還可能由 JNI 代碼或本地模塊（例如，本地 JDBC 驅動程序） 進行分配 – 還會受計算機物理內存及計算機中運行的其它進程的限制。 for queue: 39。 for queue: 39。 for queue: 39。 for queue: 39。 for queue: 39。 (0x79A2EA20) ? 3LKWAITER ExecuteThread: 39。 (0x7A906D20) ? 3LKWAITER ExecuteThread: 39。 (0x7B4AE3A0) ? 3LKWAITER ExecuteThread: 39。 (0x7BD332A0) ? 3LKWAITER ExecuteThread: 39。MDD4J 在本小節中，我們學習了以下內容： 77 MENU ? 選擇合適的 Java虛擬機 ? Java內存管理的基本概念 ? GC次數過多消耗時間過長的原因和癥狀 ? 內存不足和內存泄漏錯誤的原因和癥狀 ? 診斷、定位和解決內存不足和內存泄漏錯誤 ? 使用分析工具解決內存不足和內存泄漏錯誤 ? 預防內存不足和內存泄漏 ? OutOfMemory/Memory Leak錯誤實例 78 預防內存不足和內存泄漏 ?最好的補救不如事先的預防 ?預防內存不足和內存泄漏 – 系統管理 – 代碼編寫 79 預防內存不足和內存泄漏－系統管理 ? 系統管理 – 足夠的物理內存，適當的 Swap區大小 – 最佳的 HEAP內存設置 – 使用最新的操作系統 /最新的 JDK/最新版本的 WLS – 使用 Weblogic Server認證的 JDK – 盡量少使用第三方本地代碼，或使用 Java替代方案 – 對 Sun JDK，合適的 Permanent區大小 – 適當的垃圾回收算法和策略 – 適當的 HttpSession Timeout時間 – 適當的 EJB Pool/Cache – 適當的 weblogic server調優 80 預防內存不足和內存泄漏－代碼編寫 ?代碼編寫 – 不要放置大量對象到 Session中 – 不要緩存太多數據 – 用完的資源一定要 close()，例如 IO， File， JDBC連接 – 不要違反 J2EE規范。如果 heap設置不大 1G左右，那么需要考慮本地內存泄漏的可能 ?剩余可用內存 – 結合物理總內存， Java進程內存綜合考慮是否合理 ?Swap區大小 – Swap區通常建議是物理內存的 2－ 3倍 39 查看現場 /收集信息 (2) ? 查看 GC log 或 進 console查看內存使用曲線 – 并發用戶數量 /主要業務類型分析 – 當時并發用戶數量以及 session大小分析 – 主要業務類型分析，是否有大內存占用的業務，例如統計報表等等 ? 立即做 thread dump幫助分析 – 每隔 30秒做一次，做 3次 – Unix/Linux : kill 3 pid – Windows : Ctrl+break ? 收集操作系統 /JDK/WLS信息 – 操作系統版本信息 – JDK版本信息 – WebLogic Server版本信息 ? 是否使用了第三方本地代碼 40 查看現場 /收集信息－－措施 ? 調整措施 – 增加物理內存 – 調整合理的 Heap設置 – 調整 Swap區大小 ? 繼續跟蹤 – 通過 Java進程內存大小和 Heap大小判斷 ? Java堆內存問題 ? 本地內存問題 – 加上 GC Flag來分析 ? IBM JDK ? verbose:gc Xverbosegclog:path_GC_log_file_name ? HP JDK ? Xverbosegc[:help]|[0|1][:file=[stdout|stderr|filename]] Xloggc ? Sun JDK / BEA Jrockit ? verbose:gc – 繼續下一步 – 分析 GC日志 41 分析 GC日志－－ 完整 GC 的輸出 ?不同的 JDK將產生不同格式 GC日志，以下分析以 Sun JDK標準 GC日志為準 ?不同的 JDK有各自的其他豐富信息的 GC開關選項 ?完整 GC 將產生類似如下內容的消息： [memory ] start: GC beforeKafterK (heapK), total ms 其中： start GC 的開始時間（秒），從 JVM 啟動開始計算 before 回收前對象所使用的內存 (KB) after 回收后對象所使用的內存 (KB) size 回收后的堆大小 (KB) total 執行回收的總時間（毫秒）。每當進行垃圾收集時，應用程序都會停頓。JVM內存問題最佳實踐 JVM Best Practice 曾凡光 2022年 03月 JVM內存問題最佳實踐 本次技術交流，涵蓋范圍為： ?如何選擇合適的 Java虛擬機 ?了解 Java基本內存管理基本概念 ?了解發生內存不足 /內存泄漏錯誤的原因和癥狀 ?了解如何診斷內存不足 /內存泄漏 錯誤 ?了解如何解決 內存不足 /內存泄漏錯誤 3 MENU ? 選擇合適的 Java虛擬機 ? Java內存管理的基本概念 ? GC次數過多消耗時間過長的原因和癥狀 ? 內存不足和內存泄漏錯誤的原因和癥狀 ? 診斷、定位和解決內存不足和內存泄漏錯誤 ? 使用分析工具解決內存不足和內存泄漏錯誤 ? 預防內存不足和內存泄漏 ? OutOfMemory錯誤實例 4 Java虛擬機的種類 ? Oracle Java虛擬機 – 原 Sun Java虛擬機 – 原 BEA JRockit – 兩種 Java虛擬機，都運行在 Windows、 Linux、 Solaris平臺 ? HP Java虛擬機 ： – 與 SUN JDK基本兼容，有自己獨特的啟動參數 – 運行在 HP UNIX上 ? IBM Java虛擬機： – 與 Sun JDK基本兼容 – 啟動參數的寫法風格與 Sun JDK、 HP JDK非常不同 – 主要用于 WebSphere、跑在 AIX上的中間件服務器 ? 開源 Java虛擬機 ： – 與 SUN JDK兼容 5 如何選擇合適的 Java虛擬機 ?選擇穩定的 JDK： – 剛剛 GA的版本不穩定，比如 – 剛增加新特性的版本不穩定，比如 – 安裝 JDK之前，先看廠商的 Release Notes ?根據平臺和應用，選擇合適廠商的 JDK： – HPUX只能選擇 HP JDK， AIX只能選擇 IBM JDK – Windows、 Linux可以選擇 SUN JDK和 JRockit – Solaris平臺，最好使用 SUN JDK – 開源 JDK，目前生產環境中用的極少 6 Java虛擬機 32 VS 64 ? 盡量選擇使用 32位 JDK： – 32位 JDK在 TPS測試中，結果比 64位 JDK要好 。對于吞吐量比短暫的 GC 停頓更重要的應用程序，通常使用這種策略。 Hp JDK hs_err_pid****.log文件 – JRockit JDK – jrockit.****.dump文件 ? 文本 Core文件包含 JVM退出時收到的信號量，并會用 *標識導致退出的lib庫文件 – Signal 1 – Signal 0 – Signal 4 – Signal 10 – Signal 11 – 實踐表明，收到以上的信號量，通常但不絕對，表明 JVM的內存出現問題 – 需要結合 thread dump或者 GC日志來分析 33 小節回顧 ? 內存不足和內存泄漏錯誤的典型原因 ? OOM 錯誤的類型及相關故障癥狀 ? 文本 Core文件 在本小節中，我們講述了以下內容： 34 MENU ? 選擇合適的 Java虛擬機 ? Java內存管理的基本概念 ? GC次數過多消耗時間過長的原因和癥狀 ? 內存不足和內存泄漏錯誤的原因和癥狀 ? 診斷、定位和解決內存不足和內存泄漏錯誤 ? 使用分析工具解決內存不足和內存泄漏錯誤 ? 預防內存不足和內存泄漏 ? OutOfMemory/Memory Leak錯誤實例