HotSpot虚拟机对象探秘

对象的创建

Java是一门面向对象的编程语言，Java程序运行过程中无时无刻都有对象被创建出来。在语言层面 上，创建对象通常（例外：复制、反序列化）仅仅是一个new关键字而已，而在虚拟机中，对象（文 中讨论的对象限于普通Java对象，不包括数组和Class对象等）的创建又是怎样一个过程呢？ 当Java虚拟机遇到一条字节码new指令时，首先将去检查这个指令的参数是否能在常量池中定位到 一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。如果没有，那 必须先执行相应的类加载过程，本书第7章将探讨这部分细节。 在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成 后便可完全确定（如何确定将在2.3.2节中介绍），为对象分配空间的任务实际上便等同于把一块确定 大小的内存块从Java堆中划分出来。假设Java堆中内存是绝对规整的，所有被使用过的内存都被放在一 边，空闲的内存被放在另一边，中间放着一个指针作为分界点的指示器，那所分配内存就仅仅是把那 个指针向空闲空间方向挪动一段与对象大小相等的距离，这种分配方式称为“指针碰撞”（Bump The Pointer）。但如果Java堆中的内存并不是规整的，已被使用的内存和空闲的内存相互交错在一起，那 就没有办法简单地进行指针碰撞了，虚拟机就必须维护一个列表，记录上哪些内存块是可用的，在分 配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录，这种分配方式称 为“空闲列表”（Free List）。选择哪种分配方式由Java堆是否规整决定，而Java堆是否规整又由所采用 的垃圾收集器是否带有空间压缩整理（Compact）的能力决定。因此，当使用Serial、ParNew等带压缩 整理过程的收集器时，系统采用的分配算法是指针碰撞，既简单又高效；而当使用CMS这种基于清除 （Sweep）算法的收集器时，理论上[1]就只能采用较为复杂的空闲列表来分配内存。 除如何划分可用空间之外，还有另外一个需要考虑的问题：对象创建在虚拟机中是非常频繁的行 为，即使仅仅修改一个指针所指向的位置，在并发情况下也并不是线程安全的，可能出现正在给对象 A分配内存，指针还没来得及修改，对象B又同时使用了原来的指针来分配内存的情况。解决这个问题 有两种可选方案：一种是对分配内存空间的动作进行同步处理——实际上虚拟机是采用CAS配上失败 重试的方式保证更新操作的原子性；另外一种是把内存分配的动作按照线程划分在不同的空间之中进 行，即每个线程在Java堆中预先分配一小块内存，称为本地线程分配缓冲（Thread Local Allocation Buffer，TLAB），哪个线程要分配内存，就在哪个线程的本地缓冲区中分配，只有本地缓冲区用完 了，分配新的缓存区时才需要同步锁定。虚拟机是否使用TLAB，可以通过-XX：+/-UseTLAB参数来 设定。 内存分配完成之后，虚拟机必须将分配到的内存空间（但不包括对象头）都初始化为零值，如果 使用了TLAB的话，这一项工作也可以提前至TLAB分配时顺便进行。这步操作保证了对象的实例字段 在Java代码中可以不赋初始值就直接使用，使程序能访问到这些字段的数据类型所对应的零值。 接下来，Java虚拟机还要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到 类的元数据信息、对象的哈希码（实际上对象的哈希码会延后到真正调用Object::hashCode()方法时才 计算）、对象的GC分代年龄等信息。这些信息存放在对象的对象头（Object Header）之中。根据虚拟 机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。关于对象头的具体内 容，稍后会详细介绍。 在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了。但是从Java程序的视 角看来，对象创建才刚刚开始——构造函数，即Class文件中的()方法还没有执行，所有的字段都 为默认的零值，对象需要的其他资源和状态信息也还没有按照预定的意图构造好。一般来说（由字节 码流中new指令后面是否跟随invokespecial指令所决定，Java编译器会在遇到new关键字的地方同时生成 这两条字节码指令，但如果直接通过其他方式产生的则不一定如此），new指令之后会接着执行 ()方法，按照程序员的意愿对对象进行初始化，这样一个真正可用的对象才算完全被构造出来。 下面代码清单2-1是HotSpot虚拟机字节码解释器（bytecodeInterpreter.cpp）中的代码片段。这个 解释器实现很少有机会实际使用，大部分平台上都使用模板解释器；

对象的内存布局

