運維：大家 JAVA 服務內存佔用過高，還只增不減！告警了，快來接鍋

時間 2021-05-24

標籤 java 算法服務器 oracle 運維測試 spa 操作系統線程 code 欄目 Java 简体版

原文原文鏈接

先點贊再看，養成好習慣java

某天，運維老哥忽然找我：「大家的某 JAVA 服務內存佔用過高，告警了！GC 後也沒釋放，內存只增不減，是否是內存泄漏了！」算法

而後我趕忙看了下監控，一切正常，距離上次發版好幾天了，FULL GC 一次沒有，YoungGC，十分鐘一次，堆空閒也很充足。服務器

運維：「大家這個服務如今堆內存 used 才 800M，但這個 JAVA 進程已經佔了 6G 內存了，是否是大家程序出啥內存泄露的 bug 了！」

我想都沒想，直接回了一句：「不可能，咱們服務很是穩定，不會有這種問題！」

不過說完以後，心裏仍是自我質疑了一下：會不會真有什麼bug？難道是堆外泄露？線程沒銷燬？致使內存泄露了？？？oracle

而後我很「鎮定」的補了一句：「我先上服務器看看啥狀況」，被打臉可就很差了，仍是不要裝太滿的好……

迅速上登上服務器又仔細的查看了各類指標，Heap/GC/Thread/Process 之類的，發現一切正常，並無什麼「泄漏」的跡象。運維

和運維的「溝通」

咱們這個服務很正常啊，各個指標都ok，什麼內存只增不減，在哪呢

運維：你看大家這個 JAVA 服務，堆如今 used 才 400MB，但這個進程如今內存佔用都 6G 了，還說沒問題？確定是內存泄露了，鍋接好，趕忙回去查問題吧測試

而後我指着監控信息，讓運維看：「大哥你看這監控歷史，堆內存是達到過 6G 的，只是後面 GC 了，沒問題啊！」spa

運維：「回收了你這內存也沒釋放啊，你看這個進程 Res 仍是 6G，確定有問題啊」操作系統

我心想這運維怕不是個der，JVM GC 回收和進程內存又不是一回事，不過仍是和得他解釋一下，否則一直baba個沒完線程

「JVM 的垃圾回收，只是一個邏輯上的回收，回收的只是 JVM 申請的那一塊邏輯堆區域，將數據標記爲空閒之類的操做，不是調用 free 將內存歸還給操做系統」code

運維頓了兩秒後，忽然臉色一轉，開始笑起來：「咳咳，我可能沒注意這個。你再給我講講 JVM 的這個內存管理/回收和進程上內存的關係唄」

雖然我心裏是拒絕的，但得罪誰也不能得罪運維啊，想一想仍是給大哥解釋解釋，「增進下感情」

操做系統與 JVM的內存分配

JVM 的自動內存管理，其實只是先向操做系統申請了一大塊內存，而後本身在這塊已申請的內存區域中進行「自動內存管理」。JAVA 中的對象在建立前，會先從這塊申請的一大塊內存中劃分出一部分來給這個對象使用，在 GC 時也只是這個對象所處的內存區域數據清空，標記爲空閒而已

運維：「原來是這樣，那按你的意思，JVM 就不會將 GC 回收後的空閒內存還給操做系統了嗎？」

爲何不把內存歸還給操做系統？

JVM 仍是會歸還內存給操做系統的，只是由於這個代價比較大，因此不會輕易進行。並且不一樣垃圾回收器的內存分配算法不一樣，歸還內存的代價也不一樣。

好比在清除算法（sweep）中，是經過空閒鏈表（free-list）算法來分配內存的。簡單的說就是將已申請的大塊內存區域分爲 N 個小區域，將這些區域同鏈表的結構組織起來，就像這樣：

每一個 data 區域能夠容納 N 個對象，那麼當一次 GC 後，某些對象會被回收，但是此時這個 data 區域中還有其餘存活的對象，若是想將整個 data 區域釋放那是確定不行的。

因此這個歸還內存給操做系統的操做並無那麼簡單，執行起來代價太高，JVM 天然不會在每次 GC 後都進行內存的歸還。

怎麼歸還？

雖然代價高，但 JVM 仍是提供了這個歸還內存的功能。JVM 提供了-XX:MinHeapFreeRatio和-XX:MaxHeapFreeRatio 兩個參數，用於配置這個歸還策略。

MinHeapFreeRatio 表明當空閒區域大小降低到該值時，會進行擴容，擴容的上限爲 Xmx
MaxHeapFreeRatio 表明當空閒區域超過該值時，會進行「縮容」，縮容的下限爲Xms

不過雖然有這個歸還的功能，不過由於這個代價比較昂貴，因此 JVM 在歸還的時候，是線性遞增歸還的，並非一次所有歸還。

可是可是可是，通過實測，這個歸還內存的機制，在不一樣的垃圾回收器，甚至不一樣的 JDK 版本中還不同！

不一樣版本&垃圾回收器下的表現不一樣

下面是我以前跑過的測試結果：

public static void main(String[] args) throws IOException, InterruptedException {
    List<Object> dataList = new ArrayList<>();
    for (int i = 0; i < 25; i++) {
        byte[] data = createData(1024 * 1024 * 40);// 40 MB
        dataList.add(data);
    }
    Thread.sleep(10000);
    dataList = null; // 待會 GC 直接回收
    for (int i = 0; i < 100; i++) {
        // 測試屢次 GC
        System.gc();
        Thread.sleep(1000);
    }
    System.in.read();
}
public static byte[] createData(int size){
    byte[] data = new byte[size];
    for (int i = 0; i < size; i++) {
        data[i] = Byte.MAX_VALUE;
    }
    return data;
}

JAVA 版本	垃圾回收器	VM Options	是否能夠「歸還」
JAVA 8	UseParallelGC(ParallerGC + ParallerOld)	-Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40	否
JAVA 8	CMS+ParNew	-Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC	是
JAVA 8	UseG1GC(G1)	-Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 -XX:+UseG1GC	是
JAVA 11	UseG1GC(G1)	-Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40	是
JAVA 16	UseZGC(ZGC)	-Xms100M -Xmx2G -XX:MaxHeapFreeRatio=40 -XX:+UseZGC	否