对象头
这里不讲对象头是个什么货色，感兴趣的同学能够看我的其它文章。对象头的大小个别和零碎的位数无关，也和启动参数 UseCompressedOops无关：
32位零碎，占用 8 字节
64位零碎，开启 UseCompressedOops时，占用 12 字节，否则是16字节
实例数据
原生类型的内存占用状况如下：
boolean 1个字节
byte 1个字节
short 2个字节
char 2个字节
int 4个字节
float 4个字节
long 8个字节
double 8个字节
援用类型的内存占用和零碎位数以及启动参数 UseCompressedOops无关
32位零碎占4字节
64位零碎，开启 UseCompressedOops时，占用4字节，否则是8字节
对齐填充
在Hotspot中，为了更加容易的治理内存，个别会应用8字节进行对齐。
意思是每次调配的内存大小肯定是8的倍数，如果对象头+实例数据的值不是8的倍数，那么会从新计算一个较大值，进行调配。
后果
有了对象各局部的内存占用大小，能够很轻松的计算出ABCD各对象在64位零碎，且开启 UseCompressedOops参数时的大小。
A对象只蕴含一个对象头，大小占12字节，不是8的倍数，须要4字节进行填充，一共占16字节
B对象蕴含一个对象头和int类型，12+4=16，正好是8的倍数，不须要填充。
C对象蕴含一个对象头和long类型，12+8=20，不是8的倍数，须要4个字节进行填充，占24字节
D对象蕴含一个对象头和援用类型，12+4=16，正好是8的倍数，不须要填充。
能够得出，VisualVM的显示后果有点问题，次要因为以下两点：