在HotSpot虚拟机里，对象在堆内存中的存储布局可以划分为三个部分：对象头（Header）、实例 数据（Instance Data）和对齐填充（Padding）。 HotSpot虚拟机对象的对象头部分包括两类信息。第一类是用于存储对象自身的运行时数据，如哈 希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等，这部 分数据的长度在32位和64位的虚拟机（未开启压缩指针）中分别为32个比特和64个比特，官方称它 为“Mark Word”。对象需要存储的运行时数据很多，其实已经超出了32、64位Bitmap结构所能记录的 最大限度，但对象头里的信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效 率，Mark Word被设计成一个有着动态定义的数据结构，以便在极小的空间内存储尽量多的数据，根 据对象的状态复用自己的存储空间。例如在32位的HotSpot虚拟机中，如对象未被同步锁锁定的状态 下，Mark Word的32个比特存储空间中的25个比特用于存储对象哈希码，4个比特用于存储对象分代年 龄，2个比特用于存储锁标志位，1个比特固定为0，在其他状态（轻量级锁定、重量级锁定、GC标 记、可偏向）[1]下对象的存储内容如表2-1所示。

表2-1 HotSpot虚拟机对象头Mark Word 对象头的另外一部分是类型指针，即对象指向它的类型元数据的指针，Java虚拟机通过这个指针 来确定该对象是哪个类的实例。并不是所有的虚拟机实现都必须在对象数据上保留类型指针，换句话 说，查找对象的元数据信息并不一定要经过对象本身，这点我们会在下一节具体讨论。此外，如果对 象是一个Java数组，那在对象头中还必须有一块用于记录数组长度的数据，因为虚拟机可以通过普通 Java对象的元数据信息确定Java对象的大小，但是如果数组的长度是不确定的，将无法通过元数据中的 信息推断出数组的大小。
​

​

对象的访问定位

创建对象自然是为了后续使用该对象，我们的Java程序会通过栈上的reference数据来操作堆上的具 体对象。由于reference类型在《Java虚拟机规范》里面只规定了它是一个指向对象的引用，并没有定义 这个引用应该通过什么方式去定位、访问到堆中对象的具体位置，所以对象访问方式也是由虚拟机实 现而定的，主流的访问方式主要有使用句柄和直接指针两种： ·如果使用句柄访问的话，Java堆中将可能会划分出一块内存来作为句柄池，reference中存储的就 是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自具体的地址信息，其结构如图2-2所 示。 ·如果使用直接指针访问的话，Java堆中对象的内存布局就必须考虑如何放置访问类型数据的相关 信息，reference中存储的直接就是对象地址，如果只是访问对象本身的话，就不需要多一次间接访问 的开销，如图2-3所示。 这两种对象访问方式各有优势，使用句柄来访问的最大好处就是reference中存储的是稳定句柄地 址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而 reference本身不需要被修改。 图2-2 通过句柄访问对象 图2-3 通过直接指针访问对象 使用直接指针来访问最大的好处就是速度更快，它节省了一次指针定位的时间开销，由于对象访 问在Java中非常频繁，因此这类开销积少成多也是一项极为可观的执行成本，就本书讨论的主要虚拟 机HotSpot而言，它主要使用第二种方式进行对象访问（有例外情况，如果使用了Shenandoah收集器的 话也会有一次额外的转发，具体可参见第3章）

计算一个对象的大小

在HotSpot虚拟机中，Java对象的存储格式也是一个协议或者数据结构，底层是用C++代码定义的。Java对象结构大致如下图所示——

即，Java对象从整体上可以分为三个部分，对象头、实例数据和对齐填充
​

   对象头：Instance Header，Java对象最复杂的一部分，采用C++定义了头的协议格式，存储了Java对象hash、GC年龄、锁标记、class指针、数组长度等信息，稍后做出详细解说。

​

   实例数据：Instance Data，这部分数据才是真正具有业务意义的数据，实际上就是当前对象中的实例字段。在VM中，对象的字段是由基本数据类型和引用类型组成的。其所占用空间的大小如下所示：

​

 	类型	大小(字节)	类型	大小(字节)
 	byte	1	int	4
 	boolean	1	float	4
 	char	2	long	8
 	short	2	double	8
 	ref	4(32bit)   OR   8(64bit)  OR  4(64bit && -XX:UseCompressedOops)
      说明：其中ref表示引用类型，引用类型实际上是一个地址指针**，32bit机器上，占用4字节，64bit机器上，在jdk1.6之后，如果开启了指针压缩(默认开启: -XX:UseCompressedOops，仅支持64位机器)，则占用4字节。**Java对象的所有字段类型都可映射为上述类型之一，因此实例数据部分的大小，实际上就是这些字段类型的大小之和。当然，实际情况可能比这个稍微复杂一点，如字段排序、内部padding以及父类字段大小的计算等。

