編者按：筆者使用 JDK 自帶的內(nèi)存跟蹤工具 NMT 和 Linux 自帶的 pmap 解決了一個非常典型的資源泄漏問題。這個資源泄漏是由于 Java 程序員不正確地使用 Java API 導(dǎo)致的，使用 Files.list 打開的文件描述符必須關(guān)閉。本案例一方面介紹了怎么使用 NMT 解決 JVM 資源泄漏問題，如果讀者遇到類似問題，可以嘗試用 NMT 來解決；另一方面也提醒 Java 開發(fā)人員使用 Java API 時需要必須弄清楚 API 使用規(guī)范，希望大家通過這個案例有所收獲。

背景知識：

NMT

NMT 是 Native Memory Tracking 的縮寫，一個 JDK 自帶的小工具，用來跟蹤 JVM 本地內(nèi)存分配情況（本地內(nèi)存指的是 non-heap，例如 JVM 在運(yùn)行時需要分配一些輔助數(shù)據(jù)結(jié)構(gòu)用于自身的運(yùn)行）。

NMT 功能默認(rèn)關(guān)閉，可以在 Java 程序啟動參數(shù)中加入以下參數(shù)來開啟：

-XX:NativeMemoryTracking=［summary | detail］

其中，“summary” 和 “detail” 的差別主要在輸出信息的詳細(xì)程度。

開啟 NMT 功能后，就可以使用 JDK 提供的 jcmd 命令來讀取 NMT 采集的數(shù)據(jù)了，具體命令如下：

jcmd 《pid》 VM.native_memory ［summary | detail | baseline | summary.diff | detail.diff | shutdown］

NMT 參數(shù)的含義可以通過 “jcmd 《pid》 help VM.native_memory” 命令查詢。通過 NMT 工具，我們可以快速區(qū)分內(nèi)存泄露是否源自 JVM 分配。

pmap

對于非 JVM 分配的內(nèi)存，經(jīng)常需要用到 pmap 這個工具了，這是一個 linux 系統(tǒng)自帶工具，能夠從系統(tǒng)層面輸出目標(biāo)進(jìn)程內(nèi)存使用的詳細(xì)情況，用法非常簡單：

pmap ［參數(shù)］ 《pid》

常用的選項(xiàng)是 “-x” 或 “-X”，都是用來控制輸出信息的詳細(xì)程度。

上圖是 pmap 部分輸出信息，每列含義為

現(xiàn)象：

某業(yè)務(wù)集群中，多個節(jié)點(diǎn)出現(xiàn)業(yè)務(wù)進(jìn)程內(nèi)存消耗緩慢增長現(xiàn)象，以其中一個節(jié)點(diǎn)為例：

如圖所示，這個業(yè)務(wù)進(jìn)程當(dāng)前占用了 4.7G 的虛擬內(nèi)存空間，以及 2.2G 的物理內(nèi)存。已知正常狀態(tài)下該業(yè)務(wù)進(jìn)程的物理內(nèi)存占用量不超過 1G。

分析：

使用命令 “jcmdVM.native_memory detail” 可以看到所有受 JVM 監(jiān)控的內(nèi)存分布情況：

上圖只是截取了 nmt（Native Memory Tracking） 命令展示的概覽信息，這個業(yè)務(wù)進(jìn)程占用的 2.2G 物理內(nèi)存中，受 JVM 監(jiān)控的大概只占了 0.7G（上圖中的 committed），意味著有 1.5G 物理內(nèi)存不受 JVM 管控。JVM 可以監(jiān)控到 Java 堆、元空間、CodeCache、直接內(nèi)存等區(qū)域，但無法監(jiān)控到那些由 JVM 之外的 Native Code 申請的內(nèi)存，例如典型的場景：第三方 so 庫中調(diào)用 malloc 函數(shù)申請一塊內(nèi)存的行為無法被 JVM 感知到。

