JVM对象创建
对象创建流程
主要流程如下:

类加载检查
虚拟机遇到一条new指令时,首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用,并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有,那必须先执行相应的类加载过程。 new指令对应到语言层面上讲是,new关键词、对象克隆、对象序列化等。
分配内存
在类加载检查通过后,接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类 加载完成后便可完全确定,为对象分配空间的任务等同于把 一块确定大小的内存从Java堆中划分出来。 这个步骤有两个问题:
- 如何划分内存。
- 在并发情况下, 可能出现正在给对象A分配内存,指针还没来得及修改,对象B又同时使用了原来的指针来分配内存的情况。
划分内存的方法
- "指针碰撞"(Bump the Pointer)(默认用指针碰撞) 如果Java堆中内存是绝对规整的,所有用过的内存都放在一边,空闲的内存放在另一边,中间放着一个指针作为分界点的指示器,那所分配内存就仅仅是把那个指针向空闲空间那边挪动一段与对象大小相等的距离。
- "空闲列表"(Free List) 如果Java堆中的内存并不是规整的,已使用的内存和空 闲的内存相互交错,那就没有办法简单地进行指针碰撞了,虚拟机就必须维护一个列表,记录上哪些内存块是可用的,在分配的时候从列表中找到一块足够大的空间划分给对象实例,并更新列表上的记录
解决并发问题的方法:
- CAS(compare and swap) 虚拟机采用CAS配上失败重试的方式保证更新操作的原子性来对分配内存空间的动作进行同步处理。
- 本地线程分配缓冲(Thread Local Allocation Buffer,TLAB) 把内存分配的动作按照线程划分在不同的空间之中进行,即每个线程在Java堆中预先分配一小块内存。通过-XX:+/-UseTLAB参数来设定虚拟机是否使用TLAB(JVM会默认开启-XX:+UseTLAB),-XX:TLABSize 指定TLAB大小。
初始化零值
内存分配完成后,虚拟机需要将分配到的内存空间都初始化为零值(不包括对象头), 如果使用TLAB,这一工作过程也可以提前至TLAB分配时进行。这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用,程序能访问到这些字段的数据类型所对应的零值。
设置对象头
初始化零值之后,虚拟机要对对象进行必要的设置,例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头Object Header之中。
在HotSpot虚拟机中,对象在内存中存储的布局可以分为3块区域:对象头(Header)、实例数据(Instance Data)和对齐填充(Padding)。HotSpot虚拟机的对象头包括两部分信息,第一部分用于存储对象自身的运行时数据,如哈希码(HashCode)、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等。对象头的另外一部分是类型指针,即对象指向它的类元数据的指针,虚拟机通过这个指针来确定这个对象是哪个类的实例。
32位对象头

64位对象头

