上一篇:Java内存回收 Java内存分配 下一篇:类文件结构

2778 2017-10-05 2020-06-25

前言：之前只是提到过，对象的内存分配是在Java堆上进行。这次，我们来详细分析下。

一、概述

这篇将会讲解几条最普遍的内存分配规则，并通过代码区验证这些规则。接下来的代码在测试时使用Parallel Scavenge/Serial Old组合（JKD1.8 HopSpot的默认组合）收集器下的内存分配策略。

几条最普遍的内存分配规则，如下

  • 对象优先在Eden分配。
  • 大对象直接进入老年代。
  • 长期存活的对象将进入老年代。
  • 动态对象年龄判定。
  • 空间分配担保。

在正式讲解规则前，我们先来温习一下堆中的内存分布，如下（HotSpot下默认比例）

分代

其次需要注意的是新生代可用空间不包含to space，总体概括为

  • 新生代 = Eden + from + to。
  • 新生代可用空间 = Eden + from。
  • 新生代固定空间 = to。
  • 一般情况下，收集器默认新生代的容量为新生代的可用空间，即新生代总大小 - to = Eden + from。

二、对象优先在Eden分配

1、原理

  • 限制Java堆的大小，分配固定大小的内存给新生代和老年代
  • 当为对象分配内存时，首先在新生代Eden区分配。而当Eden区没有足够空间时，进行一次Minor GC，通过复制算法复制对象到to space。这里限制Minor GC的效果，使其失效
  • 由于第二块Survivor空间不够，只好通过分配担保机制提前转移到老年代

其中

  • 新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕死的特性，所以Minor GC非常频繁，一般回收速度也比较快
  • 老年代GC（Major GC/Full GC）：指发生在老年代的GC，出现Major GC，经常会伴随至少一次的Minor GC（并非绝对）
  • **java -XX:+PrintFlagsFinal -version |FINDSTR /i “:”**命令可以查看Java虚拟的默认参数设置（如默认收集器组合）

其中需要用到的参数

参数说明
-verbose:gc输出虚拟机中GC的详细情况
-Xms设置堆的最小值，如-Xms20m，设为堆最小值为20M
-Xmx设置堆的最大值，当最小堆值等于最大堆值时，堆不会自动扩展
-Xmn设置堆新生代的大小
-XX:SurvivorRatio设置Eden区与Survivor区的空间比例
-XX:+PrintGCDetails设置发生垃圾收集行为时打印内存回收日志，并退出时输出当前内存各区域的分配情况

2、代码分析

  • Parallel Scavenge/Serial Old组合（默认收集器参数为UseParallelGC）

代码如下

private static final int _1MB = 1024 * 1024;
/**
 * 限制Java堆大小20M，不可扩展，新生代10M，Eden:Survivor=8:1，退出时打印当前内存区域信息，以下同
 * VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
 */
public static void main(String[] args) {
    byte[] allocation1, allocation2, allocation3, allocation4;
    allocation1 = new byte[2 * _1MB];
    allocation2 = new byte[2 * _1MB];
    allocation3 = new byte[2 * _1MB];//此时eden区已有6M，总大小8M
    allocation4 = new byte[4 * _1MB];//eden区空间不够，出现一次Minor GC
}

结果如下

堆数据分析

截图代码分析如下

[GC (Allocation Failure) [PSYoungGen: 6951K->1023K(9216K)] 6951K->3604K(19456K), 0.0033071 secs] [Times: user=0.03 sys=0.02, real=0.00 secs] 
Heap
 PSYoungGen      total 9216K, used 5357K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
  eden space 8192K, 52% used [0x00000000ff600000,0x00000000ffa3b8e8,0x00000000ffe00000)
  from space 1024K, 99% used [0x00000000ffe00000,0x00000000ffeffd48,0x00000000fff00000)
  to   space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
 ParOldGen       total 10240K, used 6676K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  object space 10240K, 65% used [0x00000000fec00000,0x00000000ff285368,0x00000000ff600000)
 Metaspace       used 3508K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 383K, capacity 388K, committed 512K, reserved 1048576K

GC日志说明：
1.由于新生代可用空间只有9M，之前已经使用了6M，最后一个4M对象无法储存，于是进行垃圾收集
2.新生代垃圾收集采用复制算法，当from space到达1M时，to sapce也容纳不下，gc失败
3.于是进行老年代分配担保（猜测：Eden对象被放置一个队列，逐一转移进老年代，这里显示的是第一个2M对象，这也就解释java堆使用的3M）
4.最后情况是3个2M对象进入老年代，4M对象进入eden space

再次验证，代码及结果如下

allocation1 = new byte[1 * _1MB];
allocation2 = new byte[2 * _1MB];
allocation3 = new byte[3 * _1MB];// 此时eden区已有6M，总大小8M
allocation4 = new byte[4 * _1MB];// eden区空间不够，出现一次Minor GC

