1、問題：jar進程會隨著時間由 30% 上漲到 70% 直到虛機報警。重啟過后，還是會緩慢上漲：

進程數也在上漲：

2、在排查內存問題時，可能會使用的命令

1)查看 java 進程：jps -l 可以看到當前進程號為 1

2)查看對上內存的使用情況：

/usr/java/jdk1.8.0_161/bin/jmap -heap 1

3)pmap -x 1

4)jstat -gc 1

5)導出堆棧信息：jmap -dump:format=b,file=/qae/log/dump.dat

2、將上面 5)中導出的堆棧文件，使用?MemoryAnalyzer.exe 打開：

3、通過 mat 的泄漏分析中，可以看到有兩個問題，其中第一個可以大概猜出是 JPA的相關數據庫操作導致的泄漏，點開 detail 繼續分析：

另一個是 java.beans.ThreadGroupContext 泄漏

4、點開上面問題1 的 detail 按鈕，依次查看各個對象，以及對象中的值：

目前基本能夠判斷，該內存泄漏是由 jpa 中的 findAll()導致的，相關代碼：

5、通過 google 搜索? JAP? query plan cache 相關的泄漏問題，找到帖子：

大致意思是：

基本上歸結為在IN子句中具有可變數量的值，而Hibernate試圖緩存這些查詢計劃：

Hibernate緩存這些解析的HQL查詢。具體來說，Hibernate SessionFactoryImpl包含帶有queryPlanCache和parameterMetadataCache的QueryPlanCache。

但是當插入子句的參數數量很大并且變化時，這被證明是一個問題。hibernate.query.plan_cache_max_size，默認為2048(對于具有許多參數的查詢而言，這個屬性太大)。

由于hibernate中存在一些模糊的錯誤，有些情況下參數未正確處理并被呈現到JPQL查詢中(作為示例，請查看HHH-6280)。如果您的查詢受到此類缺陷的影響并且以高速執行，

則會破壞您的查詢計劃緩存，因為生成的每個JPQL查詢幾乎都是唯一的(例如，包含您的實體的ID)

6、根據上面帖子的建議，將緩存計劃的值改小：

、

7、上線后，重啟應用，經過一段時間運行，基本維持在 36%：

8、另外，可以通過直方圖(Histogram)查看內存中的主要內存對象：

排除掉虛引用、弱引用、軟引用：

總結

以上是生活随笔為你收集整理的java 内存泄露对象排查_记录一次 java内存泄漏的排查的全部內容，希望文章能夠幫你解決所遇到的問題。

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