对象头在hotspot的C++源码markOop.hpp文件里的注释如下:
c++
// Bit-format of an object header (most significant first, big endian layout below):
//
// 32 bits:
// --------
// hash:25 ------------>| age:4 biased_lock:1 lock:2 (normal object)
// JavaThread*:23 epoch:2 age:4 biased_lock:1 lock:2 (biased object)
// size:32 ------------------------------------------>| (CMS free block)
// PromotedObject*:29 ---------->| promo_bits:3 ----->| (CMS promoted object)
//
// 64 bits:
// --------
// unused:25 hash:31 -->| unused:1 age:4 biased_lock:1 lock:2 (normal object)
// JavaThread*:54 epoch:2 unused:1 age:4 biased_lock:1 lock:2 (biased object)
// PromotedObject*:61 --------------------->| promo_bits:3 ----->| (CMS promoted object)
// size:64 ----------------------------------------------------->| (CMS free block)
//
// unused:25 hash:31 -->| cms_free:1 age:4 biased_lock:1 lock:2 (COOPs && normal object)
// JavaThread*:54 epoch:2 cms_free:1 age:4 biased_lock:1 lock:2 (COOPs && biased object)
// narrowOop:32 unused:24 cms_free:1 unused:4 promo_bits:3 ----->| (COOPs && CMS promoted object)
// unused:21 size:35 -->| cms_free:1 unused:7 ------------------>| (COOPs && CMS free block)
执行方法
执行方法,即对象按照程序员的意愿进行初始化。对应到语言层面上讲,就是为属性赋值(注意,这与上面的赋零值不同,这是由程序员赋的值),和执行构造方法。
对象大小与指针压缩
对象大小可以用jol-core包查看,引入依赖,用于分析Java对象在内存中的布局
xml
<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-core</artifactId>
<version>0.9</version>
</dependency>
java
import org.openjdk.jol.info.ClassLayout;
/**
* 计算对象大小
*/
public class JOLSample {
public static void main(String[] args) {
ClassLayout layout = ClassLayout.parseInstance(new Object());
System.out.println(layout.toPrintable());
System.out.println();
ClassLayout layout1 = ClassLayout.parseInstance(new int[]{});
System.out.println(layout1.toPrintable());
System.out.println();
ClassLayout layout2 = ClassLayout.parseInstance(new A());
System.out.println(layout2.toPrintable());
}
// -XX:+UseCompressedOops 默认开启的压缩所有指针
// -XX:+UseCompressedClassPointers 默认开启的压缩对象头里的类型指针Klass Pointer
// Oops : Ordinary Object Pointers
public static class A {
//8B mark word
//4B Klass Pointer 如果关闭压缩-XX:-UseCompressedClassPointers或-XX:-UseCompressedOops,则占用8B
int id; //4B
String name; //4B 如果关闭压缩-XX:-UseCompressedOops,则占用8B
byte b; //1B
Object o; //4B 如果关闭压缩-XX:-UseCompressedOops,则占用8B
}
}
输出结果:
- Object对象分析
kotlin
java.lang.Object object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1) //mark word
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0) //mark word
8 4 (object header) e5 01 00 f8 (11100101 00000001 00000000 11111000) (-134217243) //Klass Pointer
12 4 (loss due to the next object alignment)
Instance size: 16 bytes
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total
解析:
- OFFSET 0-7 :Mark Word(8字节),存储对象的运行时数据(哈希码、GC分代年龄、锁状态等)
- OFFSET 8-11 :Klass Pointer(4字节),指向对象的类元数据,因为开启了压缩指针所以是4字节
- OFFSET 12-15 :对齐填充(4字节),确保对象大小是8的倍数
- 总大小 :16字节
- 空int数组分析
python
[I object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) 6d 01 00 f8 (01101101 00000001 00000000 11111000) (-134217363)
12 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
16 0 int [I.<elements> N/A
Instance size: 16 bytes
Space losses: 0 bytes internal + 0 bytes external = 0 bytes total
解析:
- OFFSET 0-7 :Mark Word(8字节)
- OFFSET 8-11 :Klass Pointer(4字节)
- OFFSET 12-15 :数组长度(4字节),存储数组元素个数,这里是0
- OFFSET 16 :数组元素区域,因为是空数组所以大小为0
- 总大小 :16字节
- 自定义类A的对象分析
python
com.jvm.JOLSample$A object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 4 (object header) 01 00 00 00 (00000001 00000000 00000000 00000000) (1)
4 4 (object header) 00 00 00 00 (00000000 00000000 00000000 00000000) (0)
8 4 (object header) 61 cc 00 f8 (01100001 11001100 00000000 11111000) (-134165407)
12 4 int A.id 0
16 1 byte A.b 0
17 3 (alignment/padding gap)
20 4 java.lang.String A.name null
24 4 java.lang.Object A.o null
28 4 (loss due to the next object alignment)
Instance size: 32 bytes
Space losses: 3 bytes internal + 4 bytes external = 7 bytes total
解析:
- OFFSET 0-11 :对象头(12字节)= Mark Word(8字节)+ Klass Pointer(4字节)
- OFFSET 12-15 :int id字段(4字节)
- OFFSET 16 :byte b字段(1字节)
- OFFSET 17-19 :内部对齐填充(3字节),确保后续引用字段按4字节对齐
- OFFSET 20-23 :String name字段(4字节),压缩指针
- OFFSET 24-27 :Object o字段(4字节),压缩指针
- OFFSET 28-31 :外部对齐填充(4字节),确保整个对象大小是8的倍数
- 总大小 :32字节
关键概念说明
- 压缩指针 : -XX:+UseCompressedOops 默认开启,将引用从8字节压缩到4字节
- 内存对齐 :JVM要求对象大小必须是8字节的倍数,字段也有对齐要求
- 字段重排序 :JVM会重新排列字段顺序以减少内存浪费
- Space losses :显示内部填充和外部对齐造成的内存浪费
关于对齐填充:对于大部分处理器,对象以8字节整数倍来对齐填充都是最高效的存取方式。
-
CPU缓存行对齐 缓存行大小 :现代CPU的缓存行(Cache Line)通常是64字节,而8字节对齐是缓存行大小的约数,有助于提高缓存效率。 减少缓存未命中 :对齐的对象可以更好地利用CPU缓存,减少跨缓存行访问的情况。
-
内存访问性能 硬件优化 :大多数现代处理器在访问按8字节对齐的内存地址时性能最佳,特别是64位系统。 原子操作支持 :8字节对齐确保了64位数据类型(如long、double)的原子性读写操作。
-
指针压缩优化 压缩指针算法 :在64位JVM中,启用压缩指针( -XX:+UseCompressedOops )时,JVM利用对象8字节对齐的特性,将64位指针压缩为32位。 地址计算 :由于对象地址的低3位总是0(8字节对齐),JVM可以省略这3位,用32位表示更大的地址空间。
-
垃圾收集器效率 标记位图 :垃圾收集器使用位图来标记对象,8字节对齐简化了位图的计算和管理。 对象遍历 :GC在遍历堆内存时,可以按8字节步长快速定位对象边界。
-
内存管理简化 分配算法 :内存分配器可以使用更简单的算法,因为所有对象都按固定大小对齐。 碎片减少 :统一的对齐规则有助于减少内存碎片,提高内存利用率。
-
平台兼容性 跨平台一致性 :8字节对齐在不同硬件平台上都能提供良好的性能,确保JVM的跨平台特性。 SIMD指令支持 :现代CPU的SIMD指令通常要求数据按特定字节数对齐,8字节是一个通用的对齐要求。
Java对象指针压缩
- jdk1.6 update14开始,在64bit操作系统中,JVM支持指针压缩
- jvm配置参数:UseCompressedOops,compressed--压缩、oop(ordinary object pointer)--对象指针
- 启用指针压缩:-XX:+UseCompressedOops(默认开启),禁止指针压缩:-XX:-UseCompressedOops
为什么要进行指针压缩?
- 在64位平台的HotSpot中使用32位指针(实际存储用64位),内存使用会多出1.5倍左右,使用较大指针在主内存和缓存之间移动数据,占用较大宽带,同时GC也会承受较大压力
- 为了减少64位平台下内存的消耗,启用指针压缩功能
- 在jvm中,32位地址最大支持4G内存(2的32次方),可以通过对对象指针的存入堆内存时压缩编码、取出到cpu寄存器后解码方式进行优化(对象指针在堆中是32位,在寄存器中是35位,2的35次方=32G),使得jvm只用32位地址就可以支持更大的内存配置(小于等于32G)
- 堆内存小于4G时,不需要启用指针压缩,jvm会直接去除高32位地址,即使用低虚拟地址空间
- 堆内存大于32G时,压缩指针会失效,会强制使用64位(即8字节)来对java对象寻址,这就会出现1的问题,所以堆内存不要大于32G为好