[GC (Allocation Failure) [PSYoungGen: 7976K->1007K(9216K)] 7976K->4636K(19456K), 0.0052235 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
Heap
 PSYoungGen      total 9216K, used 8414K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
  eden space 8192K, 90% used [0x00000000ff600000,0x00000000ffd3bd00,0x00000000ffe00000)
  from space 1024K, 98% used [0x00000000ffe00000,0x00000000ffefbd38,0x00000000fff00000)
  to   space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
 ParOldGen       total 10240K, used 3628K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  object space 10240K, 35% used [0x00000000fec00000,0x00000000fef8b368,0x00000000ff600000)
 Metaspace       used 3508K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 383K, capacity 388K, committed 512K, reserved 1048576K
1.猜测：1M、2M、3M对象被放置队列，逐一转移进入老年代，但由于某种条件限制3M对象没有进入成功
2.最后情况是1M对象和2M对象进入老年代，3M和4M对象进入eden space，而不是1M、2M、3M对象进入老年代，4M对象进入eden space

allocation1 = new byte[4 * _1MB];
allocation2 = new byte[3 * _1MB];// 此时eden区已有7M，总大小8M
allocation3 = new byte[2 * _1MB];// eden区空间不够，出现一次Minor GC
allocation4 = new byte[1 * _1MB];

[GC (Allocation Failure) [PSYoungGen: 7976K->1023K(9216K)] 12072K->8706K(19456K), 0.0060564 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
[Full GC (Ergonomics) [PSYoungGen: 1023K->0K(9216K)] [ParOldGen: 7683K->8676K(10240K)] 8706K->8676K(19456K), [Metaspace: 3500K->3500K(1056768K)], 0.0117040 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
Heap
 PSYoungGen      total 9216K, used 3318K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
  eden space 8192K, 40% used [0x00000000ff600000,0x00000000ff93d898,0x00000000ffe00000)
  from space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)
  to   space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000)
 ParOldGen       total 10240K, used 8676K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  object space 10240K, 84% used [0x00000000fec00000,0x00000000ff4792f0,0x00000000ff600000)
 Metaspace       used 3508K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 383K, capacity 388K, committed 512K, reserved 1048576K
1.GC前java堆使用了近12M的内存
2.最后情况是1M、2M对象进入eden space，而3M、4M进入老年代，但老年代仍然有1M的未知数据
  • Serial/Serial Old组合（指定参数UseSerialGC）

增加参数：-XX:+UseSerialGC后，结果如下

[GC (Allocation Failure) [DefNew: 6951K->1023K(9216K), 0.0085164 secs] 6951K->3557K(19456K), 0.0085760 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
[GC (Allocation Failure) [DefNew: 5275K->0K(9216K), 0.0059427 secs] 7809K->7652K(19456K), 0.0059867 secs] [Times: user=0.00 sys=0.00, real=0.01 secs] 
Heap
 def new generation   total 9216K, used 4178K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  eden space 8192K,  51% used [0x00000000fec00000, 0x00000000ff014930, 0x00000000ff400000)
  from space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
  to   space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
 tenured generation   total 10240K, used 7652K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
   the space 10240K,  74% used [0x00000000ff600000, 0x00000000ffd793e8, 0x00000000ffd79400, 0x0000000100000000)
 Metaspace       used 3506K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 383K, capacity 388K, committed 512K, reserved 1048576K

第一次GC日志：跟最上面的第一次GC日志类似，GC后，Java堆包括了from space了的1M，以及老年代的2M
第二次GC日志：此时新生代从5M变为了0，转移了4M，清理from space的1M。但java堆总空间不变，即from space的1M转移到了to space
最后情况是4M对象在eden space，1M、2M、3M对象在老年代，以及1M的未知数据

3、小结

从上面的代码验证中，我们不难发现，对象优先在Eden区分配只是一条普遍的内存分配规则。在不同收集器中，收集器分配和回收对象的具体细节都是有差别的。总而言之，每个收集器都有自己特定条件限制，有着自己的内部实现细节，但不同之中又有着共同点，即前面所说的那些普遍的规则。

鉴于代码验证的复杂性，后面只说明理论，证明其逻辑可行性。

三、大对象直接进入老年代

  • 大对象指的是需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组
  • 经常出现大对象容易导致内存还有不少空间时，就提前触发垃圾收集以获取足够的连续空间来“安置”它们
  • 可以指定参数，设定对象超过该值时，直接在老年代分配。避免了在Eden区及两个Survivor区之间发生大量的内存复制（复制算法）

其中需要用到的参数

参数说明
+PretenureSizeThreshold令大于这个值的对象直接在老年代分配

补充：这个参数只对Serial和ParNew两块收集器有效，Parallel Scavenge收集器不认识这个参数（一般不需要设置）。如果遇到必须使用此参数的场合，可以考虑ParNew加CMS的收集器组合。

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

  • 虚拟机根据对象的对象头部分所存储的**分代年龄信息（对象年龄计数器）**识别对象年龄。
  • 如果对象在Eden区出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，对象年龄设为1。
  • 对象在Survivor区每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认15岁），就将会被晋升到老年代中。

其中，需要使用到的参数如下

参数说明
MaxTenuringThreshold设置晋升老年代的年龄阀值

五、动态对象年龄判定

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

六、空间分配担保

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

补充：老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来在实际完成内存回收之前是无法明确知道的，所有只好取之前每一次回收到老年代对象容量的平均大小值作为经验值，决定是否进行Full GC来让老年代腾出更多空间。

七、总结

内存回收与垃圾收集器在很多时候都是影响系统性能、并发能力的主要因素之一，虚拟机之所以提供多种不多的收集器以及提供大量的调节参数，是因为只有根据实际应用需求、实现方式选择最优的收集方式才能获取最高的性能。

总访问次数: 267次, 一般般帅 创建于 2017-10-05, 最后更新于 2020-06-25

进大厂！ 欢迎关注微信公众号，第一时间掌握最新动态！