据说看完这篇 JVM 要一小时（二）

初始化

初始化是类加载过程的最后一个步骤，在之前的阶段中，都是由 Java 虚拟机占主导作用，但是到了这一步，却把主动权移交给应用程序。

对于初始化阶段，《Java 虚拟机规范》严格规定了只有下面这六种情况下才会触发类的初始化。

• 在遇到 new、getstatic、putstatic 或者 invokestatic 这四条字节码指令时，如果没有进行过初始化，那么首先触发初始化。通过这四个字节码的名称可以判断，这四条字节码其实就两个场景，调用 new 关键字的时候进行初始化、读取或者设置一个静态字段的时候、调用静态方法的时候。
• 在初始化类的时候，如果父类还没有初始化，那么就需要先对父类进行初始化。
• 在使用 java.lang.reflect 包的方法进行反射调用的时候。
• 当虚拟机启动时，用户需要指定执行主类的时候，说白了就是虚拟机会先初始化 main 方法这个类。
• 在使用 JDK 7 新加入的动态语言支持时，如果一个 jafva.lang.invoke.MethodHandle 实例最后的解析结果为 REF_getstatic、REF_putstatic、REF_invokeStatic、REF_newInvokeSpecial 四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，需要先对其进行初始化。
• 当一个接口中定义了 JDK 8 新加入的默认方法（被 default 关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

其实上面只有前四个大家需要知道就好了，后面两个比较冷门。

如果说要回答类加载的话，其实聊到这里已经可以了，但是为了完整性，我们索性把后面两个过程也来聊一聊。

使用

这个阶段没什么可说的，就是初始化之后的代码由 JVM 来动态调用执行。

卸载

当代表一个类的 Class 对象不再被引用，那么 Class 对象的生命周期就结束了，对应的在方法区中的数据也会被卸载。

⚠️但是需要注意一点：JVM 自带的类加载器装载的类，是不会卸载的，由用户自定义的类加载器加载的类是可以卸载的。

在 JVM 中，对象是如何创建的？

如果要回答对象是怎么创建的，我们一般想到的回答是直接 new 出来就行了，这个回答不仅局限于编程中，也融入在我们生活中的方方面面。

但是遇到面试的时候你只回答一个"new 出来就行了"显然是不行的，因为面试更趋向于让你解释当程序执行到 new 这条指令时，它的背后发生了什么。

所以你需要从 JVM 的角度来解释这件事情。

当虚拟机遇到一个 new 指令时（其实就是字节码），首先会去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用所代表的类是否已经被加载、解析和初始化。

因为此时很可能不知道具体的类是什么，所以这里使用的是符号引用。

如果发现这个类没有经过上面类加载的过程，那么就执行相应的类加载过程。

类检查完成后，接下来虚拟机将会为新生对象分配内存，对象所需的大小在类加载完成后便可确定（我会在下面的面试题中介绍）。

分配内存相当于是把一块固定的内存块从堆中划分出来。划分出来之后，虚拟机会将分配到的内存空间都初始化为零值，如果使用了 TLAB（本地线程分配缓冲），这一项初始化工作可以提前在 TLAB 分配时进行。这一步操作保证了对象实例字段在 Java 代码中可以不赋值就能直接使用。

接下来，Java 虚拟机还会对对象进行必要的设置，比如确定对象是哪个类的实例、对象的 hashcode、对象的 gc 分代年龄信息。这些信息存放在对象的对象头（Object Header）中。

如果上面的工作都做完后，从虚拟机的角度来说，一个新的对象就创建完毕了；但是对于程序员来说，对象创建才刚刚开始，因为构造函数，即 Class 文件中的 <init>() 方法还没有执行，所有字段都为默认的零值。new 指令之后才会执行 <init>() 方法，然后按照程序员的意愿对对象进行初始化，这样一个对象才可能被完整的构造出来。

内存分配方式有哪些呢？

在类加载完成后，虚拟机需要为新生对象分配内存，为对象分配内存相当于是把一块确定的区域从堆中划分出来，这就涉及到一个问题，要划分的堆区是否规整。

假设 Java 堆中内存是规整的，所有使用过的内存放在一边，未使用的内存放在一边，中间放着一个指针，这个指针为分界指示器。那么为新对象分配内存空间就相当于是把指针向空闲的空间挪动对象大小相等的距离，这种内存分配方式叫做指针碰撞(Bump The Pointer)。

如果 Java 堆中的内存并不是规整的，已经被使用的内存和未被使用的内存相互交错在一起，这种情况下就没有办法使用指针碰撞，这里就要使用另外一种记录内存使用的方式：空闲列表(Free List)，空闲列表维护了一个列表，这个列表记录了哪些内存块是可用的，在分配的时候从列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录。

所以，上述两种分配方式选择哪个，取决于 Java 堆是否规整来决定。在一些垃圾收集器的实现中，Serial、ParNew 等带压缩整理过程的收集器，使用的是指针碰撞；而使用 CMS 这种基于清除算法的收集器时，使用的是空闲列表，具体的垃圾收集器我们后面会聊到。

请你说一下对象的内存布局？

在 hotspot 虚拟机中，对象在内存中的布局分为三块区域：

• 对象头(Header)
• 实例数据(Instance Data)
• 对齐填充(Padding)

这三块区域的内存分布如下图所示

我们来详细介绍一下上面对象中的内容。

对象头 Header

对象头 Header 主要包含 MarkWord 和对象指针 Klass Pointer，如果是数组的话，还要包含数组的长度。

