前言：

公司有一个资产统计系统，使用频率很低，但是要求在使用时查询速度快，因此想到做一些缓存放在内存中，在长时间没有使用，就持久化到磁盘中，并对垃圾进行回收，归还物理内存给操作系统，从而节省宝贵资源给其它业务系统。当我做好缓存时，却发现了一个棘手的问题，通过程序释放资源并通知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

image

• 运行程序后，使用JProfiler查看堆内存情况：

image

• 查看控制台打印的内容：

第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

image

• 运行程序后，使用JProfiler查看堆内存情况：

image

• 查看控制台打印的内容：

第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/29161424