nmt 除了會展示概覽之外，還會詳細(xì)羅列每一片受 JVM 監(jiān)控的內(nèi)存，包括其地址，將這些 JVM 監(jiān)控到的內(nèi)存布局和用 pmap 得到的完整的進(jìn)程內(nèi)存布局做一個對比篩查，這里忽略 nmt 和 pmap（下圖 pmap 命令中 25600 是進(jìn)程號）詳細(xì)內(nèi)存地址的信息，直接給出最可疑的那塊內(nèi)存：

由圖可知，這片 1.7G 左右的內(nèi)存區(qū)域?qū)儆谙到y(tǒng)層面的堆區(qū)。

備注：這片系統(tǒng)堆區(qū)之所以稍大于上面計(jì)算得到的差值，原因大概是 nmt 中顯示的 committed 內(nèi)存并不對應(yīng)真正占用的物理內(nèi)存（linux 使用 Lazy 策略管理進(jìn)程內(nèi)存），實(shí)際通常會稍小。

系統(tǒng)堆區(qū)主要就是由 libc 庫接口 malloc 申請的內(nèi)存組合而成，所以接下來就是去跟蹤業(yè)務(wù)進(jìn)程中的每次 malloc 調(diào)用，可以借助 GDB：

實(shí)際上會有大量的干擾項(xiàng)，這些干擾項(xiàng)一方面來自 JVM 內(nèi)部，比如：

這部分干擾項(xiàng)很容易被排除，凡是調(diào)用棧中存在 “os：：malloc” 這個棧幀的干擾項(xiàng)就可以直接忽視，因?yàn)檫@些 malloc 行為都會被 nmt 監(jiān)控到，而上面已經(jīng)排除了受 JVM 監(jiān)控內(nèi)存泄漏的可能。

另一部分干擾項(xiàng)則來自 JDK，比如：

有如上圖所示，不少 JDK 的本地方法中直接或間接調(diào)用了 malloc，這部分 malloc 行為通常是不受 JVM 監(jiān)控的，所以需要根據(jù)具體情況逐個排查，還是以上圖為例，排查過程如下：

注意圖中臨時中斷的值（0x0000ffff5fc55d00）來自于第一個中斷 b malloc 中斷發(fā)生后的結(jié)果。

這里稍微解釋一下上面 GDB 在做的排查過程，就是檢查 malloc 返回的內(nèi)存地址后續(xù)是否有通過 free 釋放（通過 tb free if X3 這個命令，具體用法可以參考 GDB 調(diào)試），顯然在這個例子中是有釋放的。

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

從調(diào)用棧信息可以知道，這是一個 JDK 中的本地方法 sun.nio.fs.UnixNativeDispatcher.opendir0，作用是打開一個目錄，但后續(xù)始終沒有進(jìn)行關(guān)閉操作。進(jìn)一步分析可知，該可疑 opendir 操作會周期性執(zhí)行，而且都是操作同一個目錄 “/xxx/nginx/etc/nginx/conf”，看來，是有個業(yè)務(wù)線程在定時訪問 nginx 的配置目錄，每次訪問完卻沒有關(guān)閉打開的目錄。

分析到這里，其實(shí)這個問題已經(jīng)差不多水落石出。和業(yè)務(wù)方確認(rèn)，存在一個定時器線程在周期性讀取 nginx 的配置文件，代碼大概是這樣子的：

翻了一下相關(guān) JDK 源碼，F(xiàn)iles.list 方法是有在末尾注冊一個關(guān)閉鉤子的：

也就是說，F(xiàn)iles.list 方法返回的目錄資源是需要手動釋放的，否則就會發(fā)生資源泄漏。

由于這個目錄資源底層是會關(guān)聯(lián)一個 fd 的，所以泄漏問題還可以通過另一個地方進(jìn)行佐證：

該業(yè)務(wù)進(jìn)程目前已經(jīng)消耗了 51116 個 fd！

假設(shè)這些 fd 都是 opendir 關(guān)聯(lián)的，每個 opendir 消耗 32K，則總共消耗 1.6G，顯然可以跟上面泄漏的內(nèi)存值基本對上。

總結(jié)：

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

編輯：jq