在 32 位的虚拟机中 MarkWord ，Klass Pointer 和数组长度分别占用 32 位，也就是 4 字节。

如果是 64 位虚拟机的话，MarkWord ，Klass Pointer 和数组长度分别占用 64 位，也就是 8 字节。

在 32 位虚拟机和 64 位虚拟机的 Mark Word 所占用的字节大小不一样，32 位虚拟机的 Mark Word 和 Klass Pointer 分别占用 32 bits 的字节，而 64 位虚拟机的 Mark Word 和 Klass Pointer 占用了64 bits 的字节，下面我们以 32 位虚拟机为例，来看一下其 Mark Word 的字节具体是如何分配的。

用中文翻译过来就是

• 无状态也就是无锁的时候，对象头开辟 25 bit 的空间用来存储对象的 hashcode ，4 bit 用于存放分代年龄，1 bit 用来存放是否偏向锁的标识位，2 bit 用来存放锁标识位为 01。
• 偏向锁 中划分更细，还是开辟 25 bit 的空间，其中 23 bit 用来存放线程ID，2bit 用来存放 epoch，4bit 存放分代年龄，1 bit 存放是否偏向锁标识， 0 表示无锁，1 表示偏向锁，锁的标识位还是 01。
• 轻量级锁中直接开辟 30 bit 的空间存放指向栈中锁记录的指针，2bit 存放锁的标志位，其标志位为 00。
• 重量级锁中和轻量级锁一样，30 bit 的空间用来存放指向重量级锁的指针，2 bit 存放锁的标识位，为 11
• GC标记开辟 30 bit 的内存空间却没有占用，2 bit 空间存放锁标志位为 11。

其中无锁和偏向锁的锁标志位都是 01，只是在前面的 1 bit 区分了这是无锁状态还是偏向锁状态。

关于为什么这么分配的内存，我们可以从 OpenJDK 中的markOop.hpp类中的枚举窥出端倪

来解释一下

• age_bits 就是我们说的分代回收的标识，占用4字节
• lock_bits 是锁的标志位，占用2个字节
• biased_lock_bits 是是否偏向锁的标识，占用1个字节。
• max_hash_bits 是针对无锁计算的 hashcode 占用字节数量，如果是 32 位虚拟机，就是 32 - 4 - 2 -1 = 25 byte，如果是 64 位虚拟机，64 - 4 - 2 - 1 = 57 byte，但是会有 25 字节未使用，所以 64 位的 hashcode 占用 31 byte。
• hash_bits 是针对 64 位虚拟机来说，如果最大字节数大于 31，则取 31，否则取真实的字节数
• cms_bits 我觉得应该是不是 64 位虚拟机就占用 0 byte，是 64 位就占用 1byte
• epoch_bits 就是 epoch 所占用的字节大小，2 字节。

在上面的虚拟机对象头分配表中，我们可以看到有几种锁的状态：无锁（无状态），偏向锁，轻量级锁，重量级锁，其中轻量级锁和偏向锁是 JDK1.6 中对 synchronized 锁进行优化后新增加的，其目的就是为了大大优化锁的性能，所以在 JDK 1.6 中，使用 synchronized 的开销也没那么大了。其实从锁有无锁定来讲，还是只有无锁和重量级锁，偏向锁和轻量级锁的出现就是增加了锁的获取性能而已，并没有出现新的锁。

所以我们的重点放在对 synchronized 重量级锁的研究上，当 monitor 被某个线程持有后，它就会处于锁定状态。在 HotSpot 虚拟机中，monitor 的底层代码是由 ObjectMonitor 实现的，其主要数据结构如下（位于 HotSpot 虚拟机源码 ObjectMonitor.hpp 文件，C++ 实现的）

这段 C++ 中需要注意几个属性：_WaitSet 、 _EntryList 和 _Owner，每个等待获取锁的线程都会被封装称为 ObjectWaiter 对象。

_Owner 是指向了 ObjectMonitor 对象的线程，而 _WaitSet 和 _EntryList 就是用来保存每个线程的列表。

那么这两个列表有什么区别呢？这个问题我和你聊一下锁的获取流程你就清楚了。

锁的两个列表

当多个线程同时访问某段同步代码时，首先会进入 _EntryList 集合，当线程获取到对象的 monitor 之后，就会进入 _Owner 区域，并把 ObjectMonitor 对象的 _Owner 指向为当前线程，并使 _count + 1，如果调用了释放锁（比如 wait）的操作，就会释放当前持有的 monitor ，owner = null， _count - 1，同时这个线程会进入到 _WaitSet 列表中等待被唤醒。如果当前线程执行完毕后也会释放 monitor 锁，只不过此时不会进入 _WaitSet 列表了，而是直接复位 _count 的值。

Klass Pointer 表示的是类型指针，也就是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

你可能不是很理解指针是个什么概念，你可以简单理解为指针就是指向某个数据的地址。

实例数据 Instance Data

实例数据部分是对象真正存储的有效信息，也是代码中定义的各个字段的字节大小，比如一个 byte 占 1 个字节，一个 int 占用 4 个字节。

对齐 Padding

对齐不是必须存在的，它只起到了占位符(%d, %c 等)的作用。这就是 JVM 的要求了，因为 HotSpot JVM 要求对象的起始地址必须是 8 字节的整数倍，也就是说对象的字节大小是 8 的整数倍，不够的需要使用 Padding 补全。