转载

Java对象内存布局之谜

一个Java对象在堆上除了成员信息，还有其他内容吗？他在堆上是如何布局的？接下来本文将以Hotspot为例分析Java对象内存布局之谜。

堆中的Java对象

在Hotspot中一个Java对象包含如下三个部分:

对象头
实例信息
对齐信息

对象头

对象头要分两种类型：

普通对象包含：Mark Word、Klass Pointer
数组对象包含：Mark Word、Klass Pointer、Array Length

不同类型JVM下，对象头每一部分占用内存大小

数据类型	32位JVM(bit)	64位JVM(bit)	开启指针压缩的64位JVM(bit)
Mark Word	32	64	64
Klass Pointer	32	64	32
Array Length	32	32	32

可见在64位JVM中开启指针压缩( -XX:UseCompressedOops )后, JVM只是针对类型指针(Klass Pointer)进行压缩。而数组长度不管在什么类型的JVM里都是32bit。

不同类型JVM下，对象头占用内存大小

数据类型	32位JVM(bit)	64位JVM(bit)	开启指针压缩的64位JVM(bit)
普通对象	64	128	96
数组对象	96	160	128

由此可见，对象头还是比较耗空间的。那么用了这么多内存，对象头具体都存放了写什么信息呢？

mark word

mark word里存放的是对象运行时的信息，不同状态的对象里mark word 存放的信息是不同的。具体内容可看下表：

32位JVM

存储内容(30bit)	锁状态(2bit)
identify_hashcode:25 \| age:4 \| biased_lock:1	(01)无锁
threadId:23 \| age:4 \| epoch:2 \| biased_lock:1	(01)偏向锁
ptr_to_lock_record:30	(00)轻量级锁
ptr_to_heavyweight_monitor:30	(10)重量级锁
gc_info:30	(11)GC标记

64位JVM

存储内容(62bit)	锁状态(2bit)
unused:25 \| identify_hashcode:25 \| unused:1 \| age:4 \| biased_lock:1	(01)无锁
threadId:54 \| epoch:2 \| unused:1 \| age:4 \| biased_lock:1	(01)偏向锁
ptr_to_lock_record:62	(00)轻量级锁
ptr_to_heavyweight_monitor:62	(10)重量级锁
gc_info:62	(11)GC标记

名词解释：
- age: GC分代年龄
- identify_hashcode: 对象的hashcode值
- threadId: 偏向线程的Id
- biased_lock: 是否是偏向锁，因为只占一个bit,所以只有0和1
- epoch: 偏向时间戳
- ptr_to_lock_record: 指向栈中轻量级锁记录的指针
- ptr_to_heavyweight_monitor:指向栈中重量级锁的指针
- GC标记: 用于GC算法对对象的标记
- gc_info: GC算法给不同状态的标记信息
为什么要这么实现？
1. 因为对象头信息是跟对象自身定义的数据结构无关的。这些信息所记录的状态是用于JVM对对象的管理的。更重要的是，不同状态的存储内容基本上是互斥的。所以基于节省空间的角度考虑， Mark Word 被设计成动态的。
identify_hashcode 既然有方法可以生成为什么要放在对象头里？
1. 当一个对象的hashCode()未被重写时，调用这个方法会返回一个由随机数算法生成的值。因为一个对象的hashCode不可变，所以需要存到对象头中。当再次调用该方法时，会直接返回对象头中的hashcode。
2. identify_hashcode 采用延迟加载的方式生成。只有调用hashcode()时，才会写入对象头。若一个类的hashCode()方法被重写，对象头中将不存储hashcode信息，因为一般我们自己实现的hashcode()并未将生成的值写入对象头。
当对象的状态不是默认状态时，对象的hashcode去哪儿了？
1. 当是轻量级锁/重量级锁时，jvm会将对象的 mark word 复制一份到栈帧的Lock Record中。等线程释放该对象时，再重新复制给对象。
2. 如果一个对象头中存在hashcode,则无法使用偏向锁。