垃圾收集器（三）内存分配与回收策略

发表于 更新于 分类于
本文字数： 6.8k 阅读时长 ≈ 6 分钟
简单介绍Java虚拟机中的垃圾收集器（三）内存分配与回收策略，包括：对象优先在Eden分配，大对象直接进入老年代，长期存活的对象将进入老年代，动态对象年龄判定，空间分配担保等。

垃圾收集器（二）内存分配与回收策略

前文

  自动内存管理可以总结为自动化的处理两个问题：给对象分配内存和回收分配给对象的内存。给对象分配内存，宏观的看就是在堆上分配（但也可能经过JIT编译后被拆散为标量类型并间接的栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况下也可能会直接分配在老年代中，分配的规则也并非百分百固定，细节由当前所使用的收集器组合决定，以及虚拟机中与内存相关的参数的设置。

  接下来会介绍几个最常见的内存分配规则，并通过代码去验证这些规则。所有代码在测试时使用Client模式虚拟机运行，没有手工的指定收集器组合，验证的是在使用Serial/Serial Old收集器下的内存分配和回收的策略（ParNew / Serial Old收集器组合的规则也基本一致）。

思维导图

2019091301_内存分配和回收策略

第五节 内存分配与回收策略

5.1 对象优先在Eden分配

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

  虚拟机提供了**-XX:+PrintGCDetails**这个收集器日志参数，使虚拟机在发生垃圾收集时打印内存回收日志，并且在进程退出时输出当前内存各区域的分配情况。在应用中内存回收日志一般是打印到文件后通过日志工具进行分析。

  下列代码中testAllocation()方法中，尝试分配3个2MB大小和1个4MB大小的对象，在运行时通过-Xms20M、-Xmx20M、-Xmn10M这三个参数限制了Java堆大小为20MB，不可扩展，其中10MB分配给新生代，剩下的10MB分配给老年代。-XX:SurvivorRatio=8决定了新生代中Eden区与一个Survivor区的空间比例是8:1，从输出的结果可以清晰的看到“eden space 8192K、from space 1024K、to space 1024K”的信息，新生代总可用空间为9216KB（Eden区+1个Survivor区的总容量）。

  执行testAllocation()中分配allocation4对象的语句时会发生一次Minor GC，这次GC的结果是新生代6651KB变为148KB，而总内存占用量则几乎没有减少（因为allocation1、allocation2、allocation3三个对象都是存活的，虚拟机几乎没有找到可回收的对象）。这次GC发生的原因是给allocation4分配内存的时候，发现Eden已经被占用了6MB，剩余空间已不足以分配allocation4所需的4MB内存，因此发生Minor GC。GC期间虚拟机又发现已有的3个2MB大小的对象全部无法放入Survivor空间（Survivor空间只有1MB大小），所以只能通过分配担保机制提前转移到老年代。

  这次GC结束后，4MB的allocation4顺利分配在Eden中，因此程序执行完的结果是Eden占用4MB（被allocation4占用），Survivor空闲，老年代被占用6MB（被allocation1、allocation2、allocation3占用）。

1
2
3
4
5
6
7
8
9
10
11
12
private static final int _1MB = 1024 * 1024;

/**
 * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
 */
public static void testAllocation(){
    byte[] allocation1, allocation2, allocation3, allocation4;
    allocation1 = new byte[2 * _1MB];
    allocation2 = new byte[2 * _1MB];
    allocation3 = new byte[2 * _1MB];
    allocation4 = new byte[4 * _1MB]; //出现一次Minor GC
}

运行结果

Minor GC和Full GC不同点？

  • 新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。
  • 老年代GC（Major GC / Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴随着至少一次的Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程）。Major GC的速度一般会比Minor GC慢10倍以上。

5.2 大对象直接进入老年代

  所谓大对象是指需要大量连续内存空间的Java对象，最典型的大对象就是较长的字符串或数组。大对象的内存分配是对虚拟机非常考验的事情，特别是一群“朝生夕死”的“短命大对象”，应该在编程时避免出现这种场景。经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集来安置它们。

  虚拟机提供了一个**-XX:PretenureSizeThreshold**参数，大于此参数值的对象会直接在老年代分配。这样的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制。

  执行下列代码的testPretenureSizeThreshold()后，Eden空间几乎没有被使用，老年代的10MB空间则被使用了40%，所以allocation对象是直接被分配在了老年代，原因就是PretenureSizeThreshold参数设置为3MB。

1
2
3
4
5
6
7
8
9
10
private static final int _1MB = 1024 * 1024;

/**
 * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
 * -XX:PretenureSizeThreshold=3145728
 */
public static void testPretenureSizeThreshold(){
    byte[] allocation;
    allocation = new byte[4 * _1MB]; //直接分配在老年代中
}

运行结果

