GC分代年龄为什么是15？

在JVM中，对象在Eden区诞生，当内存不够用时触发GC进行对象回收，但不是所有的对象都可以被回收，当一个对象还在被引用时就无法回收，此时JVM会将其移动到“幸存者区”。

幸存者区内部又分为“From区”和“To区”，在幸存者区，对象仍然要面临GC，每经历一次GC，对象就要在From区和To区之间来回移动，每移动一次对象的GC年龄就加1，当年龄加到15时(不绝对)，JVM会将对象移动到老年区。

为什么GC分代年龄最大为15呢？

JAVA对象结构

对象的GC年龄肯定和对象相关，信息肯定保存在对象的某块区域，我们平时看不到是因为Java对开发者屏蔽了一些数据。

我们平时写代码，编写的只是对象的实例数据，但其实Java对象除了自身的实例数据外，还包括头信息和对齐字节，如下图所示：

对象的GC年龄就保存在对象的头信息里，除此之外，头信息还记录了对象的锁标记，大家常常说的“Java锁的是对象而不是代码”就是这个道理，上锁修改的是头信息中的锁标记。

对象的头信息内存分配不同的JVM实现不一样，一般来说32位占8字节，64位占16字节(开启压缩指针占12字节)。

头信息分为以下两个部分：

• Mark Word
• Klass Pointer

Mark Word

用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向的线程ID等数据。

由于需要考虑到JVM的空间效率，节省内存，Mark Word 被设计成在一个“非固定的数据结构”，以便在极小的空间内记录更多的数据。

简而言之：不同的标记位表示Mark Word存储的数据意义不同，如下图：

我在Mac上测试，显示Mark Word占用8个字节。

Klass Pointer

Klass Pointer是一个指向了实例的类元数据指针，JVM通过这个指针来判断对象属于哪一个类的实例。

内存固定，在64位JVM上采用4个字节存储。

如何证明

上面说的只是理论，直到现在我们都没有看到对象的头信息，对齐字节，对象的年龄，如何来证明理论是对的呢？

OpenJDK提供了一个工具包，可以输出对象的结构布局信息。

引入依赖

<dependency>    <groupId>org.openjdk.jol</groupId>    <artifactId>jol-core</artifactId>    <version>0.9</version></dependency>

编写一段测试代码，如下：

/** * @Author: pch * @Date: 2019/12/23 09:08 * @Description: 查看对象的头信息 */public class HeaderTest {public static void main(String[] args) throws InterruptedException {Person p = new Person();//不调用hashCode() 不会记录哈希码int hashCode = p.hashCode();//转16进制输出，与头信息中HashCode进行比较String hex = Integer.toHexString(hashCode);System.out.println("HashCode十六进制:"+hex);print(p);}static void print(Person p){System.err.println(ClassLayout.parseInstance(p).toPrintable());}}class Person{private boolean flag;}

控制台输出如下：

至于为什么数据是倒着存储的，请参考“大小端模式”。

笔者对控制台输出的内容作了部分注释，其实到这里答案已经有了。

GC分代年龄为什么最大为15？

因为Object Header采用4个bit位来保存年龄，4个bit位能表示的最大数就是15！

如何证明GC后年龄会加1

手动触发一次GC即可。

测试代码如下：

Person p = new Person();//手动触发GCSystem.gc();print(p);

控制台输出：

不是必须到达15岁才会晋升为老年代，JVM采用动态年龄计算，以防止老年代内存过于宽裕，而新生代内存被撑爆。