JVM-09自动内存管理机制【内存分配和回收策略】

原创

小小工匠 2022-04-12 11:36:43 ©著作权

文章标签 jvm 内存分配回收策略老年代 sed 文章分类 代码人生

©著作权归作者所有：来自51CTO博客作者小小工匠的原创作品，请联系作者获取转载授权，否则将追究法律责任

文章目录

思维导图
对象优先在eden区域分配

理论
案例

虚拟机参数设置及参数说明
代码
GC结果分析

大对象直接进入老年代

理论
案例

虚拟机参数设置及参数说明
代码
GC日志

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

理论
案例

虚拟机参数设置及参数说明
代码
XX:MaxTenuringThreshold=1时的 GC日志
XX:MaxTenuringThreshold=15时的 GC日志

动态对象年龄判定

理论
案例

虚拟机参数设置及参数说明
代码
GC日志

空间分配担保

理论

思维导图

JVM-09自动内存管理机制【内存分配和回收策略】_老年代

对象优先在eden区域分配

JVM-09自动内存管理机制【内存分配和回收策略】_老年代_02

理论

大多数情况下，对象在新生代的eden区中分配，当eden区没有足够的空间进行分配时，虚拟机将进行一次Minor GC。

虚拟机提供-XX:+PrintGCDetails参数，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进程退出的时候输出当前的内存各区域分配情况。

实际应用中，GC日志一般都是输出到文件中，使用GC日志分析工具来进行分析。

案例

虚拟机参数设置及参数说明

JDK1.6

-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+UseSerialGC  -verbose:gc -XX:+PrintGCDetails

JVM-09自动内存管理机制【内存分配和回收策略】_sed_03

-Xms20M 初始化堆内存 20M
-Xmx20M 最大堆内存20M，结合-Xms20M 即为堆内存不可扩展
-Xmn10M 新生代内存分配10M，结合-Xms -Xmx 可知老年代也是10M
-XX:SurvivorRatio=8 默认值，可不配置。新生代中Eden区与一个Survivor区的比例为8:1，即 Eden: from Survivor：to Survivor = 8:1:1，即8MB:1MB:1MB，新生代的可用空间为9MB。
-XX:+UseSerialGC 指定年轻代使用Serial垃圾收集器
-verbose:gc 和 -XX:+PrintGCDetails 发生垃圾回收时，打印GC日志

代码

package com.artisan.gc;

public class EdenAllocationGC {

  private int _1M = 1024 * 1024;

  /**
   * 
   * @Title: testGCAllocation
   * 
   * @Description: -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8
   *               -XX:+UseSerialGC -verbose:gc -XX:+PrintGCDetails
   * 
   * @return: void
   */
  @SuppressWarnings("unused")
  private void testGCAllocation() {
    // 如下的分配，仅仅是为了占用些内存空间，方便观察GC回收情况
    byte[] object1 = new byte[2 * _1M];
    byte[] object2 = new byte[2 * _1M];
    byte[] object3 = new byte[2 * _1M];
    byte[] object4 = new byte[4 * _1M];
  }

  public static void main(String[] args) {
    new EdenAllocationGC().testGCAllocation();
  }

}

GC结果分析

