面试官：JVM三种核心内容有？并从实战角度解析！

01 前言

这章节主要从实战角度方面，去解读JVM。

问：JVM三种核心内容有哪一些？

答：类加载机制+JVM调优实战+代码优化

02 类加载机制

Java源代码经过编译器编译成字节码之后，最终都需要加载到虚拟机之后才能运行。虚拟机把描述类的数据从 Class 文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java 类型，这就是虚拟机的类加载机制。

2.1 类加载时机

一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）七个阶段，其中验证、准备、解析三个部分统称为连接（Linking）。这七个阶段的发生顺序下图所示。

上图中，加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类型的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定特性（也称为动态绑定或晚期绑定）。

关于在什么情况下需要开始类加载过程的第一个阶段“加载”，《Java虚拟机规范》中并没有进行强制约束，这点可以交给虚拟机的具体实现来自由把握。

但是对于初始化阶段，《Java虚拟机规范》则是严格规定了有且只有六种情况必须立即对类进行“初始化”（而加 载、验证、准备自然需要在此之前开始）：

• 遇到new、getstatic、putstatic 或invokestatic 这4 条字节码指令；
• 使用java.lang.reflect 包的方法对类进行反射调用的时候；
• 当初始化一个类的时候，发现其父类还没有进行初始化的时候，需要先触发其父类的初始化；
• 当虚拟机启动时，用户需要指定一个要执行的主类，虚拟机会先初始化这个类；
• 当使用JDK 1.7 的动态语言支持时，如果一个java.lang.invoke.MethodHandle 实例最后的解析结果
• REF_getStatic、REF_putStatic、REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有初始化。
• 当一个接口中定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现。类发生了初始化，那该接口要在其之前被初始化。

对于这六种会触发类型进行初始化的场景，《Java虚拟机规范》中使用了一个非常强烈的限定语——“有且只有”，这六种场景中的行为称为对一个类型进行主动引用。除此之外，所有引用类型的方式都不会触发初始化，称为被动引用。

比如如下几种场景就是被动引用：

• 通过子类引用父类的静态字段，不会导致子类的初始化；
• 通过数组定义来引用类，不会触发此类的初始化；
• 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化；

2.2 类加载过程

加载

在加载阶段，Java虚拟机需要完成以下三件事情：

通过一个类的全限定名来获取定义此类的二进制字节流。

将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

在内存中生成一个代表这个类的java.lang. Class对象，作为方法区这个类的各种数据的访问入口。

验证

验证是连接阶段的第一步，这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。

验证阶段大致上会完成下面4 个阶段的检验动作：

• 文件格式验证 第一阶段要验证字节流是否符合Class 文件格式的规范，并且能够被当前版本的虚拟机处理。验证点主要包括：是否以魔数0xCAFEBABE 开头；主、次版本号是否在当前虚拟机处理范围之内；常量池的常量中是否有不被支持的常量类型；Class 文件中各个部分及文件本身是否有被删除的或者附加的其它信息等等。
• 元数据验证 第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java 语言规范的要求，这个阶段的验证点包括：这个类是否有父类；这个类的父类是否继承了不允许被继承的类；如果这个类不是抽象类，是否实现了其父类或者接口之中要求实现的所有方法；类中的字段、方法是否与父类产生矛盾等等。
• 字节码验证 第三阶段是整个验证过程中最复杂的一个阶段，主要目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
• 符号引用验证 最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段--解析阶段中发生。符号引用验证可以看做是对类自身以外（常量池中的各种符号引用）的各类信息进行匹配性校验，通俗来说就是，该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段。

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。

初始化

类初始化阶段是类加载过程中的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全是由虚拟机主导和控制的。

到了初始化阶段，才真正开始执行类中定义的Java 程序代码。

2.3 类加载器

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远超类加载阶段。

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。

这句话可以表达得更通俗一些：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

双亲委派模型

从Java 虚拟机的角度来讲，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++ 来实现，是虚拟机自身的一部分；另一种就是所有其他的类加载器，这些类加载器都由Java 来实现，独立于虚拟机外部，并且全都继承自抽象类 java.lang.ClassLoader 。

从Java 开发者的角度来看，类加载器可以划分为:

• 启动类加载器（Bootstrap ClassLoader）：这个类加载器负责将存放在<java_home>\lib 目录中的类库加载到虚拟机内存中。启动类加载器无法被Java 程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给启动类加载器，那直接使用null 代替即可；
• 扩展类加载器（Extension ClassLoader）：这个类加载器由 sun.misc.Launcher$ExtClassLoader 实现，它负责加载<java_home>\lib\ext 目录中，或者被java.ext.dirs 系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器；
• 应用程序类加载器（Application ClassLoader）：这个类加载器由 sun.misc.Launcher$AppClassLoader 实现。 getSystemClassLoader() 方法返回的就是这个类加载器，因此也被称为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库。开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

我们的应用程序都是由这3 种类加载器互相配合进行加载的，在必要时还可以自己定义类加载器。它们的关系如下图所示：

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。

双亲委派模型的工作过程是：

• 如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类
• 而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此
• 因此所有的加载请求最终都应该传送到最顶层的启动类加载器中
• 只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。

这样做的好处就是Java 类随着它的类加载器一起具备了一种带有优先级的层次关系。例如java.lang. Object，它放在rt.jar 中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型顶端的启动类加载器来加载，因此Object 类在程序的各种类加载器环境中都是同一个类。

相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang. Object 的类，并放在程序的ClassPath 中，那系统中将会出现多个不同的Object 类，Java 类型体系中最基本的行为也就无法保证了。

双亲委派模型对于保证Java程序的稳定运作极为重要，但它的实现却异常简单，用以实现双亲委派的代码只有短短十余行，全部集中在java.lang. ClassLoader的loadClass()方法之中：

protected synchronized Class<?> loadClass(String name, boolean resolve)
       throws ClassNotFoundException {
   // 首先，检查请求的类是不是已经被加载过
   Class<?> c = findLoadedClass(name);
   if (c == null) {
       try {
           if (parent != null) {
               c = parent.loadClass(name, false);
           } else {
               c = findBootstrapClassOrNull(name);
           }
       } catch (ClassNotFoundException e) {
           // 如果父类抛出 ClassNotFoundException 说明父类加载器无法完成加载
       }
       if (c == null) {
           // 如果父类加载器无法加载，则调用自己的 findClass 方法来进行类加载
           c = findClass(name);
       }
   }
   if (resolve) {
       resolveClass(c);
   }
   return c;
}
1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.
复制代码

03 JVM调优实战

3.1 JVM运行参数

在jvm中有很多的参数可以进行设置，这样可以让jvm在各种环境中都能够高效的运行。绝大部分的参数保持默认即可。

三种参数类型

• 标准参数
• -help
• -version
• -X参数(非标准参数)
• -Xint
• -Xcomp
• XX参数(使用率较高)
• -XX:newSize
• -XX:+UseSerialGC

-X参数

jvm的-X参数是非标准参数，在不同版本的jvm中，参数可能会有所不同，可以通过java -X查看非标准参数。

-XX参数

-XX参数也是非标准参数，主要用于jvm的调优和debug操作。

-XX参数的使用有2种方式，一种是boolean类型，一种是非boolean类型：

• boolean类型
• 格式：-XX:[+-] 表示启用或禁用属性
• 如：-XX:+DisableExplicitGC 表示禁用手动调用gc操作，也就是说调用System.gc()无效
• 非boolean类型
• 格式：-XX:= 表示属性的值为
• 如：-XX:NewRatio=4 表示新生代和老年代的比值为1:4

-Xms和-Xmx参数

-Xms与-Xmx分别是设置jvm的堆内存的初始大小和最大大小。 -Xmx2048m：等价于-XX:MaxHeapSize，设置JVM最大堆内存为2048M。 -Xms512m：等价于-XX:InitialHeapSize，设置JVM初始堆内存为512M。 适当的调整jvm的内存大小，可以充分利用服务器资源，让程序跑得更快。 示例：

---

[root@node01 test]# java -Xms512m -Xmx2048m TestJVM
itcast
1.2.
复制代码

jstat

jstat命令可以查看堆内存各部分的使用量，以及加载类的数量。命令的格式如下： jstat [-命令选项] [vmid] [间隔时间/毫秒] [查询次数]

查看class加载统计

F:\t>jstat -class 12076
Loaded  Bytes  Unloaded  Bytes     Time
 5962 10814.2        0     0.0       3.75

1.2.3.
复制代码

说明： Loaded：加载class的数量 Bytes：所占用空间大小 Unloaded：未加载数量 Bytes：未加载占用空间 Time：时间

查看编译统计

F:\t>jstat -compiler 12076
Compiled Failed Invalid   Time   FailedType FailedMethod
   3115      0       0     3.43          0
1.2