JVM内存分配与回收策略分析

本是古典何须时尚 2021-11-17 07:14 414阅读 0赞

> **本文的测试结果都是基于jdk1.8以及Serial + Serial Old的收集器组合。**

### 文章目录 ###

*   *  新建的对象优先在Eden分配
     *  长期存活的对象进入到老年代
     *  动态对象年龄判定规则
     *  大对象直接进入到老年代
     *  空间分配担保规则
     *  参考资料

## 新建的对象优先在Eden分配 ##

一般来说，我们代码中创建的对象会优先在Eden区域分配，如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzejI1Njg5NTIzNTQ_size_16_color_FFFFFF_t_70_pic_center]  
我们通过代码来感受一下：

public class Main { 
    
        /** * -Xms20M -Xmx20M -Xmn10M -XX:+PrintGC -XX:+PrintGCDetails -XX:+UseSerialGC */
        public static void main(String[] args) { 
    
        }
    }

GC日志输出：

Heap
     def new generation   total 9216K, used 2155K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
      eden space 8192K,  26% used [0x00000000fec00000, 0x00000000fedc5c18, 0x00000000ff400000)
      from space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
      to   space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
     tenured generation   total 10240K, used 0K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
       the space 10240K,   0% used [0x00000000ff600000, 0x00000000ff600000, 0x00000000ff600200, 0x0000000100000000)
     Metaspace       used 2930K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 317K, capacity 388K, committed 512K, reserved 1048576K

GC日志输出：

Heap
     def new generation   total 9216K, used 4203K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
      eden space 8192K,  51% used [0x00000000fec00000, 0x00000000ff01ade0, 0x00000000ff400000)
      from space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
      to   space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
     tenured generation   total 10240K, used 0K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
       the space 10240K,   0% used [0x00000000ff600000, 0x00000000ff600000, 0x00000000ff600200, 0x0000000100000000)
     Metaspace       used 3443K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 376K, capacity 388K, committed 512K, reserved 1048576K

对比以上两份代码，可以看到第一份代码中我们没有手动创建代码，新生代使用了2155K内存，eden区域已使用内存占比26%，而第二份代码中，我们手动创建了一个2M大小的对象，新生代使用了4203K内存，eden区域已使用内存占比51%，正好比上份代码多使用了2048K内存，可知这2M的对象分配在了eden区域。

那随着对象的不断创建，eden区域迟早会变满，剩余的内存已不足以存放新建的对象，此时虚拟机就会发起一次Minor GC。将eden和Survivor中还存活的对象转移到另一个Survivor区域中，然后将剩余的空间一次性清空，供新建的对象存放。**注意：新建的对象只会在Eden区域分配的，而Survivor区域是存放每次GC过后存活的对象，GC过后永远会有一块Survivor是空的。**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzejI1Njg5NTIzNTQ_size_16_color_FFFFFF_t_70_pic_center 1]  
通过代码来看一下：

public class Main { 
    
        private static final int MB_SIZE = 1024 * 1024;
    
        /** * -Xms20M -Xmx20M -Xmn10M -XX:+PrintGC -XX:+PrintGCDetails -XX:+UseSerialGC */
        public static void main(String[] args) { 
            byte[] a1 = new byte[2 * MB_SIZE];
            byte[] a2 = new byte[2 * MB_SIZE];
            byte[] a3 = new byte[2 * MB_SIZE];
            a1 = null;
            a2 = null;
            a3 = null;
            byte[] a4 = new byte[5 * MB_SIZE];
        }
    }

GC日志输出：

