JVM优化系列-对象内存分配和回收的细节

客官°小女子只卖身不卖艺 2023-07-03 06:22 110阅读 0赞

> **导语**  
>   通过之前的分享，了解了关于垃圾回收算法以及垃圾回收器以及其使用，下面介绍的就是在实际使用中或者说是在处理问题过程中会出现的一些问题。

### 文章目录 ###

*   *  禁用System.gc()
     *  System.gc()使用并发回收
     *  并行GC前额外触发新生代GC
     *  对象什么时候进入老年代
     *   *  1、初创的对象在eden区
         *  2、老年对象进入老年代
         *  3、大对象直接进入老年代

在默认情况下通过System.gc()会显式的直接出发FullGC，在程序执行的过程中这个操作是一个比较低优先级的线程，所以在一般执行的时候并不会被执行到，执行了FullGC同时也是对老年代和新生代进行的回收。在一般情况下默认垃圾回收机制会自动进行，当然也可以在认为会有内存溢出操作的地方使用System.gc()这样的操作。那么怎么禁用这个操作呢？

## 禁用System.gc() ##

在程序运行过程中如果频繁的进行垃圾回收是对整个系统的性能没有一点点的好处，相反的还会消耗JVM的性能。所以JVM提供了一个参数DisableExplicitGC，这个参数用来标识是否需要手动触发GC操作。  
  在这里首先来创建一个类，并且调用System.gc()方法。

public class GC { 
        public static void main(String[] args) { 
            System.gc();
        }
    }

&esmsp; 进入到GC方法中之后会发现其实调用了如下的方法

/** * Runs the garbage collector. * <p> * Calling the <code>gc</code> method suggests that the Java Virtual * Machine expend effort toward recycling unused objects in order to * make the memory they currently occupy available for quick reuse. * When control returns from the method call, the Java Virtual * Machine has made a best effort to reclaim space from all discarded * objects. * <p> * The call <code>System.gc()</code> is effectively equivalent to the * call: * <blockquote><pre> * Runtime.getRuntime().gc() * </pre></blockquote> * * @see java.lang.Runtime#gc() */
        public static void gc() { 
            Runtime.getRuntime().gc();
        }

继续进入会发现这个方法是一个native方法。也就是说底层是被c语言支持的，那么到底是一段什么样的代码呢？其实这段在jvm.cpp中有一段代码就是用来判断是否传入了DisableExplicitGC参数，如果这参数有就表示禁用了显式的垃圾回收机制。

public native void gc();

既然这个参数可以带来好处也可以带来不好处那么下面就来看看System.gc()在性能调优上的用法。

## System.gc()使用并发回收 ##

上面提到过，在默认情况下，System.gc()生效，它会使用传统的Full GC方式来回收整个堆，而且就会忽略调虚拟机参数中的一些其他的参数，例如UseG1GC和UseConcMarkSweepGC等参数。例如可以使用如下的参数

-XX:+PrintGCDetails -XX:+UserConcMarkSweepGC 
    或者是
    -XX:+PrintGCDetails -XX:+UseG1GC

当以上两种情况遇到System.gc()操作的时候，将不会以CMS或者是G1的方式进行并发执行，而是采用了默认的方式，这个时候就需要使用到另一个参数-XX:+ExplicitGCInvokesConcurrent ，可以改变这种默认的行为。当ExplicitGCInvokesConcurrent开启之后，System.gc()这种显式GC才会使用并发的方式进行回收，否则无论使用了G1还是CMS，都不会进行并发回收。

## 并行GC前额外触发新生代GC ##

对于并行回收器的Full GC，也就是使用UseParallelOldGC或者是UseParallelGC。之前提到过在每次Full GC之前都会有一次的新生代GC。这和串行回收器相比较，还是有很大的区别的。

例如执行下面这段代码并且加上对应的虚拟机参数

public class GC { 
        public static void main(String[] args) { 
            System.gc();
        }
    }

虚拟机参数

-XX:+PrintGCDetails -XX:+UseSerialGC

系统执行结果如下

