前言

早期面試的時候最害怕面試官問有沒有過JVM調(diào)優(yōu)的經(jīng)驗，一聽這個問題腿肚子直轉(zhuǎn)筋，JVM八股文都沒背多熟練呢，調(diào)啥優(yōu)啊，嘮嗑嘮的讓人害怕，工作一段時間發(fā)現(xiàn)不就是基于服務(wù)當時所在環(huán)境和現(xiàn)象根據(jù)JVM現(xiàn)有參數(shù)調(diào)參嘛，今天記一個JVM內(nèi)存相關(guān)參數(shù)。

某天下午運維反應(yīng)集成環(huán)境的一個Java服務(wù)內(nèi)存飆高，看到消息我第一反應(yīng)就是高就高唄，這不Java本身的特點，高你就多讓給它點內(nèi)存得了，嫌高用Go重構(gòu)。后來運維說內(nèi)存耗的太高了，疑似內(nèi)存泄漏。那得認真分析一波了，別到時候上線發(fā)版出了大問題，事關(guān)眾后端將士的績效高低，我義不容辭。

內(nèi)存分析

排查Java進程三板斧，先TOP看資源情況，shit+M按內(nèi)存排序看是個用戶中心的服務(wù)，當時看用了接近20G左右，非常高了，集成環(huán)境都是研發(fā)測試用的環(huán)境，沒有多少訪問量怎么會有這么高的內(nèi)存使用量。看來多半是泄露了。

分析內(nèi)存泄露其實也不難，我們先拿到pid淺淺的運行下

jmap -histo:live [pid] > a.txt

這是獲取當前進程中存活的對象統(tǒng)計并把結(jié)果輸出到a.txt中，從高到低排序，直接看排在前幾位的對象有沒有我們的業(yè)務(wù)對象，如果有的話那差不多就逮到了，順著這個類找一下對應(yīng)的邏輯分析一下基本就能定位到。但是執(zhí)行完查詢發(fā)現(xiàn)排在前幾位都是jdk中的class，第一位是c[（[代表數(shù)組，char[]數(shù)組最多也正常，因為String底層就是char[]，而且String應(yīng)用的地方也比較多）

這里已經(jīng)開始撓頭了，不太對啊，按理說內(nèi)存泄漏肯定是業(yè)務(wù)中用的類占比會多，再不濟也應(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)存實際只用了2g，這是咋回事呢。

解決方案

本質(zhì)上是jvm是在啟動的時候就會向操作系統(tǒng)申請一部分內(nèi)存，然后占著自己再做內(nèi)存管理，當分配對象被回收之后也只是在這個內(nèi)存區(qū)域清除數(shù)據(jù)然后標記空閑，也就是說根本不會歸還給操作系統(tǒng)。根本原因是歸還操作系統(tǒng)成本較高，不同的垃圾回收器也有不同的規(guī)則。

一直占著也不是個事，JVM還是提供了設(shè)置歸還策略的參數(shù)，MaxHeapFreeRatio，當空閑區(qū)域超過該值時，會進行內(nèi)存回收，剩余空間的下限為Xms，回收的過程也是線性回收并不是到點下班，到了MaxHeapFreeRatio內(nèi)存立馬降下來。

根據(jù)網(wǎng)上大佬們的結(jié)論，不同的垃圾回收器下的表現(xiàn)也不一樣，詳細的結(jié)論大家可以自行再去研究。

根據(jù)以上結(jié)論將服務(wù)啟動命令增加了-XX:++UseG1GC -XX:MaxHeapFreeRatio=50(最大空閑比例超過50%歸還)參數(shù)后內(nèi)存過高的問題的確沒有再出現(xiàn)。

到此這篇關(guān)于排查Java進程內(nèi)存占比過高的方法的文章就介紹到這了,更多相關(guān)Java進程內(nèi)存占比過高內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論