JOL工具分析java对象大小
JOL全称为Java Object Layout，是分析JVM中对象布局的工具，该工具大量使用了Unsafe、JVMTI来解码布局情况，所以分析结果是比较精准的，接下来我们就具体操作下。
我们先创建几个待分析的类对象实例。
public class A {}
public class B {
private long s;
}
public class C {
private int a;
private long s;
}
int[] aa = new int[0];
然后创建分析主函数：
public class Test {
public static void main(String[] args) {
A a = new A();
System.out.println(ClassLayout.parseInstance(a).toPrintable());
B b = new B();
System.out.println(ClassLayout.parseInstance(b).toPrintable());
C c = new C();
System.out.println(ClassLayout.parseInstance(c).toPrintable());
int[] aa = new int[0];
System.out.println(ClassLayout.parseInstance(aa).toPrintable());
}
}
1.运行坏境为64位虚拟机。
2.主函数里所用到的包为jol工具，引入方式如下。
<dependency>
<groupId>org.openjdk.jol</groupId>
<artifactId>jol-core</artifactId>
<version>0.9</version>
</dependency>
输出结果如下：
image
结果如上图所示，A对象为16bytes，B对象为24bytes，C对象为24bytes，数组对象为16bytes。
接下来我们具体分析下这四个对象，看jol分析的结果是否正确。
java对象的组成部分：
- 1.对象头
在jvm虚拟机中每一个java对象都有一个对象头，对象头中包含标记字段以及对象指针，标记字段用来储存hash码、gc信息以及锁信息，而指针则指向改对象的类。在64位jvm虚拟机中这两部分都是64位的，所以也就是需要128位大小（16 bytes）。
注意：64位虚拟机中在堆内存小于32GB的情况下，UseCompressedOops是默认开启的，该参数表示开启指针压缩，会将原来64位的指针压缩为32位。 - 2.实例数据
类中所有的实例字段数据。 - 3.内存填充部分（alignment）
该部分作用是用来保证java对象在虚拟机中占内存大小为8N bytes。 - 4.数组长度
这个是数组对象才特有的。
java的基础数据类型所占内存情况如下表格：
| boolean | byte | short | char | int | long | float | double |
|---|---|---|---|---|---|---|---|
| 1 bytes | 1 bytes | 2 bytes | 2 bytes | 4 bytes | 8 bytes | 4 bytes | 8 bytes |
A对象：A对象就是一个空对象，所以在内存中占据大小就是对象头的大小等于16 bytes，由于开启指针压缩则对象头占据大小为12 bytes，但是12 bytes字节不是8的倍数所以需要进行内存对齐，最后加上了4 bytes的空白字节，最终该对象占据16 bytes大小。
B对象：B对象包含一个long基本数据类型，所以大小等于 12 bytes+8 bytes=20 bytes，20 bytes不是8N所以需要加上4 bytes的填充字节，最终该对象占据24 bytes。
C对象：C对象包含一个long、一个int基本数据类型，所以大小等于 12 bytes+8 bytes+4 bytes=24 bytes，正好8N，不需要内存填充，最终该对象占据24 bytes。
D对象：D对象是一个数组对象，因为数组对象会多一个数组长度存储部分，所以大小等于12 bytes+4 bytes=16 bytes，注意这里数组长度我给的是0，如果给的是1大家可以试试看输出结果又是多少呢。
至此我们已经分析完毕，感兴趣的小伙伴可以去试一下，加深下对对象内存大小的理解，或者更改下虚拟机的运行参数UseCompressedOops 设置为-XX:-UseCompressedOops关闭指针压缩看看结果又是多少。
参考：