[GC (Allocation Failure) [DefNew: 8135K->618K(9216K), 0.0009852 secs] 8135K->618K(19456K), 0.0010119 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    Heap
     def new generation   total 9216K, used 5904K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
      eden space 8192K,  64% used [0x00000000fec00000, 0x00000000ff129790, 0x00000000ff400000)
      from space 1024K,  60% used [0x00000000ff500000, 0x00000000ff59a948, 0x00000000ff600000)
      to   space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
     tenured generation   total 10240K, used 0K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
       the space 10240K,   0% used [0x00000000ff600000, 0x00000000ff600000, 0x00000000ff600200, 0x0000000100000000)
     Metaspace       used 3443K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 376K, capacity 388K, committed 512K, reserved 1048576K

可以看到，当我创建a4时，由于内存不足，导致发生了GC，发生的区域在新生代，614K左右的存活内存被移动到另一个Survivor区域中，之后在eden区域存放这5M的对象。其实，这里还有一个问题，如果GC过后存活的对象在Survivor中放不下怎么办？这时，就需要用到了老年代空间分配担保规则，将这些对象直接放入到老年代中。

## 长期存活的对象进入到老年代 ##

在程序运行的过程中，总有一些对象存活时间较长，躲过一次又一次的GC，但是它们也要不停的在两个Survivor区域中转移，这样就比较浪费时间，因为每次GC呢它们不会被清理掉，又要每次不停的转移，所以说，如果一个对象活得够长了，干脆直接将它们转移到老年代中，不让它们再参与新生代的GC。

public class Demo { 
        private static Object object = new Object(); 
    }

就如上述代码，只要Demo类还在，没有卸载，则object这个静态变量一直存在，对Object这个对象一直引用着，无论新生代怎么垃圾回收，这个对象都不会回收。如果对象经过新生代的垃圾回收后仍然存活并且被转移到一块Survivor区域，则对象的年龄增加1。每经过一次这样的过程，对象年龄就增加1，当年龄到了一定程度了，就将它转移到老年代中。可以通过设置参数-XX:MaxTenuringThreshold来设置具体是多少岁进入老年代，默认15。**经过第一次gc后存活的年龄为1**。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzejI1Njg5NTIzNTQ_size_16_color_FFFFFF_t_70_pic_center 2]  
测试代码如下：

public class Demo2 { 
    
        private static final int MB_SIZE = 1024 * 1024;
    
        /** * -Xms200M -Xmx200M -Xmn100M -XX:+PrintGC -XX:+PrintGCDetails -XX:MaxTenuringThreshold=3 -XX:+PrintTenuringDistribution -XX:+UseSerialGC */
        public static void main(String[] args) { 
            byte[] a1 = new byte[MB_SIZE];
            byte[] a2 = new byte[MB_SIZE * 70];
            // gc3次
            for (int i = 0; i < 3; i++) { 
                a2 = null;
                a2 = new byte[70 * MB_SIZE];
            }
        }
    }

GC日志输出：