​

     对齐填充：Padding，VM要求对象大小须是8的整体数，该部分是为了让整体对象在内存中的地址空间大小达到8的整数倍而额外占用的字节数。

 其中OopDesc是对象实例的基类(Java实例在VM中表现为instanceOopDesc)，Klass是类信息的基类(Java类在VM中表现为instanceKlass)，klassKlass则是对Klass本身的描述(Java类的class对象在VM中表现为klassKlass)。

​

   有了对上述结构的认识，对应到内存中的存储区域，那么对象是怎么存储的，就了比较清楚的认识：对象实例(instanceOopDesc)保存在堆上，对象的元数据(instanceKlass)保存在方法区，对象的引用则保存在栈上。

​

因此，关于本小节，对OOP-Klass Model的讨论，可以用一句简洁明了的话来总结其意义：一个Java类在被VM加载时，JVM会为其在方法区创建一个instanceKlass，来表示该类的class信息。当我们在代码中基于此类用new创建一个新对象时，实际上JVM会去堆上创建一个instanceOopDesc对象，该对象保含对象头markWord和klass指针，klass指针指向方法区中的instanceKlass,markWord则保存一些锁、GC等相关的运行时数据。而在堆上创建的这个instanceOopDesc所对应的地址会被用来创建一个引用，赋给当前线程运行时栈上的一个变量。

经过上面的了解，可以得出对象大小 对象大小=对象头+成员变量大小+padding

1. 普通对象 64位平台下，原生对象头大小为16字节，压缩后为12字节，再加上成员变量的大小，并补齐8字节的padding

​

2. 成员变量大小

   byte	1	int	4
   boolean	1	float	4
   char	2	long	8
   short	2	double	8
   ref	4(32bit)   OR   8(64bit) （压缩后变为4字节）
   

​

对象数组类型:64位平台下，数组类型本身大小为24字节，压缩后16字节
​

​

指针压缩

1. 什么是java对象的指针压缩？

1.jdk1.6 update14开始，在64bit操作系统中，JVM支持指针压缩
​

2.jvm配置参数:UseCompressedOops，compressed–压缩、oop–对象指针
​

3.启用指针压缩:-XX:+UseCompressedOops，禁止指针压缩:-XX:-UseCompressedOops
​

2. 为什么要进行指针压缩？

​

我们知道32位机器，如果要按照一个字节寻址，那么指针就需要32位也就是4个字节
那么如果是64位机器，一个指针就需要8个字节，那么指针上就会占用更多的内存
1.在64位平台的HotSpot中使用32位指针，内存使用会多出1.5倍左右，使用较大指针在主内存和缓存之间移动数据，占用较大宽带，同时GC也会承受较大压力
​

2.为了减少64位平台下内存的消耗，启用指针压缩功能
​

3.在jvm中，32位地址表示4G个对象的指针，在4G-32G堆内存范围内，可以通过编码、解码方式进行优化，使得jvm可以支持更大的内存配置
​

4.堆内存小于4G时，不需要启用指针压缩，jvm会直接去除高32位地址，即使用低虚拟地址空间
​

5.堆内存大于32G时，压缩指针会失效，会强制使用64位(即8字节)来对java对象寻址，这就会出现1的问题，所以堆内存不要大于32G为好

指针压缩的原理是什么？

jvm对堆内存划分满足8n，在32Gb一下的内存下，寻址内存相当于变为了4Gb以下，也就是32位，因此，4个字节的指针完全够用。

​

3. 哪些信息会被压缩？

​

1.对象的全局静态变量(即类属性)
​

2.对象头信息:64位平台下，原生对象头大小为16字节，压缩后为12字节
​

3.对象的引用类型:64位平台下，引用类型本身大小为8字节，压缩后为4字节
​

4.对象数组类型:64位平台下，数组类型本身大小为24字节，压缩后16字节
数组比常规对象多一个长度大小，64下位多8字节，因此未24，压缩后变为4，比普通对象压缩后多4字节


“从Java7开始,当maximum heap size小于32G的时候,压缩指针是默认开启的。但是当maximum heap size大于32G的时候,压缩指针就会关闭

markWord与锁

mark word是对象头中较为神秘的一部分
​