[Full GC (System.gc()) [Tenured: 0K->378K(174784K), 0.0081588 secs] 2798K->378K(253440K), [Metaspace: 2935K->2935K(1056768K)], 0.0083304 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

会发现执行结果与推测的结果是一样的，System.gc()触发了一次Full GC操作，而且切换为并行回收器，然后再进行同样的操作。

调整虚拟机参数如下

-XX:+PrintGCDetails -XX:+UseParallelOldGC

执行结果如下

[GC (System.gc()) [PSYoungGen: 2621K->544K(76288K)] 2621K->552K(251392K), 0.0011556 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    [Full GC (System.gc()) [PSYoungGen: 544K->0K(76288K)] [ParOldGen: 8K->378K(175104K)] 552K->378K(251392K), [Metaspace: 2931K->2931K(1056768K)], 0.0080514 secs] [Times: user=0.04 sys=0.00, real=0.01 secs]

可以看到上面的结果，在使用并行回收器的时候在触发Full GC之前，进行了一次的新生代的GC操作。所以这里的System.gc()实际上触发了两次的GC，这样做的目的是将新生代进行一次收集，避免将所有的回收工作都一次性的交给Full GC进行，这样就可以减少一次停顿时间。

当然如果在使用的时候不需要这特性的话，也可以使用参数-XX:ScavengeBeforeFullGC 去除发生在Full GC之前的新生代 GC。默认情况该值为true。

## 对象什么时候进入老年代 ##

对于一般的情况而言，当对象第一次被创建的时候，会被放到新生代的eden区，在堆中分配的对象首先被安置在eden区，如果没有GC的介入，那么这些对象就不会离开eden。

### 1、初创的对象在eden区 ###

实例代码

public class AllocEden { 
    
        public static final int _1K = 1024;
    
        public static void main(String[] args) { 
    
            for (int i = 0; i <5*_1K ; i++) { 
                byte[] b = new byte[_1K];
            }
        }
    }

虚拟机参数

-Xmx64M -Xms64M -XX:+PrintGCDetails

执行结果

Heap
     PSYoungGen      total 18944K, used 7242K [0x00000007beb00000, 0x00000007c0000000, 0x00000007c0000000)
      eden space 16384K, 44% used [0x00000007beb00000,0x00000007bf212818,0x00000007bfb00000)
      from space 2560K, 0% used [0x00000007bfd80000,0x00000007bfd80000,0x00000007c0000000)
      to   space 2560K, 0% used [0x00000007bfb00000,0x00000007bfb00000,0x00000007bfd80000)
     ParOldGen       total 44032K, used 0K [0x00000007bc000000, 0x00000007beb00000, 0x00000007beb00000)
      object space 44032K, 0% used [0x00000007bc000000,0x00000007bc000000,0x00000007beb00000)
     Metaspace       used 3014K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 331K, capacity 388K, committed 512K, reserved 1048576K

可以看到在整个的过程中没有GC发生，所有的对象创建都被创建在堆中，从堆日志中可以看到eden区被占用6MB左右的空间，from、to和老年代都没有使用。

### 2、老年对象进入老年代 ###

在Eden区中的对象什么时候可以进入到老年代？一般来说，当对象的年龄达到一定的大小，就可以进入到老年代。对象的年龄是由对象经历过GC的次数来决定的，在新生代中的对象每次经历GC操作，如果没有被回收，年龄就会增加1。虚拟机提供了一个参数来控制新生代对象的最大年龄：MaxTenuringThreshold。默认情况下这个参数是15。也就是说最多经历过15次GC就可以进入到老年代。

public class MaxTenuringThreshold { 
    
        public static final int _1K = 1024;
        public static final int _1M = 1024*1024;
    
        public static void main(String[] args) { 
    
            Map<Integer,byte[]> map = new HashMap<Integer, byte[]>();
    
            for (int i = 0; i <5*_1K ; i++) { 
                byte[] b = new byte[_1K];
                map.put(i,b);
            }
    
            for (int i = 0; i <17 ; i++) { 
                for (int j = 0; j <270 ; j++) { 
                    byte[] g = new byte[_1M];
                }
            }
        }
    }

上面代码依然是申请5MB 左右的空间，不同的是将新生的byte数组进行保存防止在GC的时候被回收，并且继续在新生代上分配内存，从而触发新生代GC，虚拟机参数可以进行如下的设置

-Xmx1024M -Xms1024M -XX:+PrintGCDetails -XX:MaxTenuringThreshold=15 -XX:+PrintHeapAtGC

从参数中可以看到，分配了1GB的内存，是可以将对象尽可能的预留在新生代。这个时候将MaxTenuringThreshold设置为15次，并且使用了PrintHeapAtGC参数将每次GC的时候堆信息都进行了输出。

如下

观察日志，在第一次GC开始之前eden使用了99%，这个也是触发新生代GC的原因。既然eden区也就是说不能长时间容纳太多的对象，自然而然就需要对eden进行清理，而清理的结果就是将存活的对象移动到from区中，从输出日志中可以看到from区也是占用了一部分空间。之后的GC操作都是与第一次GC是一样的，但是到了16次GC发生的时候，可以看到新生代也给清空了。  
  从新生代被回收的对象，如果还没有被回收就进入到了老年代，从最后的日志中可以看出老年代的空间确实被使用了，但是这个时候新生代的使用率为0。也可以通过MaxTenuringThreshold进行设置，不同的回收次数之后才会进入到老年代。

### 3、大对象直接进入老年代 ###

除了对象年龄这种方式，对象的大小也会影响对象进入老年代，如果对象体积太大的话，新生代是没有办法初始化这个对象，自然这个对象就无法放到新生代中。所以这个时候就需要将大对象直接放入到老年代中如下图所示

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25paHVpMTIz_size_16_color_FFFFFF_t_70_pic_center]  
  出现上面这种情况就需要另外的一个参数进行设置，PretenureSizeThreshold，这个就是用来设置对象直接进入老年代的阈值，单位是字节，只要对象大于指定的字节，就会直接被创建到老年代中，这个参数只对串行回收器和ParNew有效，对于ParallelGC无效。默认情况下该值为0，也就是不指定最大升级大小，根据运行情况自行决定。

public class PretenureSizeThreshold { 
    
        private static final int _1K = 1024;
    
        public static void main(String[] args) { 
            Map<Integer,byte[]> map = new HashMap<>();
    
            for (int i = 0; i <5*_1K ; i++) { 
                byte[] b = new byte[_1K];
                map.put(i,b);
            }
        }
    }

上面代码分配了大约5MB 的空间，有6千多个byte数组，每个数组的大小是1024，可以看到运行结果运行参数如下。

执行参数

-Xmx32m -Xms32m -XX:+UseSerialGC -XX:+PrintGCDetails

执行结果

Heap
     def new generation   total 9792K, used 7400K [0x00000007be000000, 0x00000007beaa0000, 0x00000007beaa0000)
      eden space 8704K,  85% used [0x00000007be000000, 0x00000007be73a098, 0x00000007be880000)
      from space 1088K,   0% used [0x00000007be880000, 0x00000007be880000, 0x00000007be990000)
      to   space 1088K,   0% used [0x00000007be990000, 0x00000007be990000, 0x00000007beaa0000)
     tenured generation   total 21888K, used 0K [0x00000007beaa0000, 0x00000007c0000000, 0x00000007c0000000)
       the space 21888K,   0% used [0x00000007beaa0000, 0x00000007beaa0000, 0x00000007beaa0200, 0x00000007c0000000)
     Metaspace       used 3068K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 336K, capacity 388K, committed 512K, reserved 1048576K

从运行结果来看所有的对象都被分配到了新生代，老年代的使用率为0，下面就来看看加上PretenureSizeThreshold参数可以看看结果。PretenureSizeThreshold=1000 则表示大小为1024字节的byte数组被分配到老年代。  
调整参数

-Xmx32m -Xms32m -XX:+UseSerialGC -XX:+PrintGCDetails -XX:PretenureSizeThreshold=1000

执行参数

Heap
     def new generation   total 9792K, used 7347K [0x00000007be000000, 0x00000007beaa0000, 0x00000007beaa0000)
      eden space 8704K,  84% used [0x00000007be000000, 0x00000007be72cda8, 0x00000007be880000)
      from space 1088K,   0% used [0x00000007be880000, 0x00000007be880000, 0x00000007be990000)
      to   space 1088K,   0% used [0x00000007be990000, 0x00000007be990000, 0x00000007beaa0000)
     tenured generation   total 21888K, used 52K [0x00000007beaa0000, 0x00000007c0000000, 0x00000007c0000000)
       the space 21888K,   0% used [0x00000007beaa0000, 0x00000007beaad2f0, 0x00000007beaad400, 0x00000007c0000000)
     Metaspace       used 3066K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 336K, capacity 388K, committed 512K, reserved 1048576K

到这里应该有5MB的数据被分配到老年代中，但是实际上很多的对象还是被分配到了新生代，看到这个PretenureSizeThreshold参数似乎是不起作用的，但是老年代的情况确实和不加PretenureSizeThreshold参数的结果是有所不同的，有52k的数据空间被使用了。

那么是什么原因导致了这种现象呢？因为虚拟机在为线程分配空间时，会优先使用一块叫做TLAB的区域，对体积不大的对象，很有可能会在TLAB上先进行分配，所以，就失去了在老年代分配的机会。所以为了演示这个情况，需要禁用TLAB。如下

-Xmx32m -Xms32m -XX:+UseSerialGC -XX:+PrintGCDetails -XX:-UseTLAB XX:PretenureSizeThreshold=1000

Heap
     def new generation   total 9792K, used 986K [0x00000007be000000, 0x00000007beaa0000, 0x00000007beaa0000)
      eden space 8704K,  11% used [0x00000007be000000, 0x00000007be0f6998, 0x00000007be880000)
      from space 1088K,   0% used [0x00000007be880000, 0x00000007be880000, 0x00000007be990000)
      to   space 1088K,   0% used [0x00000007be990000, 0x00000007be990000, 0x00000007beaa0000)
     tenured generation   total 21888K, used 5978K [0x00000007beaa0000, 0x00000007c0000000, 0x00000007c0000000)
       the space 21888K,  27% used [0x00000007beaa0000, 0x00000007bf076b88, 0x00000007bf076c00, 0x00000007c0000000)
     Metaspace       used 3086K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 338K, capacity 388K, committed 512K, reserved 1048576K

从结果可以看到禁用TLAB之后，大于1000字节的Byte被分配到了老年代。在后面的分享中会介绍什么是TLAB上分配对象。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25paHVpMTIz_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20200207163748229.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25paHVpMTIz,size_16,color_FFFFFF,t_70#pic_center