2. 程式人生 > >JVM調優之探索CMS和G1的實體記憶體歸還機制

JVM調優之探索CMS和G1的實體記憶體歸還機制

阿新 • • 發佈：2019-07-22

前言：

公司有一個資產統計系統，使用頻率很低，但是要求在使用時查詢速度快，因此想到做一些快取放在記憶體中，在長時間沒有使用，持久化到磁碟中，並對垃圾進行回收，歸還實體記憶體給作業系統，從而節省寶貴資源給其它業務系統。當我做好快取時，卻發現了一個棘手的問題，通過程式釋放資源並通知GC回收資源後，堆記憶體的已用記憶體減少了，空閒記憶體增加了，可是程序佔用系統記憶體卻沒有減少。查閱了很多資料，也嘗試過很多次，都沒有完美解決問題。直到後來看到一段評論談及G1垃圾回收器，才恍然大悟。

接下來，通過一個小demo給大家演示一下兩種垃圾回收器對實體記憶體歸還的區別。如果有什麼不對的地方，希望大家能夠在評論裡面指正。

  • 堆大小配置：
-Xms128M -Xmx2048M

先附上測試程式碼：

import org.junit.Test;

import java.util.ArrayList;
import java.util.List;

public class MemoryRecycleTest {

    @Test
    public void testMemoryRecycle() throws InterruptedException {

        List list = new ArrayList();

        //指定要生產的物件大小為512m
        int count = 512;

        //新建一條執行緒，負責生產物件
        new Thread(() -> {
            try {
                for (int i = 1; i <= 10; i++) {
                    System.out.println(String.format("第%s次生產%s大小的物件", i, count));
                    addObject(list, count);
                    //休眠40秒
                    Thread.sleep(i * 10000);
                }
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }).start();

        //新建一條執行緒，負責清理list，回收jvm記憶體
        new Thread(() -> {
            for (;;) {
                //當list記憶體到達512m，就通知gc回收堆
                if (list.size() >= count) {
                    System.out.println("清理list.... 回收jvm記憶體....");
                    list.clear();
                    //通知gc回收
                    System.gc();
                    //列印堆記憶體資訊
                    printJvmMemoryInfo();
                }
            }
        }).start();

        //阻止程式退出
        Thread.currentThread().join();
    }

    public void addObject(List list, int count) {
        for (int i = 0; i < count; i++) {
            OOMobject ooMobject = new OOMobject();
            //向list新增一個1m的物件
            list.add(ooMobject);
            try {
                //休眠100毫秒
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

    public static class OOMobject{
        //生成1m的物件
        private byte[] bytes=new byte[1024*1024];
    }

    public static void printJvmMemoryInfo() {
        // 虛擬機器級記憶體情況查詢
        long vmFree = 0;
        long vmUse = 0;
        long vmTotal = 0;
        long vmMax = 0;
        int byteToMb = 1024 * 1024;
        Runtime rt = Runtime.getRuntime();
        vmTotal = rt.totalMemory() / byteToMb;
        vmFree = rt.freeMemory() / byteToMb;
        vmMax = rt.maxMemory() / byteToMb;
        vmUse = vmTotal - vmFree;
        System.out.println("");
        System.out.println("JVM記憶體已用的空間為：" + vmUse + " MB");
        System.out.println("JVM記憶體的空閒空間為：" + vmFree + " MB");
        System.out.println("JVM總記憶體空間為：" + vmTotal + " MB");
        System.out.println("JVM總記憶體最大堆空間為：" + vmMax + " MB");
        System.out.println("");
    }

}

首先使用CMS垃圾回收器：

  • 將jvm執行引數設定為如下：
-Xms128M -Xmx2048M -XX:+UseConcMarkSweepGC

  • 執行程式後，使用JProfiler檢視堆記憶體情況：

  • 檢視控制檯列印的內容：
第1次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：6 MB
JVM記憶體的空閒空間為：936 MB
JVM總記憶體空間為：942 MB
JVM總記憶體最大堆空間為：1990 MB

第2次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：1025 MB
JVM總記憶體空間為：1029 MB
JVM總記憶體最大堆空間為：1990 MB

第3次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：680 MB
JVM總記憶體空間為：684 MB
JVM總記憶體最大堆空間為：1990 MB

第4次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：119 MB
JVM總記憶體空間為：123 MB
JVM總記憶體最大堆空間為：1990 MB

第5次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：119 MB
JVM總記憶體空間為：123 MB
JVM總記憶體最大堆空間為：1990 MB

第6次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：119 MB
JVM總記憶體空間為：123 MB
JVM總記憶體最大堆空間為：1990 MB

第7次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：119 MB
JVM總記憶體空間為：123 MB
JVM總記憶體最大堆空間為：1990 MB

第8次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：119 MB
JVM總記憶體空間為：123 MB
JVM總記憶體最大堆空間為：1990 MB

第9次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：119 MB
JVM總記憶體空間為：123 MB
JVM總記憶體最大堆空間為：1990 MB
  • 檢視jmap heap 資訊：
C:\Users>jmap -heap 4716
Attaching to process ID 4716, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.161-b12

using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC

Heap Configuration:
   MinHeapFreeRatio         = 40
   MaxHeapFreeRatio         = 70
   MaxHeapSize              = 2122317824 (2024.0MB)
   NewSize                  = 44695552 (42.625MB)
   MaxNewSize               = 348913664 (332.75MB)
   OldSize                  = 89522176 (85.375MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
New Generation (Eden + 1 Survivor Space):
   capacity = 280887296 (267.875MB)
   used     = 1629392 (1.5539093017578125MB)
   free     = 279257904 (266.3210906982422MB)
   0.5800874668251284% used
Eden Space:
   capacity = 249692160 (238.125MB)
   used     = 1629392 (1.5539093017578125MB)
   free     = 248062768 (236.5710906982422MB)
   0.6525603366961942% used
From Space:
   capacity = 31195136 (29.75MB)
   used     = 0 (0.0MB)
   free     = 31195136 (29.75MB)
   0.0% used
To Space:
   capacity = 31195136 (29.75MB)
   used     = 0 (0.0MB)
   free     = 31195136 (29.75MB)
   0.0% used
concurrent mark-sweep generation:
   capacity = 624041984 (595.1328125MB)
   used     = 4169296 (3.9761505126953125MB)
   free     = 619872688 (591.1566619873047MB)
   0.6681114583470076% used

6718 interned Strings occupying 574968 bytes.

通過統計圖和控制檯日誌，可以看到在執行43秒左右前，使用記憶體呈直線平滑上升，開闢的記憶體呈階梯狀上升。當使用記憶體到達525m時，程式發起了System.gc()，此時垃圾被回收了，因此使用記憶體回到了10m，可是jvm開闢出來的記憶體空間卻沒有歸還給作業系統，導致程式一直霸佔著960m左右的記憶體資源。第二次生產物件時，可以看到在執行53秒至1分44秒時，不再開闢新空間，而是重複利用已開闢的記憶體繼續建立物件，當執行第二次System.gc()時，jvm又開闢了一小部分記憶體，這一次程式霸佔了1050m記憶體資源。第三次生產物件時，可以看到在執行2分05秒至2分55秒時，不再開闢新空間，而是重複利用已開闢的記憶體繼續建立物件，當執行到第三次System.gc()時，jvm歸還了一部分記憶體給作業系統，此時依然霸佔著700m記憶體。........迴圈執行10次......從總的情況，可以看出，隨著System.gc()次數逐漸增加和時間間隔逐漸拉大，從繼續開闢記憶體變成了慢慢歸還記憶體給了作業系統，直到後面將實體記憶體全部歸還給作業系統。

接下來使用G1垃圾回收器：

-Xms128M -Xmx2048M -XX:+UseG1GC

  • 執行程式後，使用JProfiler檢視堆記憶體情況：

  • 檢視控制檯列印的內容：
第1次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：5 MB
JVM記憶體的空閒空間為：123 MB
JVM總記憶體空間為：128 MB
JVM總記憶體最大堆空間為：2024 MB

第2次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：124 MB
JVM總記憶體空間為：128 MB
JVM總記憶體最大堆空間為：2024 MB

第3次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：124 MB
JVM總記憶體空間為：128 MB
JVM總記憶體最大堆空間為：2024 MB

第4次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：124 MB
JVM總記憶體空間為：128 MB
JVM總記憶體最大堆空間為：2024 MB

第5次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：124 MB
JVM總記憶體空間為：128 MB
JVM總記憶體最大堆空間為：2024 MB

第6次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：124 MB
JVM總記憶體空間為：128 MB
JVM總記憶體最大堆空間為：2024 MB

第7次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：124 MB
JVM總記憶體空間為：128 MB
JVM總記憶體最大堆空間為：2024 MB

第8次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：124 MB
JVM總記憶體空間為：128 MB
JVM總記憶體最大堆空間為：2024 MB

第9次生產512大小的物件
清理list.... 回收jvm記憶體....

JVM記憶體已用的空間為：4 MB
JVM記憶體的空閒空間為：124 MB
JVM總記憶體空間為：128 MB
JVM總記憶體最大堆空間為：2024 MB
  • 檢視jmap heap 資訊：
C:\Users>jmap -heap 18112
Attaching to process ID 18112, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.161-b12

using thread-local object allocation.
Garbage-First (G1) GC with 4 thread(s)

Heap Configuration:
   MinHeapFreeRatio         = 40
   MaxHeapFreeRatio         = 70
   MaxHeapSize              = 2122317824 (2024.0MB)
   NewSize                  = 1363144 (1.2999954223632812MB)
   MaxNewSize               = 1272971264 (1214.0MB)
   OldSize                  = 5452592 (5.1999969482421875MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 1048576 (1.0MB)

Heap Usage:
G1 Heap:
   regions  = 2024
   capacity = 2122317824 (2024.0MB)
   used     = 8336616 (7.950416564941406MB)
   free     = 2113981208 (2016.0495834350586MB)
   0.39280714253663074% used
G1 Young Generation:
Eden Space:
   regions  = 2
   capacity = 83886080 (80.0MB)
   used     = 2097152 (2.0MB)
   free     = 81788928 (78.0MB)
   2.5% used
Survivor Space:
   regions  = 0
   capacity = 0 (0.0MB)
   used     = 0 (0.0MB)
   free     = 0 (0.0MB)
   0.0% used
G1 Old Generation:
   regions  = 11
   capacity = 50331648 (48.0MB)
   used     = 6239464 (5.950416564941406MB)
   free     = 44092184 (42.049583435058594MB)
   12.396701176961264% used

6706 interned Strings occupying 573840 bytes.

通過統計圖和控制檯日誌，可以看到在執行41秒左右前，使用記憶體呈直線平滑上升，開闢的記憶體也是呈直線平滑上升。當使用記憶體到達530m時，程式發起了System.gc()，垃圾被回收，因此使用記憶體回到了10m。此時會發現神奇的現象出來了，jvm之前開闢出來的剩餘記憶體空間全部歸還給了作業系統，記憶體回到了我們指定的初始jvm堆大小128m。通過多次執行生產物件對比發現，jvm都是在每一次呼叫System.gc()後全部歸還實體記憶體，不做任何保留。達到了我期望的效果！

總結：

CMS垃圾回收器，在記憶體開闢後，會隨著System.gc()執行次數逐漸增多和回收頻率逐漸拉長，從繼續開闢記憶體到慢慢歸還實體記憶體給作業系統，直到出現一次全部歸還，就會在每次呼叫System.gc()都歸還所有剩餘的實體記憶體給作業系統；G1恰恰相反，G1是在JVM每次回收垃圾後，主動歸還實體記憶體給作業系統，不做任何保留，大大降低了記憶體佔用。

另外，檢視java堆疊實時情況，推薦使用JProfiler和VisualVM。如果是本地推薦JProfiler，因為功能強大，不過遠端配置麻煩；如果是連遠端java程序，推薦VisualVM，功能夠用，連線遠端只需配置一些jvm引數。

其它說明

JDK 12將有G1收集器，將記憶體返回到作業系統(不呼叫System.gc)“應用程式空閒時”

jdk9 增加了這個jvm引數：

-XX:+ShrinkHeapInSteps
使Java堆漸進地縮小到目標大小，該選項預設開啟，經過多次GC後堆縮小到目標大小；如果關閉該選項，那麼GC後Java堆將立即縮小到目標大小。如果希望最小化Java堆大小，可以關閉改選項，並配合以下選項：

-XX:MaxHeapFreeRatio=10 -XX:MinHeapFreeRatio=5

這樣將保持Java堆空間較小，並減少程式的動態佔用空間，這對嵌入式應用非常有用，但對於一般應用，可能降低效能。

參考資料：

http://www.imooc.com/wenda/detail/574044
https://developer.ibm.com/cn/blog/2017/still-paying-unused-memory-java-app-idle/
https://gameinstitute.qq.com/community/detail/118528
https://www.zhihu.com/question/30813753
https://www.zhihu.com/question/29161

相關推薦

JVM調優之探索CMS和G1的實體記憶體歸還機制

前言： 公司有一個資產統計系統，使用頻率很低，但是要求在使用時查詢速度快，因此想到做一些快取放在記憶體中，在長時間沒有使用，持久化到磁碟中，並對垃圾進行回收，歸還實體記憶體給作業系統，從而節省寶貴資源給其它業務系統。當我做好快取時，卻發現了一個棘手的問題，通過程式釋放資源並通知GC回收資源後，堆記憶體的已用記

JVM調優——之CMS 常見引數解析

 最近在學習使用CMS這個GC,這裡記錄下常用的引數。1. UseCMSCompactAtFullCollection 與 CMSFullGCsBeforeCompaction     有一點需要注意的是：CMS併發GC不是“full GC”。HotSpot VM裡對conc

JVM調優之jstack找出最耗cpu的線程並定位代碼

grep 輪詢 tin jstack stack ads OS 分享 bject jstack可以定位到線程堆棧，根據堆棧信息我們可以定位到具體代碼，所以它在JVM性能調優中使用得非常多。下面我們來一個實例找出某個Java進程中最耗費CPU的Java線程並定位堆棧信息，用到

JVM調優之監控工具

protect 操作 虛擬 遠程調試 -xms thread 行號 垃圾 time javac -verbose 類名.java java -verbose 類名 javap -c 類名 javap -verbose 類名JAVAP -HELP用法: javap其中, 可能

JVM調優之Tomcat啟動參數配置及詳解

.bat xms 是否 大堆 pts 啟動參數 spa java permgen 開發項目中會遇到Tomcat內存溢出(java.lang.OutOfMemoryError: PermGen space)的問題，通過查找資料找到是通過設置

【轉】【JVM】JVM調優之jstack找出最耗cpu的執行緒並定位程式碼

jstack可以定位到執行緒堆疊，根據堆疊資訊我們可以定位到具體程式碼，所以它在JVM效能調優中使用得非常多。下面我們來一個例項找出某個Java程序中最耗費CPU的Java執行緒並定位堆疊資訊，用到的命令有ps、top、printf、jstack、grep。 第一步先找

JVM調優之常用引數配置

一、堆設定 -Xms:初始堆大小 -Xmx:最大堆大小 -XX:NewSize=n:設定年輕代大小 -XX:NewRatio=n:設定年輕代和年老代的比值。如:為3，表示年輕代與年老代比值為1：3，年輕代佔整個年輕代年老代和的1/4 -XX:SurvivorRatio=n:年輕代中Eden區與

JVM調優之Tomcat啟動引數配置及詳解

開發專案中會遇到Tomcat記憶體溢位(java.lang.OutOfMemoryError: PermGen space)的問題，通過查詢資料找到是通過設定Tomcat 啟動堆空間大小、年輕代大小、每個執行緒大小引數進行調優的，具體如下： 一、在Tomcat 啟動指令碼（

JVM調優之jstack找出最耗cpu的執行緒並定位程式碼

第一步：先找出java的程序Id(PID) 假設java應用名稱是zcg_commodity ps -ef|grep zcg_commodity 得到程序Id為32464 第二步：找出該程序內最消耗CPU的執行緒 top -Hp pid 輸入top

spark JVM調優之原理概述以及降低cache操作的記憶體佔比

每一次放物件的時候，都是放入eden區域，和其中一個survivor區域；另外一個survivor區域是空閒的。 當eden區域和一個survivor區域放滿了以後（spark執行過程中，產生的物件實在太多了），就會觸發minor gc，小型垃圾回收。把不再使用的物件，從記憶體中清空，給後面新建立

JVM調優之經驗

在生產系統中，高吞吐和低延遲一直都是JVM調優的最終目標，但這兩者恰恰又是相悖的，魚和熊掌不可兼得，所以在調優之前要清楚舍誰而取誰

JVM調優之垃圾定位、垃圾回收演算法、垃圾處理器對比

談垃圾回收器之前,要先講講垃圾回收演算法,以及JVM對垃圾的認定策略,JVM垃圾回收器是垃圾回收演算法的具體實現,瞭解了前面的前置知識,有利於對垃圾回收器的理解。 ## 什麼是垃圾? 垃圾,主要是指堆上的物件,那麼如何確定這些物件是可以被回收的呢? 大概思路就是,如果一個物件永遠不可能被訪問到,那麼

JVM調優（一）虛擬機器的記憶體模型

前言 Java虛擬機器記憶體模型是Java程式執行的基礎，JVM虛擬機器的記憶體模型如下圖： 程式計數器 程式計數器(Program Counter Register)是一塊很小的記憶體空間。由於java是支援多執行緒的語言，當執行緒數超過cpu的數量時，執行緒之間根據時間片輪詢搶

JVM調優——Java動態編譯過程中的記憶體溢位問題

由於測試環境專案每2小時記憶體就溢位一次， 分析問題，發現Java動態載入Class並執行那塊存在記憶體溢位問題， 遂本地調測。 一、找到動態編譯那塊的程式碼，具體如下 /** * @MethodName : 編譯java程式碼到Object * @Descrip

Java調優之jvm和執行緒的記憶體分析

      這幾天因為自己開發的一個網站在768M記憶體的機器上撐不起100多個使用者的執行，因為每個使用者啟用功能後，系統將為每個使用者分配8個左右的獨立執行緒，我的這篇文章http://www.mzone.cc/article/311.html也有介紹的。在記憶體小的機器上經常出現的問題就是Cann’t

JVM調優系列：（五）JVM常用調試參數和工具

框架 break 統計 進程 -i 內存 文件的 /etc/ action 轉自：http://blog.csdn.net/opensure/article/details/46715769 JVM常用調試參數: –verbose:gc在虛擬機發生內存

JVM學習筆記（二）--方法調用之靜態分配和動態分配

extends AD 找到 n! sse 運行時 面試 static sys 本篇文章從JVM的角度來理解Java學習中經常提到的重載和重寫。 方法調用：方法調用不等同於方法執行，在Java虛擬機中，方法調用僅僅是為了確定調用哪個版本的方法。方法調用分為解析調用和分派。解析

Spark學習之路 （十二）SparkCore的調優之資源調優JVM的基本架構

程序員 存儲 src ron 指示器 引用 double strong 功能 一、JVM的結構圖 1.1　Java內存結構 JVM內存結構主要有三大塊：堆內存、方法區和棧。 堆內存是JVM中最大的一塊由年輕代和老年代組成，而年輕代內存又被分成三部分，Eden空間、

Spark學習之路 （十四）SparkCore的調優之資源調優JVM的GC垃圾收集器

當前 復制 event 只需要 引用 應用 之前 相互 分享 一、概述 垃圾收集 Garbage Collection 通常被稱為“GC”，它誕生於1960年 MIT 的 Lisp 語言，經過半個多世紀，目前已經十分成熟了。 jvm 中，程序計數

Spark調優之JVM調優

今天給大家分享Spark調優相關的JVM調優，這個調優方法在開發中也很常見，他主要分為兩種，一種是降低cache操作的記憶體佔比，一種是調節executor堆外記憶體和降低連線等待時長。 在此之前，我們先來了解一下JVM的堆記憶體。 堆記憶體存放我們建立的一些物件，有老年代和年輕代。理想