排查Java進(jìn)程內(nèi)存占比過高的方法
前言
早期面試的時候最害怕面試官問有沒有過JVM調(diào)優(yōu)的經(jīng)驗(yàn)，一聽這個問題腿肚子直轉(zhuǎn)筋，JVM八股文都沒背多熟練呢，調(diào)啥優(yōu)啊，嘮嗑嘮的讓人害怕，工作一段時間發(fā)現(xiàn)不就是基于服務(wù)當(dāng)時所在環(huán)境和現(xiàn)象根據(jù)JVM現(xiàn)有參數(shù)調(diào)參嘛，今天記一個JVM內(nèi)存相關(guān)參數(shù)。
某天下午運(yùn)維反應(yīng)集成環(huán)境的一個Java服務(wù)內(nèi)存飆高，看到消息我第一反應(yīng)就是高就高唄，這不Java本身的特點(diǎn)，高你就多讓給它點(diǎn)內(nèi)存得了，嫌高用Go重構(gòu)。后來運(yùn)維說內(nèi)存耗的太高了，疑似內(nèi)存泄漏。那得認(rèn)真分析一波了，別到時候上線發(fā)版出了大問題，事關(guān)眾后端將士的績效高低，我義不容辭。
內(nèi)存分析
排查Java進(jìn)程三板斧，先TOP看資源情況，shit+M按內(nèi)存排序看是個用戶中心的服務(wù)，當(dāng)時看用了接近20G左右，非常高了，集成環(huán)境都是研發(fā)測試用的環(huán)境，沒有多少訪問量怎么會有這么高的內(nèi)存使用量?？磥矶喟胧切孤读?。
分析內(nèi)存泄露其實(shí)也不難，我們先拿到pid淺淺的運(yùn)行下
jmap -histo:live [pid] > a.txt
這是獲取當(dāng)前進(jìn)程中存活的對象統(tǒng)計并把結(jié)果輸出到a.txt中，從高到低排序，直接看排在前幾位的對象有沒有我們的業(yè)務(wù)對象，如果有的話那差不多就逮到了，順著這個類找一下對應(yīng)的邏輯分析一下基本就能定位到。但是執(zhí)行完查詢發(fā)現(xiàn)排在前幾位都是jdk中的class，第一位是c[（[代表數(shù)組，char[]數(shù)組最多也正常，因?yàn)镾tring底層就是char[]，而且String應(yīng)用的地方也比較多）
這里已經(jīng)開始撓頭了，不太對啊，按理說內(nèi)存泄漏肯定是業(yè)務(wù)中用的類占比會多，再不濟(jì)也應(yīng)該是map占用高，這里明顯不太符合泄露的現(xiàn)象。。。
分析一下每5s的gc情況發(fā)現(xiàn)也都很平穩(wěn)。
jstat -gc pid 5000
那只能分析dump文件了，可以借助fastThread.io分析dump，也可以搞個JProfile分析。
jmap -dump pid
dump之后導(dǎo)入Jprofile發(fā)現(xiàn)整體內(nèi)存占用才2G多，這就很詭異了，從現(xiàn)象上來看像是假裝用了20g內(nèi)存實(shí)際只用了2g，這是咋回事呢。
解決方案
本質(zhì)上是jvm是在啟動的時候就會向操作系統(tǒng)申請一部分內(nèi)存，然后占著自己再做內(nèi)存管理，當(dāng)分配對象被回收之后也只是在這個內(nèi)存區(qū)域清除數(shù)據(jù)然后標(biāo)記空閑，也就是說根本不會歸還給操作系統(tǒng)。根本原因是歸還操作系統(tǒng)成本較高，不同的垃圾回收器也有不同的規(guī)則。
一直占著也不是個事，JVM還是提供了設(shè)置歸還策略的參數(shù)，MaxHeapFreeRatio，當(dāng)空閑區(qū)域超過該值時，會進(jìn)行內(nèi)存回收，剩余空間的下限為Xms，回收的過程也是線性回收并不是到點(diǎn)下班，到了MaxHeapFreeRatio內(nèi)存立馬降下來。
根據(jù)網(wǎng)上大佬們的結(jié)論，不同的垃圾回收器下的表現(xiàn)也不一樣，詳細(xì)的結(jié)論大家可以自行再去研究。
| JAVA 版本 | 垃圾回收器 | 參數(shù) | 是否可以“歸還” |
|---|---|---|---|
| JAVA 8 | ParallerGC + ParallerOld | -Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 | 否 |
| JAVA 8 | CMS+ParNew | -Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC | 是 |
| JAVA 8 | G1 | -Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 -XX:+UseG1GC | 是 |
| JAVA 11 | G1 | -Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 | 是 |
根據(jù)以上結(jié)論將服務(wù)啟動命令增加了-XX:++UseG1GC -XX:MaxHeapFreeRatio=50(最大空閑比例超過50%歸還)參數(shù)后內(nèi)存過高的問題的確沒有再出現(xiàn)。
到此這篇關(guān)于排查Java進(jìn)程內(nèi)存占比過高的方法的文章就介紹到這了,更多相關(guān)Java進(jìn)程內(nèi)存占比過高內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
這篇文章主要介紹了Java中Synchronized鎖的使用和原理詳解,synchronized是?Java?內(nèi)置的關(guān)鍵字，它提供了一種獨(dú)占的加鎖方式,synchronized的獲取和釋放鎖由JVM實(shí)現(xiàn)，用戶不需要顯示的釋放鎖，非常方便,需要的朋友可以參考下2023-07-07
Java調(diào)用瀏覽器打開網(wǎng)頁完整實(shí)例
這篇文章主要介紹了Java調(diào)用瀏覽器打開網(wǎng)頁的方法,以完整實(shí)例形式分析了java打開網(wǎng)頁的相關(guān)技巧,需要的朋友可以參考下2015-05-05
Java簡單實(shí)現(xiàn)農(nóng)夫過河問題示例
這篇文章主要介紹了Java簡單實(shí)現(xiàn)農(nóng)夫過河問題,簡單描述了農(nóng)夫過河問題的概念、原理并結(jié)合簡單實(shí)例形式分析了java解決農(nóng)夫過河問題的相關(guān)操作技巧,需要的朋友可以參考下2017-12-12
本文介紹了MyBatis-Plus中邏輯刪除和樂觀鎖的實(shí)現(xiàn)概念、方法和示例,邏輯刪除通過更改記錄狀態(tài)模擬刪除,而樂觀鎖通過版本號或時間戳確保并發(fā)操作的正確性2025-03-03
java啟動jar包修改JVM默認(rèn)內(nèi)存問題
這篇文章主要介紹了java啟動jar包修改JVM默認(rèn)內(nèi)存問題，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2023-02-02
詳解設(shè)計模式在Spring中的應(yīng)用(9種)
這篇文章主要介紹了詳解設(shè)計模式在Spring中的應(yīng)用(9種)，詳細(xì)的介紹了這9種模式在項(xiàng)目中的應(yīng)用，具有一定的參考價值，感興趣的可以了解一下2019-04-04
MyBatis中${}?和?#{}?有什么區(qū)別小結(jié)
${}?和?#{}?都是?MyBatis?中用來替換參數(shù)的，它們都可以將用戶傳遞過來的參數(shù)，替換到?MyBatis?最終生成的?SQL?中，但它們區(qū)別卻是很大的，今天通過本文介紹下MyBatis中${}?和?#{}?有什么區(qū)別，感興趣的朋友跟隨小編一起看看吧2022-11-11
今天小編就為大家分享一篇關(guān)于MapReduce核心思想圖文詳解，小編覺得內(nèi)容挺不錯的，現(xiàn)在分享給大家，具有很好的參考價值，需要的朋友一起跟隨小編來看看吧2019-01-01
spring boot整合quartz實(shí)現(xiàn)多個定時任務(wù)的方法
這篇文章主要介紹了spring boot整合quartz實(shí)現(xiàn)多個定時任務(wù)的方法，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2018-01-01
Springboot任務(wù)之異步任務(wù)的使用詳解
今天學(xué)習(xí)了一個新技能SpringBoot實(shí)現(xiàn)異步任務(wù),所以特地整理了本篇文章,文中有非常詳細(xì)的介紹及代碼示例,需要的朋友可以參考下2021-06-06