[GC [DefNew: 6487K->159K(9216K), 0.0052344 secs] 6487K->6303K(19456K), 0.0052735 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 def new generation   total 9216K, used 4582K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,  54% used [0x00000000f9a00000, 0x00000000f9e51f98, 0x00000000fa200000)
  from space 1024K,  15% used [0x00000000fa300000, 0x00000000fa327c28, 0x00000000fa400000)
  to   space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
 tenured generation   total 10240K, used 6144K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  60% used [0x00000000fa400000, 0x00000000faa00030, 0x00000000faa00200, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 2995K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  14% used [0x00000000fae00000, 0x00000000fb0eccf8, 0x00000000fb0ece00, 0x00000000fc2c0000)
No shared spaces configured.

因为内容较少可以直接阅读。当然了也可以传到http://gceasy.io 在线生成一份GC分析报告。

JVM-09自动内存管理机制【内存分配和回收策略】_老年代_04

JVM-09自动内存管理机制【内存分配和回收策略】_jvm_05

这里我们直接来分析下这个GC日志

结合JVM参数的设置，通过GC日志的验证，符合设置。

def new generation   total 9216K ......
eden space 8192K ......
from space 1024K ......
to   space 1024K ......

def new generation 是通过-XX:+UseSerialGC指定的垃圾回收器，显示名称是由收集器决定的。

如果是用的Serial收集器，新生代名为“Default New Generation”,所以显示“[DefNew”。
如果是用的ParNew收集器，新生代名为“Parallel New Generation”,所以显示“[ParNew”。
如果是用的Parallel Scavenge收集器，新生代名则显示为“[PSYongGen”

-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8

新生代分配了10M，又因为SurvivorRatio = 8 。所以 Eden: from Survivor：to Survivor = 8192K:1024K :1024K

通过new创建对象的方式，虚拟机会将对象的实例分配到堆内存中，具体的说是分配object1 、object2 、object3 三个对象到 Eden区+Survivor From，3个对象占6MB空间，而 Eden + Survivor From 的大小为9M，空间足够，优先分配到Eden区。所以Eden区的内存被占用6M

分配object4时的时候，发现Eden+Survivor From剩余空间只有3M，而object4占用4M的内存，这个时候就会触发一次Minor GC ，输出的信息如下

[GC [DefNew: 6487K->159K(9216K), 0.0052344 secs] 6487K->6303K(19456K), 0.0052735 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

可以看到6487K->159K(9216K) ，新生代的内存由6487K变为了159K。而堆内存 6487K->6303K基本没有发生变化，是因为 object1,object2,object3都是存活的对象，无法被GC回收。

GC期间又发现已有的3个2MB的对象都无法放入Survivor To空间（1MB），所以通过担保机制提前转移到老年代区（3个2MB的对象），此时Eden区恢复到8MB空间，然后将object4分配到Eden空间。

GC结束后，4M的object4被顺利的分配到了Eden区中，Survivor空闲。老年代 tenured generation占用6M（object1,object2,object3占用）。通过如下日志也可以眼睁这个结论

tenured generation   total 10240K, used 6144K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  60% used [0x00000000fa400000, 0x00000000faa00030, 0x00000000faa00200, 0x00000000fae00000)

大对象直接进入老年代

JVM-09自动内存管理机制【内存分配和回收策略】_sed_06

理论

需要大量连续内存空的Java对象，一般称之为大对象。

PretenureSizeThreshold参数，可以在新生代直接分配的对象最大值，0表示没有最大值。可以使大于这个值的对象直接在老年代分配，避免在Eden区和Survivor区发生大量的内存复制，该参数只对Serial和ParNew收集器有效，Parallel Scavenge并不认识该参数

使用方法：-XX:PretenureSizeThreshold=1000000

案例

虚拟机参数设置及参数说明

JDK1.6

-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+UseSerialGC  -verbose:gc -XX:+PrintGCDetails -XX:PretenureSizeThreshold=3145728

-XX:PretenureSizeThreshold=3145728 ：单位是byte, 3145728 = 3M,大于3M的对象直接在老年代分配，避免在Eden区和Survivor区发生大量的内存复制.

代码

package com.artisan.gc;

public class PretenureSizeThresholdTest {

  private int _1M = 1024 * 1024;

  /**
   * 
   * @Title: testPretenureSizeThreshold
   * 
   * @Description: -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8
   *               -XX:+UseSerialGC -verbose:gc -XX:+PrintGCDetails
   *               -XX:PretenureSizeThreshold=3145728
   * 
   * @return: void
   */
  @SuppressWarnings("unused")
  private void testPretenureSizeThreshold() {
    // 如下的分配，仅仅是为了占用些内存空间，方便观察GC回收情况
    byte[] object4 = new byte[4 * _1M];
  }

  public static void main(String[] args) {
    new PretenureSizeThresholdTest().testPretenureSizeThreshold();
  }
}

GC日志

JDK1.6

Heap
 def new generation   total 9216K, used 507K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000)
  eden space 8192K,   6% used [0x00000000f9a00000, 0x00000000f9a7ee98, 0x00000000fa200000)
  from space 1024K,   0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)
  to   space 1024K,   0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)
 tenured generation   total 10240K, used 4096K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  40% used [0x00000000fa400000, 0x00000000fa800010, 0x00000000fa800200, 0x00000000fae00000)
 compacting perm gen  total 21248K, used 2985K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000)
   the space 21248K,  14% used [0x00000000fae00000, 0x00000000fb0ea690, 0x00000000fb0ea800, 0x00000000fc2c0000)
No shared spaces configured.

可以看到这里并没有发生Minor GC ,仅仅是打印了堆内存信息。通过-XX:PretenureSizeThreshold=3145728的设置，4M大小的object4 大于设置的3M阀值，直接分配到了老年代。

tenured generation   total 10240K, used 4096K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000)
   the space 10240K,  40% used [0x00000000fa400000, 0x00000000fa800010, 0x00000000fa800200, 0x00000000fae00000)

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

JVM-09自动内存管理机制【内存分配和回收策略】_内存分配_07

理论

现在商用虚拟机都采用分代收集的思想来管理内存，那么内存回收就必须能识别哪些对象应该放在新生代，哪些对象应该放在老年代。

为了做到这一点，虚拟机给每个对象定义了一个对象年龄计数器。如果对象在Eden畜生并经过第一次Minor GC后仍然存活，并且能够被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设置为1。对象在Survivor区中没经历过一次Minor GC且存活下来，年龄就增加1岁。当它的年龄增加到一定程度（默认15岁），就将会被晋升到老年代中。

对象晋升老年代的年龄可以通过-XX:MaxTenuringThreshold设置

案例

我们分别将-XX:MaxTenuringThreshold=1 和 -XX:MaxTenuringThreshold=15 来看下GC日志的区别。

虚拟机参数设置及参数说明

JDK1.6

-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+UseSerialGC  -verbose:gc -XX:+PrintGCDetails -XX:MaxTenuringThreshold=1

结合这个虚拟机参数设置，我们来构造符合预期的数据

-Xms20M -Xmx20M：java堆内存初始化值和最大值均为20M，不可扩展。

-Xmn10M ：同时给新生代分配10M内存，可以推算出老年代也是20-10=10M

通过-XX:SurvivorRatio=8可知，新生代中Eden : Survivor From : Survivor To = 8：1：1 ,所以新生代能用的最大的内存为9M。

通过-XX:MaxTenuringThreshold设置对象在新生代存活的最大年龄。

根据Eden : Survivor From : Survivor To = 8：1：1 来构造对象的大小。一个256KB的对象，确保在不符合MaxTenuringThreshold的情况下，Survivor To 区能够有足够的空间存放这个256KB的对象。

代码

package com.artisan.gc;

public class MaxTenuringThresholdTest {

  private static final int _1M = 1024 * 1024;

  /**
   * 
   * 
   * @Title: testMaxTenuringThreshold
   * 
   * @Description: -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8
   *               -XX:+UseSerialGC -verbose:gc -XX:+PrintGCDetails
   *               -XX:MaxTenuringThreshold=1
   * 
   * 
   * @return: void
   */
  public void testMaxTenuringThreshold() {
    // 根据JVM参数的设置，分配合理的大小，达到测试的目的
    byte[] object1 = new byte[_1M / 4];
    byte[] object2 = new byte[_1M * 4];
    // 什么时候进入老年代取决于-XX:MaxTenuringThreshold
    byte[] object3 = new byte[_1M * 4];
    object3 = null;
    byte[] object4 = new byte[_1M * 4];
  }
  public static void main(String[] args) {
    new MaxTenuringThresholdTest().testMaxTenuringThreshold();
  }

}

XX:MaxTenuringThreshold=1时的 GC日志

JVM-09自动内存管理机制【内存分配和回收策略】_sed_08

堆内存新生代可用空间为9M，首先在堆内存中分配了object1 256KB的内存，紧接着分配了object2 占用4M内存空间，此时新生代中还剩余8M-( 256KB+4M ) 的内存空间, object3 占用一个4M的内存空间，空间已经不够，提前触发了一次Minor GC

[GC [DefNew: 4695K->415K(9216K), 0.0056811 secs] 4695K->4511K(19456K), 0.0057238 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

发生Minor GC，Survivor From 只有1M的空间可用，也不够存放object2, 所以出发了担保机制，将该对象放到了老年代（10M），可以存放的下4M的object2 。但object1只有256KB，所以Survivor From可以存放的下object1。同时 MaxTenuringThreshold变为1 。

将object3置为null（这个时候已经没有引用，对象已经死亡，GC可以回收），分配object4 的时候又触发了一次Minor GC 。此时object1已经达到了MaxTenuringThreshold，符合清理到老年代的要求，可以看到新生代from space已经被清为0了。

from space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)

XX:MaxTenuringThreshold=15时的 GC日志

JVM-09自动内存管理机制【内存分配和回收策略】_sed_09

from space 使用了40% ，存放的是object1对象，因没达到XX:MaxTenuringThreshold，暂时还没有清理到老年代。

动态对象年龄判定

JVM-09自动内存管理机制【内存分配和回收策略】_老年代_10

理论

为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

案例

虚拟机参数设置及参数说明

-Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+UseSerialGC  -verbose:gc -XX:+PrintGCDetails -XX:MaxTenuringThreshold=15

代码

package com.artisan.gc;

public class MaxTenuringThresholdTest {

  private static final int _1M = 1024 * 1024;

  /**
   * 
   * 
   * @Title: testMaxTenuringThreshold
   * 
   * @Description: -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8
   *               -XX:+UseSerialGC -verbose:gc -XX:+PrintGCDetails
   *               -XX:MaxTenuringThreshold=15
   * 
   * 
   * @return: void
   */
  public void testMaxTenuringThreshold() {
    // 根据JVM参数的设置，分配合理的大小，达到测试的目的
    byte[] object1 = new byte[_1M / 4];
    byte[] object2 = new byte[_1M / 4];
    // 什么时候进入老年代取决于-XX:MaxTenuringThreshold
    byte[] object3 = new byte[_1M * 4];
    byte[] object4 = new byte[_1M * 4];
    object4 = null;
    object4 = new byte[_1M * 4];
  }
  public static void main(String[] args) {
    new MaxTenuringThresholdTest().testMaxTenuringThreshold();
  }

}

GC日志

JVM-09自动内存管理机制【内存分配和回收策略】_回收策略_11

设置了MaxTenuringThreshold=15，会发现运行结果中Survivor的空间占用仍然为0%，而老年代比预期增加了6%【和上个案例的结果比对】，也就是说，object1、object2对象都直接进入了老年代，而没有等到15岁的临界年龄。因为这两个对象加起来已经到达了512KB，并且它们是同年的，满足同年对象达到Survivor空间的一半规则。

如果我们只要注释掉其中一个对象new操作，就会发现另外一个就不会晋升到老年代中去了