【正文】 是否有明確的 OutOfMemory錯誤信息顯示 – 是否明確的看到內(nèi)存曲線一直在頂部 – 是否 GC日志明確顯示內(nèi)存緊張 ? 不明確的信息，但是可以歸到 OOM/ML錯誤 – 需要更多信息來證實 – GC日志 – Thread Dump – 文本 Core文件 – 通?？梢詺w到 OOM/ML錯誤的可能癥狀： – Weblogic Server不響應(yīng)，很慢 – GC異常，例如 heap使用到頂， GC時間很長 – Thread Dump顯示幾乎所有的線程都在等待，只有 GC線程在工作 – Core文件指出信號量為 1/0/4/10/11 38 查看現(xiàn)場 /收集信息 (1) ?物理內(nèi)存大小 – 如果物理內(nèi)存不夠，請增加物理內(nèi)存 ?Java進程內(nèi)存大小 – 如果 Java進程內(nèi)存不大，只有幾百 M或者 1G左右，要結(jié)合并發(fā)用戶和 GC日志來考慮 – 如果 Java進程內(nèi)存特別大，例如到 ，結(jié)合 heap設(shè)置綜合考慮。這種策略只能在 IBM pSeries174。對于吞吐量比短暫的 GC 停頓更重要的應(yīng)用程序，通常使用這種策略。 進程 C 的 虛擬內(nèi)存 可執(zhí)行 文件 /庫 Java 堆 保留供 OS 使用 本地內(nèi)存 進程 D 的 虛擬內(nèi)存 可執(zhí)行 文件 /庫 Java 堆 保留供 OS 使用 本地內(nèi)存 RAM 交換空間 JVM 啟動時將保留堆 13 Java內(nèi)存管理的基本概念 ?垃圾回收 (Garbage Collection, GC)： – JVM自動檢測和釋放不再使用的內(nèi)存。JVM內(nèi)存問題最佳實踐 JVM Best Practice 曾凡光 2022年 03月 JVM內(nèi)存問題最佳實踐 本次技術(shù)交流，涵蓋范圍為： ?如何選擇合適的 Java虛擬機 ?了解 Java基本內(nèi)存管理基本概念 ?了解發(fā)生內(nèi)存不足 /內(nèi)存泄漏錯誤的原因和癥狀 ?了解如何診斷內(nèi)存不足 /內(nèi)存泄漏 錯誤 ?了解如何解決 內(nèi)存不足 /內(nèi)存泄漏錯誤 3 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錯誤實例 4 Java虛擬機的種類 ? Oracle Java虛擬機 – 原 Sun Java虛擬機 – 原 BEA JRockit – 兩種 Java虛擬機，都運行在 Windows、 Linux、 Solaris平臺 ? HP Java虛擬機 ： – 與 SUN JDK基本兼容，有自己獨特的啟動參數(shù) – 運行在 HP UNIX上 ? IBM Java虛擬機： – 與 Sun JDK基本兼容 – 啟動參數(shù)的寫法風(fēng)格與 Sun JDK、 HP JDK非常不同 – 主要用于 WebSphere、跑在 AIX上的中間件服務(wù)器 ? 開源 Java虛擬機 ： – 與 SUN JDK兼容 5 如何選擇合適的 Java虛擬機 ?選擇穩(wěn)定的 JDK： – 剛剛 GA的版本不穩(wěn)定，比如 – 剛增加新特性的版本不穩(wěn)定，比如 – 安裝 JDK之前，先看廠商的 Release Notes ?根據(jù)平臺和應(yīng)用，選擇合適廠商的 JDK： – HPUX只能選擇 HP JDK， AIX只能選擇 IBM JDK – Windows、 Linux可以選擇 SUN JDK和 JRockit – Solaris平臺，最好使用 SUN JDK – 開源 JDK，目前生產(chǎn)環(huán)境中用的極少 6 Java虛擬機 32 VS 64 ? 盡量選擇使用 32位 JDK： – 32位 JDK在 TPS測試中，結(jié)果比 64位 JDK要好 。 – Java 運行時 JVM會執(zhí)行 GC，這樣程序員不再需要顯式釋放對象。每當(dāng)進行垃圾收集時，應(yīng)用程序都會停頓。 和 zSeries174。如果 heap設(shè)置不大 1G左右，那么需要考慮本地內(nèi)存泄漏的可能 ?剩余可用內(nèi)存 – 結(jié)合物理總內(nèi)存， Java進程內(nèi)存綜合考慮是否合理 ?Swap區(qū)大小 – Swap區(qū)通常建議是物理內(nèi)存的 2－ 3倍 39 查看現(xiàn)場 /收集信息 (2) ? 查看 GC log 或 進 console查看內(nèi)存使用曲線 – 并發(fā)用戶數(shù)量 /主要業(yè)務(wù)類型分析 – 當(dāng)時并發(fā)用戶數(shù)量以及 session大小分析 – 主要業(yè)務(wù)類型分析，是否有大內(nèi)存占用的業(yè)務(wù)，例如統(tǒng)計報表等等 ? 立即做 thread dump幫助分析 – 每隔 30秒做一次，做 3次 – Unix/Linux : kill 3 pid – Windows : Ctrl+break ? 收集操作系統(tǒng) /JDK/WLS信息 – 操作系統(tǒng)版本信息 – JDK版本信息 – WebLogic Server版本信息 ? 是否使用了第三方本地代碼 40 查看現(xiàn)場 /收集信息－－措施 ? 調(diào)整措施 – 增加物理內(nèi)存 – 調(diào)整合理的 Heap設(shè)置 – 調(diào)整 Swap區(qū)大小 ? 繼續(xù)跟蹤 – 通過 Java進程內(nèi)存大小和 Heap大小判斷 ? Java堆內(nèi)存問題 ? 本地內(nèi)存問題 – 加上 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 – 繼續(xù)下一步 – 分析 GC日志 41 分析 GC日志－－ 完整 GC 的輸出 ?不同的 JDK將產(chǎn)生不同格式 GC日志，以下分析以 Sun JDK標(biāo)準(zhǔn) GC日志為準(zhǔn) ?不同的 JDK有各自的其他豐富信息的 GC開關(guān)選項 ?完整 GC 將產(chǎn)生類似如下內(nèi)容的消息： [memory ] start: GC beforeKafterK (heapK), total ms 其中： start GC 的開始時間（秒），從 JVM 啟動開始計算 before 回收前對象所使用的內(nèi)存 (KB) after 回收后對象所使用的內(nèi)存 (KB) size 回收后的堆大小 (KB) total 執(zhí)行回收的總時間（毫秒）。 – 定期監(jiān)視進程內(nèi)存大?。? ? 在 Unix/Linux 上，使用 ps p PID o vsz 或者 top命令 ? 在 Windows 上，使用 perfmon 工具。MDD4J 在本小節(jié)中，我們學(xué)習(xí)了以下內(nèi)容： 77 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錯誤實例 78 預(yù)防內(nèi)存不足和內(nèi)存泄漏 ?最好的補救不如事先的預(yù)防 ?預(yù)防內(nèi)存不足和內(nèi)存泄漏 – 系統(tǒng)管理 – 代碼編寫 79 預(yù)防內(nèi)存不足和內(nèi)存泄漏－系統(tǒng)管理 ? 系統(tǒng)管理 – 足夠的物理內(nèi)存，適當(dāng)?shù)?Swap區(qū)大小 – 最佳的 HEAP內(nèi)存設(shè)置 – 使用最新的操作系統(tǒng) /最新的 JDK/最新版本的 WLS – 使用 Weblogic Server認(rèn)證的 JDK – 盡量少使用第三方本地代碼，或使用 Java替代方案 – 對 Sun JDK，合適的 Permanent區(qū)大小 – 適當(dāng)?shù)睦厥账惴ê筒呗? – 適當(dāng)?shù)?HttpSession Timeout時間 – 適當(dāng)?shù)?EJB Pool/Cache – 適當(dāng)?shù)?weblogic server調(diào)優(yōu) 80 預(yù)防內(nèi)存不足和內(nèi)存泄漏－代碼編寫 ?代碼編寫 – 不要放置大量對象到 Session中 – 不要緩存太多數(shù)據(jù) – 用完的資源一定要 close()，例如 IO， File， JDBC連接 – 不要違反 J2EE規(guī)范。 (0x7BA1EC20), entry count 2 ? 3LKWAITERQ Waiting to enter: ? 3LKWAITER ExecuteThread: 39。 (0x7BD332A0) ? 3LKWAITER ExecuteThread: 39。 (0x7BA1FEA0) ? 3LKWAITER ExecuteThread: 39。 (0x7B4AE3A0) ? 3LKWAITER ExecuteThread: 39。 (0x7B0F8F20) ? 3LKWAITER ExecuteThread: 39。 (0x7A906D20) ? 3LKWAITER ExecuteThread: 39。 (0x79E6EA20) ? 3LKWAITER ExecuteThread: 39。 (0x79A2EA20) ? 3LKWAITER ExecuteThread: 39。 (TID:0x30106330, sys_thread_t:0x790A5AA0, state:CW, native ID:0x5B5C) prio=5 ? 4XESTACKTRACE at (Native Method) ? 4XESTACKTRACE at (:443) ? 4XESTACKTRACE at (:153) ? 4XESTACKTRACE at (:172) ? 3XMTHREADINFO ExecuteThread: 39。 for queue: 39。 for queue: 39。 for queue: 39。 for queue: 39。 for queue: 39。 for queue: 39。 for queue: 39。 for queue: 39。 for queue: 39。自動產(chǎn)生 heapdump和 javacore文件 ?只能重啟 。 – 還要檢查計算機的物理內(nèi)存總量（ RAM 和交換空間 之和）是否足以滿足所有正在運行的進程的需要 52 處理本地內(nèi)存 OOM（ 2） ? 請記住，進程內(nèi)存大?。? – 是進程運行時所占用的地址空間 – 受 OS 進程大小值的限制： ? 32 位 Unix：進程大小限值為 4GB，保留 12GB 供 OS 自己使用 ? Red Hat Linux AS ：可供應(yīng)用程序使用的進程大小為 3GB ? Windows：進程大小限值為 2GB（缺省值），但可以增加到 3GB – 包括 Java 堆內(nèi)存， JVM 在服務(wù)器啟動時會保留指定的最大值 – 還可能由 JNI 代碼或本地模塊（例如，本地 JDBC 驅(qū)動程序） 進行分配 – 還會受計算機物理內(nèi)存及計算機中運行的其它進程的限制。 45 針對 Java 堆 OOM 的應(yīng)用程序分析 ?如果 JVM 正確執(zhí)行了 GC，則應(yīng)該是應(yīng)用程序問題所致： – 如果應(yīng)用程序使用了緩存對象： ? 請確保對緩存對象數(shù)量施加了限制 ? 或許可