編者按：筆者使用 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。

分析：

使用命令 “jcmdVM.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 是需要關閉的，這個案例算是給大家都提了個醒。

編輯：jq