因为对象头信息只是对象运行时自身的一部分数据，相比实例数据部分，头部分属于与业务无关的额外存储成功。为了提高对象对堆空间的复用效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。
​

    对于上述源码，mark word中字段枚举意义解释如下：

hash： 保存对象的哈希码
age： 保存对象的分代年龄
biased_lock： 偏向锁标识位
lock： 锁状态标识位
JavaThread*： 保存持有偏向锁的线程ID
epoch： 保存偏向时间戳

   锁标记枚举的意义解释如下：

locked_value             = 0,//00 轻量级锁
unlocked_value           = 1,//01 无锁
monitor_value            = 2,//10 监视器锁，也叫膨胀锁，也叫重量级锁
marked_value             = 3,//11 GC标记
biased_lock_pattern      = 5 //101 偏向锁

   实际上，markword的设计非常像网络协议报文头：将mark word划分为多个比特位区间，并在不同的对象状态下赋予不同的含义, 下图是来自网络上的一张协议图。

    对象的hash码，hash代表的并不一定是对象的（虚拟）内存地址，但依赖于内存地址，具体取决于运行时库和JVM的具体实现，底层由C++实现，实现细节参考OpenJDK源码。但可以简单的理解为对象的内存地址的整型值。

​

age
对象分代GC的年龄。分代GC的年龄是指Java对象在分代垃圾回收模型下(现在JVM实现基本都使用的这种模型)，对象上标记的分代年龄，当该年轻代内存区域空间满后，或者到达GC最达年龄时，会被扔进老年代等待老年代区域满后被FullGC收集掉，这里的最大年龄是通过JVM参数设定的：-XX:MaxTenuringThreshold ，默认值是15
​

​

1. 无锁：对象头记录hashCode（25）,分代年龄（4）+是否偏向(1) +锁标志位(2)，25+4+1+2 刚好32位
2. 当对象只有一个线程加锁时，采用偏向锁，即记录线程id，此过程无实际加锁同步操作，markword此时记录加锁的线程id，此时hashCode不再记录在markWord
3. 当存在竞争时，升级为乐观锁， 只记录锁记录指针(30位)，线程采用自旋cas修改指针，如果失败就不断重试，占据锁,适合竞争少的情况
4. 乐观锁不断尝试过程中失败次数多时，说明竞争激烈，不再适用乐观锁，升级位悲观，重锁。同样30位记录重锁指针

那么问题来了，在锁升级的过程中，hashCode,年龄等信息markWork已经存不下了
原来 当对象加锁后，计算的结果31位不够表示，在偏向锁情况下计算hashCode，那么偏向锁无法将会直接碰撞重量级锁hashcode等信息会被转移到Monitor中。轻量锁的hashCode，gc信息会存放到线程栈中的LockRecord中，量级锁hashcode等信息会被转移到Monitor中，
看到这里可能会发现一个问题:
当对象进入偏向状态的时候，Mark Word大部分的空间（23个比特）都用于存储持有锁的线程ID了，这部分空间占用了原有存储对 象哈希码的位置，那原来对象的哈希码怎么办呢?
在Java语言里面一个对象如果计算过哈希码，就应该一直保持该值不变(强烈推荐但不强制，因为用户可以重载hashCode(）方法按自己的意愿返回哈希码)，否则很多依赖对象哈希码的API都可能存在出错风险。而作为绝大多数对象哈希码来源的Object::hashCode(）方法，返回的是对象的一致性哈希码（Identity> Hash> Code)，这个值是能强制保证不变的，它通过在对象头中存储计算结果来保证第一次计算之后，再次调用该方法取到的哈希码值永远不会再发生改变。因此，当一个对象已经计算过一致性哈希码后，它就再也无法进入偏向锁状态了;而当一个对象当前正处于偏向锁状态，又收到需要计算其一致性哈希码请求时，它的偏向状态会被立即撤销，并且锁会膨胀为重量级锁。在重量级锁的实现中，对象头指向了重量级锁的位置，代表重量级锁的ObiectMonitor类里有字段可以记录非加锁状态（标志位为“01”）下的Mark
Word，其中自然可以存储原来的哈希码。
偏向锁可以提高带有同步但无竞争的程序性能，但它同样是一个带有效益权衡（TradeOff）性质的优化，也就是说它并非总是对程序运行有利。如果程序中大多数的锁都总是被多个不同的线程访问，那偏向模式就是多余的。在具体问题具体分析的前提下，有时候使用参数-XX:-UseBiasedLocking来禁止偏向锁优化反而可以提升性能"。

文章中引用了阿里云云栖号（如何计算Java对象所占内存的大小）