注意：PretenureSizeThreshold参数只对Serial和ParNew两款收集器有效，Parallel Scavenge收集器不会识别此参数，此收集器一般不用设置，如果遇到需要使用此参数场景，推荐使用ParNew+CMS收集器组合。

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

  虚拟机采用分代收集的思想来管理内存，自然需要能够识别对象应被归属的代，所以虚拟机给每个对象定义了一个对象年龄计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活，且能被Survivor容纳的话，会被移动到Survivor空间，并且年龄设置为1。对象在Survivor区中每“熬过”一次Minor GC，年龄就会增加1岁，当年龄增加到一定程度（默认为15），会被晋升到老年代。对象晋升到老年代的年龄阈值，可以通过参数**-XX:MaxTenuringThreshold**设置。

  可以尝试分别以1和15为值设置参数MaxTenuringThreshold，测试下列代码的testTenuringThreshold()。对象allocation1需要256KB内存，Survivor空间可以容纳。当MaxTenuringThreshold=1时，allocation1在第二次GC发生时进入老年代，新生代已使用内存GC后非常干净的变为0KB。而MaxTenuringThreshold=15时，第二次GC发生后，allocation1对象还留在新生代Survivor空间，此时新生代仍有40KB占用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
private static final int _1MB = 1024 * 1024;

/**
 * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=1
 * -XX:PrintTenuringDistribution
 */
@SuppressWarning("unused")
public static void testTenuringThreshold(){
    byte[] allocation1, allocation2, allocation3;
    allocation1 = new byte[_1MB / 4];
    //什么时候进入老年代取决于-XX:MaxTenuringThreshold设置
    allocation2 = new byte[4 * _1MB];
    allocation3 = new byte[4 * _1MB];
    allocation3 = null;
    allocation3 = new byte[4 * _1MB];
}

  MaxTenuringThreshold=1运行结果。

运行结果

  MaxTenuringThreshold=15运行结果。

运行结果

运行结果

5.4 动态对象年龄判定

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

  执行下列代码的testTenuringThreshold2()，设置-XX:MaxTenuringThreshold=15，可以发现运行结果中Survivor空间占用依然为0%，而老年代比预期增加6%，所以allocation1、allocation2直接进入了老年代，而不是等到age=15。这两个对象内存和为512KB，且年龄相同，满足同年占比一半的规则，可以注释掉其中一个对象观察结果。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
private static final int _1MB = 1024 * 1024;

/**
 * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15
 * -XX:PrintTenuringDistribution
 */
@SuppressWarning("unused")
public static void testTenuringThreshold2(){
    byte[] allocation1, allocation2, allocation3, allocation4;
    allocation1 = new byte[_1MB / 4];
    //allocation1+allocation2大于Survivor空间一半
    allocation2 = new byte[_1MB / 4];
    allocation3 = new byte[4 * _1MB];
    allocation4 = new byte[4 * _1MB];
    allocation4 = null;
    allocation4 = new byte[4 * _1MB];
}

运行结果

5.5 空间分配担保

  在发生Minor GC之前，虚拟机会检查老年代最大可用连续空间是否大于新生代所有对象总空间，如果成立则可以保证此Minor GC是安全的。如果不成立，虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代对象的平均大小，如果大于则会尝试进行一次Minor GC，尽管这次是承担着风险的。如果HandlePromotionFailure值设置不允许，或者小于平均大小，则改为进行一次Full GC。

  “冒险”是在承担什么风险？我们知道新生代使用复制收集算法，为了内存利用率，只使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象Minor GC后仍然存活的情况，就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代。但老年代能进行担保的前提是其自身有足够的空间可以容纳这些对象，有多少对象在GC后会活下来是无法提前知道的，所以只好取每次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多空间。

  取平均值进行比较其实是一种动态概率的手段，如果某次Minor GC后存活的对象突然激增，依然会导致担保失败（HandlePromotionFailure）。如果出现了HandlePromotionFailure失败，就只好在失败后再发动一次Full GC。虽然担保失败时最麻烦，但大部分情况下都还会将HandlePromotionFailure开关打开，避免Full GC太过频繁，参考下列代码，在JDK 6 Update 24之前的版本中运行测试。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
private static final int _1MB = 1024 * 1024;

/**
 * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:HandlePromotionFailure
 */
@SuppressWarning("unused")
public static void testHandlePromotion(){
    byte[] allocation1, allocation2, allocation3, allocation4, allocation5, allocation6, allocation7;
    allocation1 = new byte[2 * _1MB];
    allocation2 = new byte[2 * _1MB];
    allocation3 = new byte[2 * _1MB];
    allocation1 = null;
    allocation4 = new byte[2 * _1MB];
    allocation5 = new byte[2 * _1MB];
    allocation6 = new byte[2 * _1MB];
    allocation4 = null;
    allocation5 = null;
    allocation6 = null;
    allocation7 = new byte[2 * _1MB];
}

运行结果

运行结果

  在JDK 6 Update 24之后的版本中结果会有差异，HandlePromotionFailure参数不再影响到虚拟机的空间分配担保策略，观察OpenJDK中的源码变化，虽然HandlePromotionFailure参数仍然被定义了，但代码中已不会再使用它，规则改变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则进行Full GC。

1
2
3
4
5
6
7
8
9
10
bool TenuredGeneration::promotion_attempt_is_safe(size_t
max_promotion_in_bytes) const {
    //老年代最大可用的连续空间
    size_t available = max_contiguous_available();
    //每次晋升到老年代的平均大小
    size_t av_promo = (size_t)gc_status()->avg_promoted()->padded_average();
    //老年代可用空间是否大于平均晋升大小，或者老年代可用空间是否大于当此GC时新生代所有对象容量
    bool res = (available >= av_promo) || (available >= max_promotion_in_bytes);
    return res;
}

参考博客和文章书籍等：

《深入理解Java虚拟机》

因博客主等未标明不可引用，若部分内容涉及侵权请及时告知，我会尽快修改和删除相关内容