JVM系列之对象的内存布局和访问定位

对象的内存布局

在HotSpot虚拟机中对象在堆内存存储时包含三块区域：对象头、实例数据、对齐填充。虚拟机的对象内存布局如下图：

 

对象头（Header）

对象头包含的信息：运行时数据、类型指针、数组长度（如果对象是Java数组时）。如果是32位虚拟机，那么这三部分各占32bit，如果是64位虚拟机，则各占64bit。

对象头信息中的运行时数据（Mark Word）：identityHashCode对象标识码（调用方法System.identityHashCode()计算而得，不同于继承自Object对象的hashCode）、GC 分代年龄、锁状态标识、是否偏向锁、线程持有的锁、偏向线程ID、偏向时间戳等信息（有关对象锁的详细信息请参看Java并发编程系列）。该部分被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据自己的状态复用自己的存储空间。

 

类型指针：对象指向方法区类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。（如果采用的是句柄方式访问，对象头信息就没有存储该类型指针，具体参看后面对象的访问定位）

数组长度：如果对象是一个 Java 数组，那在对象头中还必须有一块用于记录数组长度的数据。因为虚拟机可以通过普通 Java 对象的元数据信息确定 Java 对象的大小，但是从数组的元数据中无法确定数组的大小。

实例数据（Instance Data）

实例数据部分是对象真正存储的有效信息，也是在程序代码中所定义的各种类型的字段内容，父类继承的和子类定义的字段都会记录。

对齐填充（Padding）

占位符（没有其他作用），虚拟机内存管理系统要求对象起始地址必须是 8 字节的整数倍，也就是对象的大小必须是8字节的整数倍，所以当实例的数据部分没有对齐时，就需要通过对齐填充来补全。

对象的访问定位

在对象创建完成后，会有一个对应着堆内存中该对象的引用地址reference存放在局部变量表中，当需要使用该对象时，则通过该reference数据在堆内存中定位。目前主流的访问定位方式有两种：句柄方式、直接指针。

句柄方式：堆中维护一个句柄池，句柄包含类型数据指针和对象数据指针（栈中的 reference 指向句柄池中的句柄，句柄指向堆中的实例，句柄指向方法区的类型数据）。此种方式优势为句柄比较稳定，在对象被移动（垃圾收集时移动对象）时，只会改变句柄中的实例指针，而reference不需要改变。但是需要另外开辟一块区域（堆中的句柄池）。

直接指针：堆中的对象直接包含类型数据指针（栈中的 reference 指向堆中对象，对象指向方法区中的类信息 ）。此方式节省一次指针定位开销，相对来说速度更快。（HotSpot采用的是此种方式）

压缩指针

由于对象的数量多，在64位虚拟机中使用64位的指针将浪费大量内存，所以为了节约内存开销引入了指针压缩的概念（虚拟机选项-XX:+UseCompressedOops，默认开启），将堆中的64位指针压缩成32位，这样以来，对象头占用的内存就从16字节下降到了12字节。

当然，也不是所有的指针都会压缩，一些特殊类型的指针JVM不会优化，比如指向PermGen的Class对象指针(JDK8中指向元空间的Class对象指针)、本地变量、堆栈元素、入参、返回值和NULL指针等。 

相关问题

1、GC 分代年龄为什么默认为 15？

在GC中，如果对象在Survivor区复制一次，年龄增加1。当对象达到设定的阈值时，将会晋升到老年代。默认情况下，并行GC的年龄阈值为15，并发GC的年龄阈值为6。由于age只有4位，可存储的最大值为15，这就是-XX:MaxTenuringThreshold选项最大值为15的原因。

2、对象锁状态类型有几种？

偏向锁、轻量级锁、重量级锁

3、当对象启用锁之后MarkWord中为什么就没有hashCode了？

当对象加锁后（偏向、轻量级、重量级），MarkWord的字节没有足够的空间保存hashCode，因此该值会移动到管程Monitor中。

4、从对象所占内存分析为什么要使用基本数据类型？

64位JVM中，比如Integer类，仅有一个私有的int字段（4个字节），而头部额外多出16个字节，因此，每一个Integer的内存额外开销至少是400%，这也是java要引入基本类型的原因之一。 

--------------------------------------------------------END---------------------------------------------------------------

由于本人水平有限，如有纰漏，欢迎指正！

本文的图片使用的是在线画图软件https://www.processon.com/i/5ee19c46e401fd1fd28801db

--------------------------------------------------------END---------------------------------------------------------------