HotSpot虚拟机对象探秘（六）

对象的创建

• 虚拟机遇到一条new指令时，首先检查这个指令的参数能否在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已经被加载、解析和初始化过。如果没有那么首先执行相应的类的加载过程。

• 在类加载检查通过之后，接下来虚拟机需要为新生的对象分配内存。对象所需的内存大小在类加载完成之后便可完全确定，为对象分配内存的任务等同于把一块确定大小的内存从java堆中划分出来。假设Java堆内存是完全规整的，所有用过的内存放在一边，空闲的内存放在另一边，中间放着一个指针作为分界点的指示器，这种分配方式成为“指针碰撞”。如果java堆空间不是规整的，已使用内存和空闲内存都是相互交叉的，那就没办法简单的使用指针碰撞了，虚拟机必须维护一个列表，记录哪些内存是可用的，在分配内存的时候从列表中找到一块足够大的空间划分给对象，并更新列表上的记录，这种分配方式成为“空闲列表”。选择那种分配方式由Java堆是否规整决定，而Java堆是否规整由所采用的垃圾收集器是否带有压缩整理功能决定。因此，使用Serial、ParNew 等带Compact 过程的收集器采用指针碰撞，而使用CMS这种基于Mark-Sweep算法的收集器，通常采用空闲列表。

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

  TLAB:
  TLAB，避免了多线程冲突，在给对象分配内存时，每个线程使用自己的TLAB，这样可以避免线程同步，提高了对象分配的效率。TLAB本身占用eEden区空间，在开启TLAB的情况下，虚拟机会为每个Java线程分配一块TLAB空间。参数-XX:+UseTLAB开启TLAB，JVM默认是开启的，TLAB空间的内存非常小，缺省情况下仅占有整个Eden空间的1%，可以通过选项-XX:TLABWasteTargetPercent设置TLAB空间所占用Eden空间的百分比大小。TLAB空间一般不会很大，因此大对象无法在TLAB上进行分配，总是会直接分配在堆上。TLAB空间由于比较小，因此很容易装满。比如，一个100K的空间，已经使用了80KB，当需要再分配一个30KB的对象时，肯定就无能为力了。这时虚拟机会有两种选择，第一，废弃当前TLAB，这样就会浪费20KB空间；第二，将这30KB的对象直接分配在堆上，保留当前的TLAB，这样可以希望将来有小于20KB的对象分配请求可以直接使用这块空间。实际上虚拟机内部会维护一个叫作refill_waste的值，当请求对象大于refill_waste时，会选择在堆中分配，若小于该值，则会废弃当前TLAB，新建TLAB来分配对象。这个阈值可以使用TLABRefillWasteFraction来调整，它表示TLAB中允许产生这种浪费的比例。默认值为64，即表示使用约为1/64的TLAB空间作为refill_waste。默认情况下，TLAB和refill_waste都会在运行时不断调整的，使系统的运行状态达到最优。如果想要禁用自动调整TLAB的大小，可以使用-XX:-ResizeTLAB禁用ResizeTLAB，并使用-XX:TLABSize手工指定一个TLAB的大小。-XX:+PrintTLAB可以跟踪TLAB的使用情况。一般不建议手工修改TLAB相关参数，推荐使用虚拟机默认行为。

• 接下来虚拟机需要对对象进行必要的参数设置，例如这个对象是哪个类的实例、如何才能找到类的元信息、对象的Hash码、对象的GC分代年龄这些信息都会设置在对象的头（Object Header）

• 上面的工作完成之后，从虚拟机视角，一个新的对象就产生了，从java视角来看，对象创建才刚刚开始——<init> 方法还没有执行，所有的字段还为0，所以执行new命令之后按照程序员的意愿初始化之后，一个真正可用的对象才算产生出来。

对象内存分配流程图

• 类加载以及内存分配流程
  
• 对象在堆内存的分配流程图
  

对象的内存布局

在HotSpot虚拟机中，对象在内存找那个存储的布局可以分为3块区域：对象头（Hesder）、实例数据（Instance）和对其填充（Padding）。

• 对象头：头信息主要包含两部分，第一部分用户存储对象自身的运行时数据如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等，这部分数据的长度在32位和64位虚拟机（未开启指针压缩）中分别为：32bit和64bit。官方称之为“Mark word”。对象需要存储的运行时的数据很多，其实已经超过了32位和64位Bitmap结构所能记录的限度，但是对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Word 被设计成一个非固定长度的数据结构以便在极小的空间内存存储尽量多的信息，它会根据对象的状态复用自己的存储空间。另外一部分是类型指针，即对象指向他的类元数据的指针，虚拟机通过这个指针确定对象是哪个类的实例，并不是所有的虚拟机实现都必须在对象数据上保留类型指针是通过，换句话说，查找对象的元数据信息并不一定经过对象本身。如果对象为一个数组，那么对象头还必须有一块用于记录数组长度的数据。
  Mark Word在不同的锁状态下存储的内容不同，在32位JVM中是这么存的：
  
• 实例数据：是对象真正存储的有效信息，也是程序代码中所定义的各种类型的字段内容。无论是从父类继承下来的还是子类定义的，都需要记录下来。这部分的存储顺序会受虚拟机的分配策略参数（FiledsAllocationStype）和字段在Java源码中定义的顺序影响。HotSpot的分配策略为longs/doubles、ints、shorts/char、bytes、booleans、oops(Ordinary Object Pointers)，从分配策略可以看出，相同宽度的字段会被分配到一起，在满足这个条件的前提下，在父类定义的变量也会出现在子类之前。如果CompactFields参数值为true（默认为true），那么子类之中较窄的变量也可能插入到分类变量的空隙之中。
• 对象填充：对象填充不是必然存在的，也没有特别的含义，它仅仅是占位符的左右。主要是因为HotSpot JVM内存管理系统要求对象起始地址必须为8的整数倍，也就是对象大小必须为8的整数倍，对象头部分正好是8的整数倍（1倍或者2倍），因此对象实例数据部分没有对齐的，就需要通过填充方式来补全。

对象的访问定位

建立对象主要是为了使用对象，我们的Java程序主要是通过栈上的Reference数据来操作堆上的具体对象，Reference只规定了一个指向对象的引用，并没有定义这个引用对象通过何种方式去定位和访问堆上的对象的具体位置，所以对象访问取决于虚拟机的自己的实现而定。目前主流的方式主要有句柄和直接指针。

• 句柄访问： 使用句柄访问的话，Java堆中将划分一块内存出来作为句柄池，Reference中存储的就是对象的句柄池，而句柄池包含了对象实例数据与数据类型各自的具体地址信息如图：
  
• 直接指针：使用直接指针访问的话，Java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，而Reference中存储的直接就是对象地址，如图：
  

句柄访问和直接指针访问的优缺点：
使用句柄的最大好处就是Reference中存储的是隐定的句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而Reference本身不需要修改。直接指针最大的好处是速度快，节省了一次指针的定位开销，由于对象的访问在Java中非常频繁，因此这类开销积少成多也是一项非常可观的执行成本。Sun HotSpot虚拟机主要是采用
直接指针的方式访问的对象的。从整体软件开发范围来看，各种语言和框架使用句柄访问的情况也十分常见。