JOLJava对象内存布局

　　如果想要深入的学习synchronized关键字，必须提前掌握的一部分知识就是Java对象内存布局。通过这篇文章一起探索Java对象在虚拟机中是如何保存的。
　　在正式学习后续内容之前，先约定如下：Java对象：本篇中所说的Java对象是指普通Java对象，不包括数值对象、Class对象虚拟机：除了特别说明以外，虚拟机均指HotSpot虚拟机Java对象内存布局
　　在HotSpot虚拟机里，对象在堆内存中的存储布局可以划分为三个部分：对象头（Header）、实例数据（InstanceData）和对齐填充（Padding）。
　　Header
　　Java对象头包括两个部分：MarkWord和ClassPointer，对于数组对象对象头还包括数组长度（Length），下面具体看一下每个部分：
　　1MarkWord
　　用于存储对象自身的运行时数据，如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等，这部分数据的长度在32位和64位的虚拟机（未开启压缩指针）中分别为32个比特和64个比特。
　　对象需要存储的运行时数据很多，其实已经超出了32、64位Bitmap结构所能记录的最大限度，但对象头里的信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，MarkWord被设计成一个有着动态定义的数据结构，以便在极小的空间内存储尽量多的数据，根据对象的状态复用自己的存储空间。
　　MarkWord在不同状态时存储的数据如下所示（32和64位虚拟机）：
　　在某一时刻MarkWord只会处于上图中某一个锁状态，根据当前对象synchronized锁升级的不同锁状态，MarkWord保存的数据会不同，这就为什么说MarkWord是动态定义的数据结构。具体synchronized章节讲解。
　　2ClassPointer
　　这部分是一个类型指针，即对象指向它的类型元数据的指针，Java虚拟机通过这个指针来确定该对象是哪个类的实例。
　　并不是所有的虚拟机实现对象头都具有类型指针，这和对象的访问定位方式有关，主流的访问方式主要有使用句柄和直接指针两种：使用句柄的方式：Java堆中将可能会划分出一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自具体的地址信息直接指针的方式：Java堆中对象的内存布局就必须考虑如何放置访问类型数据的相关信息，reference中存储的直接就是对象地址，如果只是访问对象本身的话，就不需要多一次间接访问的开销（HotSpot虚拟机采用该方式，所以对象头中有类型指针用于存放对象结构的引用）
　　通过句柄访问对象
　　通过直接指针访问对象
　　3Length
　　如果对象是一个Java数组，那在对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小，但是如果数组的长度是不确定的，将无法通过元数据中的信息推断出数组的大小。
　　这就解释了为什么Java数组一旦初始化了数组长度，就不能修改InstanceData
　　实例数据部分是对象真正存储的有效信息，即我们在程序代码里面所定义的各种类型的字段内容，无论是从父类继承下来的，还是在子类中定义的字段都必须记录起来。这部分的存储顺序会受到虚拟机分配策略参数（XX：FieldsAllocationStyle参数）和字段在Java源码中定义顺序的影响。HotSpot虚拟机默认的分配顺序为longsdoubles、ints、shortschars、bytesbooleans、oops（OrdinaryObjectPointers，OOPs），从以上默认的分配策略中可以看到，相同宽度的字段总是被分配到一起存放，在满足这个前提条件的情况下，在父类中定义的变量会出现在子类之前。如果HotSpot虚拟机的XX：CompactFields参数值为true（默认就为true），那子类之中较窄的变量也允许插入父类变量的空隙之中，以节省出一点点空间。Padding
　　对象的第三部分是对齐填充，这并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。由于HotSpot虚拟机的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说就是任何对象的大小都必须是8字节的整数倍。对象头部分已经被精心设计成正好是8字节的倍数（1倍或者2倍），因此，如果对象实例数据部分没有对齐的话，就需要通过对齐填充来补全。JOL工具
　　JOL的全称是JavaObjectLayout。是一个用来分析JVM中对象内存布局的小工具。包括对象在内存中的占用情况，实例对象的引用情况等等。
　　使用JOL需要在Maven项目中引入依赖：dependencygroupIdorg。openjdk。jolgroupIdjolcoreartifactIdversion0。16versiondependency
　　JOL高版本依赖和低版本输出对象内存布局时略有不同，但是高版本对对象布局描述更加直观。
　　测试没有任何字段的类的代码如下：publicclassJolTest｛publicstaticvoidmain（String〔〕args）｛Console。log（VMDESC）；Console。log（VM。current（）。details（））；Console。log（JavaObjectLayout）；Console。log（ClassLayout。parseInstance（newObject（））。toPrintable（））；｝｝
　　输出结果：
　　通过上面的输出结果可以获取如下信息：
　　1、VMDESCRunning64bitHotSpotVM：运行的虚拟机是64位HotSpot虚拟机Objectsare8bytesaligned：对象是基于8byte对齐Fieldsizesbytype：4，1，1，2，2，4，4，8，8〔bytes〕和Arrayelementsizes：4，1，1，2，2，4，4，8，8〔bytes〕：描述了对象字段和数组元素各种数据类型占用的内存大小，依次是：4引用数据类型占用4byte（因默认开启压缩指针）；1boolean占用1byte；1byte占用1byte；2short占用2byte；2char占用2byte；4int占用4byte；4float占用4byte；8long占用8byte；8double占用8byte
　　2、JavaObjectLayout08（objectheader：mark）0x0000000000000001（nonbiasable；age：0）：对象的MarkWord占用了8byte（64bit），此时存储的数据为：0x0000000000000001，即无锁状态84（objectheader：class）0xf80001e5：对象的ClassPointer占用了4byte（32bit），因为开启了压缩指针，引用数据类型占用4byte124（objectalignmentgap）：对象的Padding占用了4byte，因为MarkWordClassPointer12byte，不是8byte的整数，所以需要4byte的对齐填充Instancesize：16bytes：当前对象占用的内存大小，当前对象没有实例数据，也就是一个对象最小占用内存大小为16byte（64位虚拟机）
　　压缩指针默认是开启（XX：UseCompressedOops）的，当我们关闭压缩指针（XX：UseCompressedOops），重新执行测试程序输入如下：
　　1、VMDESCFieldsizesbytype：8，1，1，2，2，4，4，8，8〔bytes〕和Arrayelementsizes：8，1，1，2，2，4，4，8，8〔bytes〕：关闭压缩指针后只有引用数据类型占用内存由4byte变为8byte，其余基本数据类型占用内存不变
　　2、JavaObjectLayout08（objectheader：mark）0x0000000000000001（nonbiasable；age：0）：较关闭压缩指针之前无变化88（objectheader：class）0x0000019fd2471c00：ClassPointer由之前占用4byte变为占用8byte，由于此时MarkWordClassPointer16byte，是8byte整数倍，所以不需要对齐填充
　　测试具有字段的类的代码如下：（开启压缩指针）publicclassJolTest｛publicstaticvoidmain（String〔〕args）｛Console。log（ClassLayout。parseInstance（newDemo（））。toPrintable（））；｝publicstaticclassDemo｛privateStringreferenceField；privatebooleanbooleanField；privatebytebyteField；privateshortshortField；privatecharcharField；privateintintField；privatefloatfloatField；privatelonglongField；privatedoubledoubleField；｝｝
　　输出结果如下：