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

進(jìn)程數(shù)也在上漲：

2、在排查內(nèi)存問題時，可能會使用的命令

1)查看 java 進(jìn)程：jps -l 可以看到當(dāng)前進(jìn)程號為 1

2)查看對上內(nèi)存的使用情況：

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

3)pmap -x 1

4)jstat -gc 1

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

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

3、通過 mat 的泄漏分析中，可以看到有兩個問題，其中第一個可以大概猜出是 JPA的相關(guān)數(shù)據(jù)庫操作導(dǎo)致的泄漏，點開 detail 繼續(xù)分析：

另一個是 java.beans.ThreadGroupContext 泄漏

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

目前基本能夠判斷，該內(nèi)存泄漏是由 jpa 中的 findAll()導(dǎo)致的，相關(guān)代碼：

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

大致意思是：

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

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

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

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

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

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

、

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。