[GC (Allocation Failure) [DefNew
    Desired survivor size 5242880 bytes, new threshold 3 (max 3)
    - age   1:    1684360 bytes,    1684360 total
    : 77619K->1644K(92160K), 0.0031652 secs] 77619K->1644K(194560K), 0.0032269 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] 
    [GC (Allocation Failure) [DefNew
    Desired survivor size 5242880 bytes, new threshold 3 (max 3)
    - age   2:    1680680 bytes,    1680680 total
    : 73324K->1641K(92160K), 0.0024464 secs] 73324K->1641K(194560K), 0.0024812 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    [GC (Allocation Failure) [DefNew
    Desired survivor size 5242880 bytes, new threshold 3 (max 3)
    - age   3:    1680464 bytes,    1680464 total
    : 74959K->1641K(92160K), 0.0012489 secs] 74959K->1641K(194560K), 0.0012832 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    Heap
     def new generation   total 92160K, used 74140K [0x00000000f3800000, 0x00000000f9c00000, 0x00000000f9c00000)
      eden space 81920K,  88% used [0x00000000f3800000, 0x00000000f7ecce50, 0x00000000f8800000)
      from space 10240K,  16% used [0x00000000f9200000, 0x00000000f939a450, 0x00000000f9c00000)
      to   space 10240K,   0% used [0x00000000f8800000, 0x00000000f8800000, 0x00000000f9200000)
     tenured generation   total 102400K, used 0K [0x00000000f9c00000, 0x0000000100000000, 0x0000000100000000)
       the space 102400K,   0% used [0x00000000f9c00000, 0x00000000f9c00000, 0x00000000f9c00200, 0x0000000100000000)
     Metaspace       used 3213K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 349K, capacity 388K, committed 512K, reserved 1048576K

把内存设置大一点主要是避免动态对象年龄判定。为MaxTenuringThreshold设置为3，当a1经过3次gc时，可以看到，a1还留在Survivor区域中，老年代中还没有对象。

public class Demo2 { 
    
        private static final int MB_SIZE = 1024 * 1024;
    
        /** * -Xms200M -Xmx200M -Xmn100M -XX:+PrintGC -XX:+PrintGCDetails -XX:MaxTenuringThreshold=3 -XX:+PrintTenuringDistribution -XX:+UseSerialGC */
        public static void main(String[] args) { 
            byte[] a1 = new byte[MB_SIZE];
            byte[] a2 = new byte[MB_SIZE * 70];
            // gc4次
            for (int i = 0; i < 4; i++) { 
                a2 = null;
                a2 = new byte[70 * MB_SIZE];
            }
        }
    }

GC日志输出：

[GC (Allocation Failure) [DefNew
    Desired survivor size 5242880 bytes, new threshold 3 (max 3)
    - age   1:    1684360 bytes,    1684360 total
    : 77619K->1644K(92160K), 0.0034374 secs] 77619K->1644K(194560K), 0.0035061 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    [GC (Allocation Failure) [DefNew
    Desired survivor size 5242880 bytes, new threshold 3 (max 3)
    - age   2:    1680680 bytes,    1680680 total
    : 73324K->1641K(92160K), 0.0022057 secs] 73324K->1641K(194560K), 0.0022525 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    [GC (Allocation Failure) [DefNew
    Desired survivor size 5242880 bytes, new threshold 3 (max 3)
    - age   3:    1680464 bytes,    1680464 total
    : 74959K->1641K(92160K), 0.0018657 secs] 74959K->1641K(194560K), 0.0019163 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    [GC (Allocation Failure) [DefNew
    Desired survivor size 5242880 bytes, new threshold 3 (max 3)
    : 73321K->0K(92160K), 0.0023300 secs] 73321K->1641K(194560K), 0.0023680 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    Heap
     def new generation   total 92160K, used 72499K [0x00000000f3800000, 0x00000000f9c00000, 0x00000000f9c00000)
      eden space 81920K,  88% used [0x00000000f3800000, 0x00000000f7ecce50, 0x00000000f8800000)
      from space 10240K,   0% used [0x00000000f8800000, 0x00000000f8800000, 0x00000000f9200000)
      to   space 10240K,   0% used [0x00000000f9200000, 0x00000000f9200000, 0x00000000f9c00000)
     tenured generation   total 102400K, used 1641K [0x00000000f9c00000, 0x0000000100000000, 0x0000000100000000)
       the space 102400K,   1% used [0x00000000f9c00000, 0x00000000f9d9a450, 0x00000000f9d9a600, 0x0000000100000000)
     Metaspace       used 3213K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 349K, capacity 388K, committed 512K, reserved 1048576K

从上面的日志可以看到第四次gc后新生代没有对象了，从73321K变为0K，全转移到老年代了，说明a1经过了第四次gc后被转移到老年代了。默认设置下，MaxTenuringThreshold=15，即在第16次gc后转移到老年代。

## 动态对象年龄判定规则 ##

还要一个跟对象年龄有关的就是这个动态对象年龄判定规则。虚拟机中对象年龄不一定非要等到MaxTenuringThreshold所设置的值才要转移到老年代，《深入理解Java虚拟机》里对这个规则的描述是：“如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄”。一开始我对这句话的理解是一定要相同年龄的对象大小超过50%的，但如果是这样的话，比如，年龄为3的对象大小超过了Survivor区域的一半了，年龄都为3，说明它们都是经过3次gc存活下来的，都是从年龄为2的时候经过gc存活下来的，那在年龄为2的时候这些对象大小就应该超过了Survivor的一半了，同理，年龄为1的时候也一样，也就是说如果有同龄的对象大小超过了Survivor的一半，就只能是年龄为1的对象，而根据动态对象年龄判定规则，年龄大于等于1的就得转移到老年代中，那根据以上的推论，根本就不会出现年龄大于1的同龄对象总大小超过Survivor区域的一半。如果有，早在年龄为1的时候这些对象就已经转移到老年代了。所以，我觉得这句话没表述清楚，容易发生歧义。

正确的理解是这样的：Survivor中的对象年龄从小到大进行累加，当加入某个年龄段后，累加和超过survivor区域50%的时候，就将这个年龄以及往上的年龄都转移到老年代，无须等到MaxTenuringThreshold中要求的年龄。比如Survivor空间中年龄为1的对象占用20%，年龄为2的对象占用40%， 年龄为3的对象占用30%。从低年龄开始累加，年龄为1加上年龄为2的对象大小占用60%，超过了默认的50%，则就将年龄为2以及往上的对象转移到老年代。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzejI1Njg5NTIzNTQ_size_16_color_FFFFFF_t_70_pic_center 3]  
测试代码  
gc两次：

public class Demo2 { 
    
        private static final int MB_SIZE = 1024 * 1024;
    
        /** * -Xms200M -Xmx200M -Xmn100M -XX:+PrintGC -XX:+PrintGCDetails -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution -XX:+UseSerialGC */
        public static void main(String[] args) { 
            byte[] a1 = new byte[MB_SIZE * 3];
            byte[] a2 = null;
            byte[] a3 = new byte[MB_SIZE * 70];
            // gc两次
            for (int i = 0; i < 2; i++) { 
                a3 = null;
                a3 = new byte[70 * MB_SIZE];
                if (i == 0) { 
                    a2 = new byte[MB_SIZE * 3];
                }
            }
        }
    }

GC日志：

[GC (Allocation Failure) [DefNew
    Desired survivor size 5242880 bytes, new threshold 15 (max 15)
    - age   1:    3781512 bytes,    3781512 total
    : 79667K->3692K(92160K), 0.0041238 secs] 79667K->3692K(194560K), 0.0041744 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    [GC (Allocation Failure) [DefNew
    Desired survivor size 5242880 bytes, new threshold 2 (max 15)
    - age   1:    3145744 bytes,    3145744 total
    - age   2:    3777832 bytes,    6923576 total
    : 80032K->6761K(92160K), 0.0055647 secs] 80032K->6761K(194560K), 0.0056018 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
    Heap
     def new generation   total 92160K, used 80899K [0x00000000f3800000, 0x00000000f9c00000, 0x00000000f9c00000)
      eden space 81920K,  90% used [0x00000000f3800000, 0x00000000f8066800, 0x00000000f8800000)
      from space 10240K,  66% used [0x00000000f8800000, 0x00000000f8e9a538, 0x00000000f9200000)
      to   space 10240K,   0% used [0x00000000f9200000, 0x00000000f9200000, 0x00000000f9c00000)
     tenured generation   total 102400K, used 0K [0x00000000f9c00000, 0x0000000100000000, 0x0000000100000000)
       the space 102400K,   0% used [0x00000000f9c00000, 0x00000000f9c00000, 0x00000000f9c00200, 0x0000000100000000)
     Metaspace       used 3214K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 349K, capacity 388K, committed 512K, reserved 1048576K

通过日志可以看出：经过两次gc后年龄1加上年龄2已经达到6923576 bytes，超过了Survivor的一半5242880 bytes，所以阈值threshold动态调整为2，下次gc后年龄大于2并存活的对象就会转移到老年代中。如下测试：  
gc三次：

public class Demo2 { 
    
        private static final int MB_SIZE = 1024 * 1024;
    
        /** * -Xms200M -Xmx200M -Xmn100M -XX:+PrintGC -XX:+PrintGCDetails -XX:MaxTenuringThreshold=15 -XX:+PrintTenuringDistribution -XX:+UseSerialGC */
        public static void main(String[] args) { 
            byte[] a1 = new byte[MB_SIZE * 3];
            byte[] a2 = null;
            byte[] a3 = new byte[MB_SIZE * 70];
            for (int i = 0; i < 3; i++) { 
                a3 = null;
                a3 = new byte[70 * MB_SIZE];
                if (i == 0) { 
                    a2 = new byte[MB_SIZE * 3];
                }
            }
        }
    }

GC日志：

[GC (Allocation Failure) [DefNew
    Desired survivor size 5242880 bytes, new threshold 15 (max 15)
    - age   1:    3781512 bytes,    3781512 total
    : 79667K->3692K(92160K), 0.0044879 secs] 79667K->3692K(194560K), 0.0045403 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    [GC (Allocation Failure) [DefNew
    Desired survivor size 5242880 bytes, new threshold 2 (max 15)
    - age   1:    3145744 bytes,    3145744 total
    - age   2:    3777832 bytes,    6923576 total
    : 80032K->6761K(92160K), 0.0068550 secs] 80032K->6761K(194560K), 0.0069083 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
    [GC (Allocation Failure) [DefNew
    Desired survivor size 5242880 bytes, new threshold 15 (max 15)
    - age   2:    3145744 bytes,    3145744 total
    : 80079K->3072K(92160K), 0.0047592 secs] 80079K->6761K(194560K), 0.0047949 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
    Heap
     def new generation   total 92160K, used 76390K [0x00000000f3800000, 0x00000000f9c00000, 0x00000000f9c00000)
      eden space 81920K,  89% used [0x00000000f3800000, 0x00000000f7f99b20, 0x00000000f8800000)
      from space 10240K,  30% used [0x00000000f9200000, 0x00000000f9500010, 0x00000000f9c00000)
      to   space 10240K,   0% used [0x00000000f8800000, 0x00000000f8800000, 0x00000000f9200000)
     tenured generation   total 102400K, used 3689K [0x00000000f9c00000, 0x0000000100000000, 0x0000000100000000)
       the space 102400K,   3% used [0x00000000f9c00000, 0x00000000f9f9a450, 0x00000000f9f9a600, 0x0000000100000000)
     Metaspace       used 3214K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 349K, capacity 388K, committed 512K, reserved 1048576K

可以看到，Survivor中不存在年龄为3的对象，都转移到老年代去了，只剩下年龄为2的对象了，并且阈值重新调整为15 。

其实，无论是默认超过15岁就进入老年代，还是动态对象年龄判定规则，都是希望那些可能是长期存活的对象，今早进入到老年代，避免在新生代中占用大量内存，影响效率以及频繁触发GC。

## 大对象直接进入到老年代 ##

如果遇到一个大对象，则直接将它分配到老年代去，避免遇到一个存活时间长，屡次躲过GC的大对象，在两个Survivor区域间来回移动，浪费时间。可以通过-XX:PretenureSizeThreshold参数来设置大对象的阈值，即多大的对象直接分配到老年代，比如：-XX:PretenureSizeThreshold=3145728，其中3145728指字节数，即超过3M的对象直接分配到老年代。如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzejI1Njg5NTIzNTQ_size_16_color_FFFFFF_t_70_pic_center 4]  
代码测试如下：

public class Main { 
    
        private static final int MB_SIZE = 1024 * 1024;
    
        /** * -Xms20M -Xmx20M -Xmn10M -XX:+PrintGC -XX:+PrintGCDetails -XX:PretenureSizeThreshold=3145728 -XX:+UseSerialGC */
        public static void main(String[] args) { 
            byte[] a1 = new byte[4 * MB_SIZE];
        }
    }

GC日志输出：

Heap
     def new generation   total 9216K, used 1982K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
      eden space 8192K,  24% used [0x00000000fec00000, 0x00000000fedefa40, 0x00000000ff400000)
      from space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
      to   space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
     tenured generation   total 10240K, used 4096K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
       the space 10240K,  40% used [0x00000000ff600000, 0x00000000ffa00010, 0x00000000ffa00200, 0x0000000100000000)
     Metaspace       used 3101K, capacity 4496K, committed 4864K, reserved 1056768K
      class space    used 336K, capacity 388K, committed 512K, reserved 1048576K

可以看到10M的老年代被使用了40%，即4M的大对象已直接分配到了老年代。**注意：PretenureSizeThreshold参数只对Serial和ParNew两种垃圾收集器有效。**

## 空间分配担保规则 ##

上面讲到了，如果GC过后存活的对象在Survivor中放不下了，就需要用到了老年代空间分配担保规则，将这些对象直接放入到老年代中，现在就来讲讲这个空间分配担保规则是怎样的。

首先，在执行任何一次Minor GC之前，虚拟机都会先检查一遍老年代中最大的可用的连续空间是否大于新生代中对象的总大小。

为什么要检查呢？因为在极端情况下，新生代在GC后对象全部存活，此时存活对象可能比较大，一块Survivor区域放不下了，就会转移到老年代中。所以如果老年代中最大的可用的连续空间大于新生代中对象的总大小，那就算新生代的对象都转移过来，老年代也是有空间可以放得下的，此时就可以放心的Minor GC了。

但如果老年代中最大的可用的连续空间小于新生代中对象的总大小，那就可能出现老年代也没有足够的连续空间来放这些对象。所以如果检查发现老年代中最大的可用的连续空间小于新生代中对象的总大小，就会查看HandlePromotionFailure设置值是否允许担保失败。

如果有设置HandlePromotionFailure这个参数，则再检查老年代最大的可用的连续空间是否大于之前历次Minor GC后进入老年代对象的平均大小。因为新生代一共会有多少对象活下来在实际完成内存回收之前是无法明确知道，所以虚拟机只好以之前每一次进入老年代对象的平均大小作为参考，认为很可能这次进入老年代对象的大小跟平均大小差不多。所以若大于，则可以认为这次晋升的对象老年代可以放得下，可尝试进行一次Minor GC（**这次Minor GC是有风险的，因为会出现这次Minor GC后存活的对象比平均值大并且也比老年代最大的可用的连续的空间大，那也会导致担保失败，老年代放不下这些对象。若出现这种情况，虚拟机会发起一次Full GC。若GC过后老年代还是放不下，就会导致OOM内存溢出**）。若小于或者HandlePromotionFailure参数没有设置，则虚拟机就会直接进行一次Full GC，让老年代腾出一些空间，而后再进行Minor GC。

单看文字可能说不清，画个简单的流程图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzejI1Njg5NTIzNTQ_size_16_color_FFFFFF_t_70_pic_center 5]  
这个图可能不一定正确，只是一个简单的流程。

但是不同版本规则有点不同，引用《深入理解Java虚拟机》中的一句话：“JDK6 Update 24之后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC， 否则将进行Full GC”。之后的版本HandPromotionFailure参数不会再影响到虚拟机的空间分配担保策略，可以认为强制打开了HandlePromotionFailure设置。

## 参考资料 ##

《深入理解Java虚拟机》  
[jvm误区–动态对象年龄判定][jvm]  
[你不知道的晋升阈值TenuringThreshold详解][TenuringThreshold]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzejI1Njg5NTIzNTQ_size_16_color_FFFFFF_t_70_pic_center]: /images/20211116/44746a5249ed430aae58e1ad216b3950.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzejI1Njg5NTIzNTQ_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20211116/95bfbe1ff6d1477db052b7b534507bc6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzejI1Njg5NTIzNTQ_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20211116/91fbfe87a2b143679f8c622001a36207.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzejI1Njg5NTIzNTQ_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20211116/bb55d332925c4f48a3be3e80ad32922c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzejI1Njg5NTIzNTQ_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20211116/5436bb775b3a41809937e731e5c2b5df.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hzejI1Njg5NTIzNTQ_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20211116/d0e30d1c0c024bd5ad7610b6efa53229.png
[jvm]: https://my.oschina.net/xpbob/blog/2221709
[TenuringThreshold]: https://blog.csdn.net/foolishandstupid/article/details/77596050