JVM对象的内存布局

摘要：博主JVM系列都是跟随周志明先生的《深入了解JAVA虚拟机》一书来学习，记录并尝试解释下书中一些晦涩知识点，方便自己复习，如果能帮到他人，十分荣幸。

在HotSpot虚拟机中，对象在内存中存储的区域可以分为三个部分：对象头（Header），实例数据(Instance Data)，对齐填充（padding）:

对象头:

HotSpot虚拟机中对象头包含两部分信息:一部分是对象运行时的数据，如哈希码（HashCode），GC分代年龄，锁状态标志，线程持有的锁，偏向线程ID，偏向时间戳，这部分数据的长度在32bit和64bit的虚拟机中，官方称之为“Mark Word”.

•       GC分代年龄:Java堆是用来存放java实例对象的，JVM将java堆分成了两个不同的区域新生代（young）和老年代（old）。将新生代又分为了三个部分Eden，FromSurvivor，Tosurvivor，这主要是为了方便回收，至于如何回收，新生代老年代之间的转化参考另一片博客。。。。。。(明天编写。。).
•      锁状态标志：锁是为了解决多线程竞争的问题，在并发的情况下，可能出现多个线程同时抢占一个资源并对资源操作的情况，为了保证原子性，就是用锁，锁状态标志位就是用字面意思咯！
•       偏向线程ID这里博主认为是偏向锁指向的线程ID，简称偏向线程ID。因为为了保证原子性，在多线程的情况下，抢占到CPU的线程在运行的前后都会进行上锁和卸锁的操作，有一定的时间消耗。但是如果此时锁总是同一个线程拥有，很少发生竞争，我们就可以就说这个线程是锁的偏向线程。那么下一次运行该线程的时候，可以通过匹配的方式（查看锁偏向ID和进程ID是否一致）进入同步，无需进行繁琐的加锁和卸锁过程。
•        时间戳是一个数据类型，只是精度很高，避免出现脏读现象。

对象需要存储的数据很多，其实已经超过了32bit或64bitBitMap结构能够记录的极限，但是对象头信息是与对象自定义数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Word被设计成一种非固定数据以便在极小的空间内存储更多的信息，它会根据对象的状态来复用存储空间。

第二部分是类型指针，这是一个指向它的元数据的指针，即该对象是谁的实例。但是并不是所有的虚拟机都必须实现在对象数据上保留类型指针，换句话说，查找对象元数据信息不一定通过对象本身。如果对象是一个数组类型，对象头需要保存该数组的长度，因为虚拟机可以通过普通的 Java对象的元数据信息来确定Java对象的大小，但是无法从数组的元数据中确定数组大小。

        这里博主斗胆的认为是一个数组Array={1,2,3,4}，我们可以通过Array.length()来获取数组大小，但是通过Array[2](3) 数组中数据则不行

实例数据

     实例数据就是对象真正存储的有效数据，也就是程序代码中定义的各种类型的字段内容。无论是从父类继承的，或者自己定义的，都需要记录起来。这部分数据的存储顺序并不是用户定义的先后顺序决定的，而是受到虚拟机参数(FildsAllcationStyle)和字段在java源码中定义的顺序的影响。HotSpot虚拟机默认的分配策略为longs/doubles,ints,shorts/chars,bytes/booleans,oops(Ordinary Object Pointers)，从定义可以看出，相同字段的总是分配到一起，在满足这个条件下，父类中定义的变量会出现在子类变量之前。如果CompactFields参数值为true，那么子类中较窄的变量也可能出现在父类变量的空隙之中。

对齐填充

      对齐填充并不是必然存在的，因为它仅仅起着占位符的作用。由于HotSpotVm的自动内存管理要求对象起始地址必须是8字节的整数倍，换句话说，就是对象的大小必须是8的整数倍。而对象头部分刚好是8的整数倍，所以我们前面不做考虑，但是实例对象部分如果没有对齐的话，就需要通过对齐填充来补全