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），没有任何问题，内存图如下：
当allocation3对象创建的时候，这时发现eden区空间不足，则会触发第一次GC：
我们先来看第一次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，我们通过画图来形象的表示下：
这里请大家注意：由于我们的 allocation1对象和allocation2对象都是强引用不会被回收，所以肯定会直接放入幸存者区域，allocation1对象可以放入，但是我们的allocation2对象太大是无法放入S1区的，因此根据我们上面讲的垃圾收集器的默认担保机制，allocation2对象会直接进入到我们的老年代进行存放。 这也解释了为什么最终有4096K（4MB）大小的对象进入了老年代
当第一次GC完后Eden区就有足够的空间存放 allocation3对象了。
我们再来看第二次GC情况：
allocation3 = null; //这行代码一旦执行，那么我们的allotion3对象没有了直接引用者
如下：
接着最后一行代码开始执行：
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对象从年轻代转移到了老年代
最后内存结果如下：
跟我们最后的内存日志结果匹配：
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的空间分配担保机制到底是怎么玩的。
