使用 NMT 和 pmap 解決 JVM 資源洩漏問題

編者按：筆者使用 JDK 自帶的記憶體跟蹤工具 NMT 和 Linux 自帶的 pmap 解決了一個非常典型的資源洩漏問題。這個資源洩漏是由於 Java 程式設計師不正確地使用 Java API 導致的，使用 Files.list 開啟的檔案描述符必須關閉。本案例一方面介紹了怎麼使用 NMT 解決 JVM 資源洩漏問題，如果讀者遇到類似問題，可以嘗試用 NMT 來解決；另一方面也提醒 Java 開發人員使用 Java API 時需要必須弄清楚 API 使用規範，希望大家通過這個案例有所收穫。

背景知識：

NMT

NMT 是 Native Memory Tracking 的縮寫，一個 JDK 自帶的小工具，用來跟蹤 JVM 本地記憶體分配情況（本地記憶體指的是 non-heap，例如 JVM 在執行時需要分配一些輔助資料結構用於自身的執行）。

NMT 功能預設關閉，可以在 Java 程式啟動引數中加入以下引數來開啟：

-XX:NativeMemoryTracking=[summary | detail]

其中，"summary" 和 "detail" 的差別主要在輸出資訊的詳細程度。

開啟 NMT 功能後，就可以使用 JDK 提供的 jcmd 命令來讀取 NMT 採集的資料了，具體命令如下：

jcmd <pid>  VM.native_memory [summary | detail | baseline | summary.diff | detail.diff | shutdown]

NMT 引數的含義可以通過 "jcmd <pid>  help VM.native_memory" 命令查詢。通過 NMT 工具，我們可以快速區分記憶體洩露是否源自 JVM 分配。

pmap

對於非 JVM 分配的記憶體，經常需要用到 pmap 這個工具了，這是一個 linux 系統自帶工具，能夠從系統層面輸出目標程序記憶體使用的詳細情況，用法非常簡單：

pmap [引數] <pid>

常用的選項是 "-x" 或 "-X"，都是用來控制輸出資訊的詳細程度。

上圖是 pmap 部分輸出資訊，每列含義為

現象：

某業務叢集中，多個節點出現業務程序記憶體消耗緩慢增長現象，以其中一個節點為例：

如圖所示，這個業務程序當前佔用了 4.7G 的虛擬記憶體空間，以及 2.2G 的實體記憶體。已知正常狀態下該業務程序的實體記憶體佔用量不超過 1G。

分析：

使用命令 "jcmd VM.native_memory detail" 可以看到所有受 JVM 監控的記憶體分佈情況：

上圖只是截取了 nmt(Native Memory Tracking) 命令展示的概覽資訊，這個業務程序佔用的 2.2G 實體記憶體中，受 JVM 監控的大概只佔了 0.7G（上圖中的 committed），意味著有 1.5G 實體記憶體不受 JVM 管控。JVM 可以監控到 Java 堆、元空間、CodeCache、直接記憶體等區域，但無法監控到那些由 JVM 之外的 Native Code 申請的記憶體，例如典型的場景：第三方 so 庫中呼叫 malloc 函式申請一塊記憶體的行為無法被 JVM 感知到。

nmt 除了會展示概覽之外，還會詳細羅列每一片受 JVM 監控的記憶體，包括其地址，將這些 JVM 監控到的記憶體佈局和用 pmap 得到的完整的程序記憶體佈局做一個對比篩查，這裡忽略 nmt 和 pmap（下圖 pmap 命令中 25600 是程序號）詳細記憶體地址的資訊，直接給出最可疑的那塊記憶體：

由圖可知，這片 1.7G 左右的記憶體區域屬於系統層面的堆區。

備註：這片系統堆區之所以稍大於上面計算得到的差值，原因大概是 nmt 中顯示的 committed 記憶體並不對應真正佔用的實體記憶體（linux 使用 Lazy 策略管理程序記憶體），實際通常會稍小。

系統堆區主要就是由 libc 庫介面 malloc 申請的記憶體組合而成，所以接下來就是去跟蹤業務程序中的每次 malloc 呼叫，可以藉助 GDB：

實際上會有大量的干擾項，這些干擾項一方面來自 JVM 內部，比如：

這部分干擾項很容易被排除，凡是呼叫棧中存在 "os::malloc" 這個棧幀的干擾項就可以直接忽視，因為這些 malloc 行為都會被 nmt 監控到，而上面已經排除了受 JVM 監控記憶體洩漏的可能。

另一部分干擾項則來自 JDK，比如：

有如上圖所示，不少 JDK 的本地方法中直接或間接呼叫了 malloc，這部分 malloc 行為通常是不受 JVM 監控的，所以需要根據具體情況逐個排查，還是以上圖為例，排查過程如下：

注意圖中臨時中斷的值（0x0000ffff5fc55d00）來自於第一個中斷 b malloc 中斷髮生後的結果。

這裡稍微解釋一下上面 GDB 在做的排查過程，就是檢查 malloc 返回的記憶體地址後續是否有通過 free 釋放（通過 tb free if X3 這個命令，具體用法可以參考 GDB 除錯），顯然在這個例子中是有釋放的。

通過這種排查方式，幾經篩選，最終找到了一個可疑的 malloc 場景：

從呼叫棧資訊可以知道，這是一個 JDK 中的本地方法 sun.nio.fs.UnixNativeDispatcher.opendir0，作用是開啟一個目錄，但後續始終沒有進行關閉操作。進一步分析可知，該可疑 opendir 操作會週期性執行，而且都是操作同一個目錄 "/xxx/nginx/etc/nginx/conf"，看來，是有個業務執行緒在定時訪問 nginx 的配置目錄，每次訪問完卻沒有關閉開啟的目錄。

分析到這裡，其實這個問題已經差不多水落石出。和業務方確認，存在一個定時器執行緒在週期性讀取 nginx 的配置檔案，程式碼大概是這樣子的：

翻了一下相關 JDK 原始碼，Files.list 方法是有在末尾註冊一個關閉鉤子的：

也就是說，Files.list 方法返回的目錄資源是需要手動釋放的，否則就會發生資源洩漏。

由於這個目錄資源底層是會關聯一個 fd 的，所以洩漏問題還可以通過另一個地方進行佐證：

該業務程序目前已經消耗了 51116 個 fd！

假設這些 fd 都是 opendir 關聯的，每個 opendir 消耗 32K，則總共消耗 1.6G，顯然可以跟上面洩漏的記憶體值基本對上。

總結：

稍微瞭解了一下，發現幾乎沒人知道 JDK 方法 Files.list 是需要關閉的，這個案例算是給大家都提了個醒。

後記：

如果遇到相關技術問題（包括不限於畢昇 JDK），可以進入畢昇 JDK 社群查詢相關資源（點選閱讀原文進入官網），包括二進位制下載、程式碼倉庫、使用教學、安裝、學習資料等。畢昇 JDK 社群每雙週週二舉行技術例會，同時有一個技術交流群討論 GCC、LLVM、JDK 和 V8 等相關編譯技術，感興趣的同學可以新增如下微信小助手，回覆 Compiler 入群。