JVM之二：基础篇 - Java对象详解

        简述：上篇文章我们对JVM运行时数据区（包括方法区、Java堆、虚拟机栈、本地方法栈和程序计数器等）有了一个比较清晰的认识，那么对象的创建流程是什么样的呢？对象又包含哪些信息呢？程序又是如何去访问对象的呢？本章就讲带你去具体探秘Java对象。

1 对象的创建

        Java是一门面向对象的编程语言，在Java程序执行过程中时时刻刻都在创建对象，在语言层面上，创建对象通常通过 new 关键字而已。在Java虚拟机中，当遇到 new 关键字的时候，首先检查这个符号引用代表的类是否被加载、解析和初始化过，如果没有，则必须先执行相应的类加载过程（后续文章将会详细介绍Java类加载过程）。

        在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存大小在类加载完成后已经完全确定（稍后会讲到）。为对象分配内存的任务等同于把一块确定大小的内存从Java堆中划分出来（几乎所有的对象在存放在Java堆中）。假设内存绝对规整，把所有用过的内存都放在一边，空闲的放在另一边，中间放着一个指针作为分界点的指示器，那分配内存时仅仅就是把指针往空闲的一边挪动一段与对象大小相等的距离（指针碰撞）。如下图所示：

指针碰撞

如果内存不是规整的，已使用的内存和未使用的内存互相交错，那就没有办法简单地进行“指针碰撞”了，虚拟机必须维护一个列表，记录那些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象并更新列表上的记录（空闲列表）。如下图所示：

空闲列表

选择哪个分配方式由Java堆是否规整决定，而Java堆是否规整又由所采用的垃圾回收器是否带有压缩整理功能有关。因此，在使用 Serial 、ParNew（这两个是新生代垃圾回收器）等带Compact过程的收集器时，通常采用的是碰撞指针，而 CMS（老年代垃圾回收器）这种基于Mark-Sweep 算法的垃圾回收器时，通常采用的是空闲列表。

        除划分空间外，还有另一个需要考虑的问题是对象在虚拟机中创建时非常频繁的行为，及时是仅仅修改一个指针所指向的位置，在并发情况下也不是现成安全的，可能出现正在给对象A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针所指向的内存的情况。解决这个问题有两种方案：一是对分配内存的动作进行同步处理（虚拟机采用CAS配上失败重试的方式保证更新操作的原子性）；二是把内存分配的动作按照线程划分在不同的空间中进行，即在每个线程中预先分配一小块内存，这个称为本地线程分配缓冲（Thread Local Allocation Buffer ，TLAB）。哪个线程要分配内存，就在哪个线程的TLAB上分配，只有TLAB用完并分配新的TLAB时，才需要同步锁定。虚拟机是否使用TLAB，可以通过 -XX：+/-UseTLAB参数来设定。

        内存分配完成后，虚拟机需要将分配到的内存空间都初始化为零（不包括对象头），如果使用TLAB，这一工作过程也可以提前至TLAB分配时进行。这一步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，程序能访问到这些字段的数据类型所对应的零值。接下来，虚拟机要对 对象进行必要的设置，例如这个对象时哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头里。根据虚拟机当前的运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。关于对象头的具体内容，下节会详细讲述。

        在上面的工作完成后，从虚拟机的视角来看，一个新的对象已经产生了，但从Java程序的视角来看，对象创建在刚刚开始  -- 方法还没执行，所有的字段都还为零。所以一般来说，执行new指令后会接着执行 方法（构造方法），把对象按程序员的意愿进行初始化，这样一个真正可用的对象才算完全产生出来。

2 对象的内存布局

        在HotSpot虚拟机中，对象在内存中存储的布局可以分为3块区域：对象头（header）、实例数据（Instance Data）、对齐填充。 

对象内存结构

2.1 对象头（Header）

        HotSpot 虚拟机的对象头包含两部分信息：第一部分是用于存储对象自身的运行时数据，如哈希码、GC分代年龄信息、锁状态标识、线程持有的锁、偏向线程ID、偏向时间戳等，这部分数据的长度在32位和64位虚拟机中分别为32Bit和64Bit，官方称为 “Mark Word”。对需要存储的运行时数据很多，其实已经超过了32Bit或者64Bit  Bitmap结构所能记录的长度，但是对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Word 被设计成一个非固定的数据结构已便在极小的内存空间存储尽量多的信息。它会根据对象的状态复用自己的存储空间。例如，在32位的HotSpot虚拟机中，如果对象处于未被锁定的状态下，那么Mark Word 的32Bit空间中的25bit用于存储哈希码，4Bit用于存储对象的分代年龄标识，2Bit用于存储锁标示位，1Bit固定为0；第二部分是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针，换句话说，查找对象的元数据信息并不一定要经过对象本身。如果对象是一个Java数组，那在对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通Java对象的元数据信息确定Java对象的大小，但是从数组的元数据中却无法确定数据的大小。

2.2 实例数据（Instance Data）

        实例数据部分是对象真正存储的有效信息。包含程序代码中所定义的各种类型的字段内容，无论是从父类继承下来的还是在子类中定义的，都需要记录下来。这部分的存储顺序会受到虚拟机分配策略参数和字段在Java源码中定义的顺序的影响。HotSpot 虚拟机默认的分配策略为longs/doubles、ints、shorts/charts、bytes/booleans、oops(Ordinary Object Pointers)，从分配策略中可以看出，相同宽度的字段总是被分配到一起。在满足这个前提条件下，在父类中定义的变量会出现在子类中定义的变量之前。如果CompactFields参数值为true（默认为false），那么子类中较窄的变量也可能会插入到父类的变量空隙中。

2.3 对齐填充（Padding）

       对齐填充并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用，由于HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说就是对象的大小必须是8字节的整数倍。而对象头正好是8字节的倍数，因此，当对象实例数据部分没有对齐时，就需要对齐填充来补全。

3 对象的访问定位

        建立对象时为了访问对象，Java程序需要通过栈上的reference数据来操作堆上的具体对象。由于reference类型在Java虚拟机规范中只规定了一个指向对象的引用，并没有定义这个引用应该通过何种方式去定位、访问堆中对象的具体位置，所以对象访问方式也是取决于虚拟机实现而定的。目前主流的访问方式由使用句柄和指针两种。

        如果使用句柄方式的话，那么Java堆中将会划分出一块内存来作为句柄池，reference 中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息，如下图所示：

通过句柄访问对象

        如果通过指针访问对象，那么Java堆对象中就必须考虑如何放置访问类型数据的相关信息，而reference中存储直接就是对象的地址，如下图所示：

通过指针访问

        这两种访问方式各有优势，使用句柄来访问的最大好处就是reference中存储的是稳定的句柄地址，在对象被移动（垃圾收集时移动对象时非常普遍的行为）时只会改变句柄中的实例数据指针，而reference本身不需要修改；使用指针访问方式的最大好处就是速度更快，它节省了一次指针定位的时间开销，由于对象的访问在Java中非常频繁，因此这类开销积少成多后也是一项非常可观的执行成本。HotSpot 就是使用指针访问的方式。

        总结：通过本篇博文，相信读者朋友已经能够大致的了解Java对象在内存的创建和访问流程了，大多数情况下我们并不需要关心这个流程，可是作为向高阶程序员迈进的过程中，了解底层原理还是有必要。

        附加：本篇博文内容多借鉴《深入理解Java虚拟机》周志明；