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

HotSpot虚拟机中多数收集器都采用了分代收集来管理堆内存， 那内存回收时就必须能决策哪些存活对象应当放在新生代， 哪些存活对象放在老年代中。为做到这点， 虚拟机给每个对象定义了一个对象年龄（Age） 计数器， 存储在对象头中 。对象通常在Eden区里诞生， 如果经过第一次Minor GC后仍然存活， 并且能被Survivor容纳的话， 该对象会被移动到Survivor空间中， 并且将其对象年龄设为1岁。对象在Survivor区中每熬过一次Minor GC， 年龄就增加1岁， 当它的年龄增加到一定程度（默认为15） ， 就会被晋升到老年代中。对象晋升老年代的年龄阈值， 可以通过参数-XX：MaxTenuringThreshold设置。

1.MaxTenuringThreshold=1的情况

当我们以-XX：MaxTenuringThreshold=1 记性参数设置时，来执行以下代码：

/**
 * @Des: 长期存活的对象进入老年代的测试
 * VM参数： -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC
 * -XX:MaxTenuringThreshold=1 ：当新生代对象的年龄达到1岁即可进入老年代
 * -XX:+PrintTenuringDistribution：JVM 在每次新生代GC时，打印出幸存区中对象的年龄分布。
 */
public class TestLongObjToOld {
    private static final int _1MB = 1024 * 1024;

    public static void testTenuringThreshold() {
        byte[] allocation1, allocation2, allocation3;
        allocation1 = new byte[_1MB / 4]; //256KB 什么时候进入老年代决定于XX:MaxTenuringThreshold设置
        allocation2 = new byte[4 * _1MB]; //4048KB
        allocation3 = new byte[4 * _1MB];//4048KB eden共占用了 8352KB
        allocation3 = null;  //断开引用，成为垃圾对象
        allocation3 = new byte[4 * _1MB]; //再申请分配4MB内存，放不下，触发Minor GC
    }

    public static void main(String[] args) {
        testTenuringThreshold();
    }
}

输出结果：

[GC (Allocation Failure) [DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 1)
- age   1:     896768 bytes,     896768 total
: 6079K->875K(9216K), 0.0036167 secs] 6079K->4971K(19456K), 0.0036538 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 1)
- age   1:        584 bytes,        584 total
: 5056K->0K(9216K), 0.0008881 secs] 9152K->4968K(19456K), 0.0009051 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 def new generation   total 9216K, used 4316K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  eden space 8192K,  52% used [0x00000000fec00000, 0x00000000ff037058, 0x00000000ff400000)
  from space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400248, 0x00000000ff500000)
  to   space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
 tenured generation   total 10240K, used 4968K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
   the space 10240K,  48% used [0x00000000ff600000, 0x00000000ffada120, 0x00000000ffada200, 0x0000000100000000)
 Metaspace       used 3244K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 353K, capacity 388K, committed 512K, reserved 1048576K

针对输出结果我们可以拆分来看，当allocation1和allocation2对象加载的时候，两个对象加在一起是4.25MB，Eden区都能存放下（Eden区大小9216K），没有任何问题，内存图如下：

image

当allocation3对象创建的时候，这时发现eden区空间不足，则会触发第一次GC：

image

我们先来看第一次GC的打印：

[GC (Allocation Failure) [DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 1)
- age   1:     896768 bytes,     896768 total
: 6079K->875K(9216K), 0.0036167 secs] 6079K->4971K(19456K), 0.0036538 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 

GC：代表发生了一次垃圾回收，前面没有Full修饰，表明这时一次Minor GC；

Allocation Failure：表明本次引起GC的原因是因为在年轻代中没有足够的空间能够存储新的数据了。

6079K->875K(9216K) 三个参数分别为：GC前该内存区域(这里是年轻代)使用容量，GC后该内存区域使用容量，该内存区域总容量。

6079K->4971K(19456K) 三个参数分别为：堆区垃圾回收前的大小，堆区垃圾回收后的大小，堆区总大小。

0.0036167 secs:代表本次新生代GC耗时

那么我们本次日志得出的结论：

• 该次GC新生代减少了 6079 - 875 = 5204KB
• Heap区总共减少了 6079 - 4971 = 1108KB
• 5204KB - 1108KB = 4096KB 代表一共有 4096KB对象从年轻代转移到了老年代

ok，我们通过画图来形象的表示下：

image

这里请大家注意：由于我们的 allocation1对象和allocation2对象都是强引用不会被回收，所以肯定会直接放入幸存者区域，allocation1对象可以放入，但是我们的allocation2对象太大是无法放入S1区的，因此根据我们上面讲的垃圾收集器的默认担保机制，allocation2对象会直接进入到我们的老年代进行存放。 这也解释了为什么最终有4096K（4MB）大小的对象进入了老年代

当第一次GC完后Eden区就有足够的空间存放 allocation3对象了。

我们再来看第二次GC情况：

allocation3 = null; //这行代码一旦执行，那么我们的allotion3对象没有了直接引用者

如下：

image

接着最后一行代码开始执行：

allocation3 = new byte[4 * _1MB]; //再申请分配4MB内存，放不下，触发Minor GC

这次继续申请分配4MB大小对象放入Eden区，那么依然又会存在分配不下触发GC，继续分析如下日志：

[GC (Allocation Failure) [DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 1)
- age   1:        584 bytes,        584 total
: 5056K->0K(9216K), 0.0008881 secs] 9152K->4968K(19456K), 0.0009051 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]

那么我们本次日志得出的结论：

• 该次GC新生代减少了 5056- 0 = 5056KB
• • 注意：新生代直接减少到了0！代表所有幸存区S1里的对象全部转移到了老年代！（因为我们的年龄阈值设置的刚好就是1）allocation3对象是直接被回收了
• Heap区总共减少了 9152- 4968= 4184KB
• • 主要就是我们的allocation3对象以及少量系统对象被回收了
• 5056KB - 4184KB =872 KB 代表一共有 872KB对象从年轻代转移到了老年代

最后内存结果如下：

image

跟我们最后的内存日志结果匹配：

Heap
 def new generation   total 9216K, used 4316K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  eden space 8192K,  52% used [0x00000000fec00000, 0x00000000ff037058, 0x00000000ff400000)
  from space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400248, 0x00000000ff500000)
  to   space 1024K,   0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
 tenured generation   total 10240K, used 4968K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
   the space 10240K,  48% used [0x00000000ff600000, 0x00000000ffada120, 0x00000000ffada200, 0x0000000100000000)

2.MaxTenuringThreshold=15的情况

代码没有变化，只是JVM参数发生了改变，我们可以直接看运行后的日志结果：

[GC (Allocation Failure) [DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 15)
- age   1:     877184 bytes,     877184 total
: 6079K->856K(9216K), 0.0025954 secs] 6079K->4952K(19456K), 0.0026263 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] 
[GC (Allocation Failure) [DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
- age   1:        728 bytes,        728 total
: 5037K->0K(9216K), 0.0009100 secs] 9133K->4949K(19456K), 0.0009267 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 

注意：我们神奇的发现：在第二次GC后，新生代的占用空间变成了0！这是尼玛啥情况！我们明明已经设置了阈值为15

这里跟这个对象年龄有另外一个规则可以让对象进入老年代，不用等待15此GC过后才可以。

那么到底是什么规则呢？我想有些同学应该已经猜到了，就是我们的动态年龄判断规则，下一篇文章我们将继续给大家带来动态年龄判断规则以及JVM的空间分配担保机制到底是怎么玩的。