現象

最近項目組從NET平臺遷移到Java的Dubbo平臺上，由于大家都是Java的生手，發生了蠻多的問題，以后一一記錄。現在解決一個遇到的關于Java程序內存泄露的問題。

特別說明

Java萌新，理解不到位的地方請指點一二

版本

Java 1.8

Dubbo 2.6.2

Docker 18.0.2

系統環境

我們這里是Docker Swarm集群，三臺機器組成，Dubbo服務隨機部署到三臺機器上。

問題重現

上線了一個Dubbo服務，這個服務涉及到數據庫查詢、排序分析、第三方接口調用。 服務啟動初始內存占用500MB左右，每檢索一次，內存增加10MB到幾十MB不等，而且不釋放。持續增高，最高可以塞滿整個服務器的內存。

檢查問題

首先，由于我們是部署在Docker集群上的，所以得去容器內進行檢查，剛上線，所以基礎容器選擇的是JDK版本，沒有用JRE。因為JDK帶有很多的調試工具。

查看生產環境并導出heap.hprof

首先看看容器的運行情況：

docker stats

這是后面調試的時候截的圖，早期發現的時候，內存是4.8G。明顯內存占用過多了。

因為宿主是沒有任何java環境的，進容器內做內存分析。

docker exec -it 容器ID bash # 進入指定容器

jmap -histo 1 | head -n 30 # 通過jmap工具查看

jmap的檢查結果當時忘了截圖了，這里就不留存了，百度能搜到了，就一筆帶過。

現在導出heap.hprof文件，方便用MAT進行分析。

jmap -dump:format=b,file=heap.hprof 1

在docker容器內，PID 1 是服務進程，以上命令將會在當前目錄生成heap.hprof文件，比較大，我的有1.2G。可以先壓縮了，再傳回來，進行分析。

使用MAT進行內存分析

獨立版下載地址：MAT

打開從服務器下載回來的heap.hprof文件

點擊Leak Suspects查看分析結果。

點擊Details查看詳情

上圖可以看到，MAT分析結果表明，OcMapperFactory這個類有問題。

看看具體代碼：

這個OcMapperFactory是用來封裝orika的工具類，而orika是一個對象映射工具。由于這里沒有用單例導致了內存的泄露。加上單例再看看：

重新測試，發現內存已經穩定。

總結

以上是生活随笔為你收集整理的JAVA处理 M_一次Java内存泄露处理手记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。