当前位置：首页 > article >正文

java-JVM面试问题-2024

article 2024/10/26 19:31:58

1、简单介绍下虚拟机内存模型？

VM由三部分组成：类加载子系统、运行时数据区、执行引擎

类加载子系统：通过类加载机制加载类的class文件，如果该类是第一次加载，会执行加载、验证、解析。只负责class文件的加载，至于是否可运行，则由执行引擎决定。

类加载过程是在类加载子系统完成的：加载 --> 链接（验证 --> 准备 --> 解析） --> 初始化

运行时数据区：

在程序运行时，存储程序的内容（例如字节码、对象、参数、返回值等）。运行时数据区包括本地方法栈、虚拟机栈、方法区、堆、程序计数器。

只有方法区和堆是各线程共享的进程内存区域，其他运行区都是每个线程可以独立拥有的。

本地方法栈：存放本地方法调用过程中的栈帧。用于管理本地方法的调用，本地方法是C语言写的。不是所有虚拟机都支持本地方法栈，例如Hotspot虚拟机就是将本地方法栈和虚拟机栈合二为一。栈解决程序的运行问题，即程序如何执行、如何处理数据。

栈帧：栈帧是栈的元素，由三部分组成，即局部变量表（存方法参数和局部变量）、操作数栈（存方法执行过程中的中间结果，或者其他暂存数据）和帧数据区（存方法返回地址、线程引用等附加信息）。

虚拟机栈：存放Java方法调用过程中的栈帧。用于管理Java方法的调用，Java方法是开发时写的Java方法。

方法区：可以看作是一块独立于Java堆的内存空间，方法区是各线程共享的内存区域。

方法区和永久代、元空间的关系：方法区是一个抽象概念，永久代和元空间是方法区的实现方式。

永久代：属于JVM方法区的内存，用来存储类的元数据，如类名、方法信息、字段信息等一些静态的数据。JDK7及之前方法区也叫永久代。缺点是内存大小固定，容易出现oom问题。可以通过-XX:PermSize设置永久代大小。永久代对象只能通过Major GC（又称Full GC）进行垃圾回收。

元空间：是Hotspot在JDK8引入的，用于取代永久代。元空间属于本地内存，由操作系统直接管理，不再受JVM管理。同时内存空间可以自动扩容，避免内存溢出。默认情况下元空间可以无限使用本地内存，也可以通过-XX:MetaspaceSize限制内存大小。

常量池：就是一张表，JVM根据这张常量表找到要执行的类信息和方法信息

类常量池：是.class字节码文件中的资源仓库，主要存放字面量（表示字符串值和数值，例如字符串值"abc"、final常量、静态变量）和符号引用（类和接口的全限定名、字段名、方法名）。

运行时常量池：类加载的“加载”阶段会创建运行时常量池，统一存放各个类常量池去重后的符号引用。在类加载的“解析”阶段JVM会把运行时常量池的这些符号引用转为直接引用。类常量池。类常量池在字节码文件中的，运行时常量池在内存中。

字符串常量池：专门针对String类型设计的常量池。是当前应用程序里所有线程共享的，每个jvm只有一个字符串常量池。存储字符串对象的引用。在创建String对象时，JVM会先在字符串常量池寻找是否已存在相同字符串的引用，如果有的话就直接返回引用，没的话就在堆中创建一个对象，然后常量池保存这个引用并返回引用。

堆：存放对象实例、实例变量、数组，包括新生代（伊甸园区、幸存区S0和S1）和老年代。堆是垃圾收集器管理的内存区域。堆解决的是数据存储的问题，即数据怎么放、放在哪儿。堆实际内存空间可以不连续，大小可以选择固定大小或可扩展，堆是各线程共享的内存区域。

程序计数器（PC寄存器）：存放下一条字节码指令的地址，由执行引擎读取下一条字节码指令并转为本地机器指令进行执行。是程序控制流（分支、循环、跳转、线程恢复）的指示器，只有它不会抛出OutOfMemoryError。每个线程有自己独立的程序计数器，以便于线程在切换回来时能知道下一条指令是什么。程序计数器生命周期与线程一致。

执行引擎：将字节码指令解释/编译为对应平台上的本地机器指令。充当了将高级语言翻译为机器语言的译者。执行引擎在执行过程中需要执行什么样的字节码指令依赖于PC寄存器。每当执行完一项指令操作后，PC寄存器就会更新下一条需要被执行的指令地址。

字节码指令（JVM指令）：字节码文件中的指令，内部只包含一些能够被JVM所识别的字节码指令、符号表，以及其他辅助信息，不能够直接运行在操作系统之上。

本地机器指令：可以直接运行在操作系统之上。

2、默认Java虚拟机HotSpot

HotSpot是Sun/OracleJDK和OpenJDK中的默认Java虚拟机，也是目前使用范围最广的Java虚拟机。HotSpot既继承了Sun之前两款商用虚拟机的优点，也有许多自己新的技术优势，如它名称中的HotSpot指的就是它的热点代码探测技术。HotSpot的热点代码探测能力可以通过执行计数器找出最具有编译价值的代码，然后通知即时编译器以方法为单位进行编译。如果一个方法被频繁调用，或方法中有效循环次数很多，将会分别触发标准即时编译和栈上替换编译行为。通过编译器与解释器恰当地协同工作，可以在最优化的程序响应时间与最佳执行性能中取得平衡，而且无须等待本地代码输出才能执行程序，即时编译的时间压力也相对减小，这样有助于引入更复杂的代码优化技术，输出质量更高的本地代码。本地方法栈和Java方法栈是合并的。

3、说说类加载机制

类加载过程：加载、链接（验证、准备、解析）、初始化。这个过程是在类加载子系统完成的。

加载：生成类的Class对象。

通过类的全限定名获取该类的二进制字节流

类的全限定名：即"包名.类名"，例如Object类的全限定名是java.lang.Object 。包名的各个部分之间，包名和类名之间，使用点号分割。

类的二进制字节流：即类的字节码文件，是一组以8个字节(64位)为基础单位的二进制流，各个单位内部及之间都排列紧凑，中间没有添加任何分隔符和空隙，这使得整个Class文件中存储的内容几乎都是程序运行的必要数据。当遇到需要占用8个字节以上空间的数据项时，则会按照高位在前的方式分割成若干个8个字节进行存储，保证每个基础单位只有8个字节。

将这个字节流的静态存储结构，转化为方法区的运行时数据结构。包括创建运行时常量池，将类常量池的部分符号引用放入运行时常量池。

静态存储结构：二进制文件，存储内容，存储内容包括魔数、版本号、常量池、访问标识、类索引、字段表、方发表、属性表

运行时数据结构：存储在内存中的JVM内存模型中的运行时数据区-方法区，存储内容是类常量池、运行时常量池、字符串常量池，存储形式是永久代（JDK7及之前）和元空间（JDK8及之后）。

在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类各种数据的访问入口。注意类的class对象是运行时生成的、存在内存中的对象，类的class字节码文件是编译时生成的、存在磁盘中的文件。

链接：将类的二进制数据合并到JRE中。该过程分为以下3个阶段：

验证：确保代码符合JAVA虚拟机规范和安全约束。包括文件格式验证、元数据验证、字节码验证、符号引用验证。

文件格式验证：验证字节码文件是否符合规范。

魔数：是否魔数0xCAFEBABE开头

版本号：版本号是否在JVM兼容范围

常量类型：类常量池里常量类型是否合法

索引值：索引值是否指向不存在或不符合类型的常量。

元数据验证：元数据是字节码里类的全名、方法信息、字段信息、继承关系等。

标识符：验证类名接口名标识符有没有符合规范

接口实现方法：有没有实现接口的所有方法

抽象类实现方法：有没有实现抽象类的所有抽象方法

final类：是不是继承了final类。

指令验证：主要校验类的方法体，通过数据流和控制流分析，保证方法在运行时不会危害虚拟机安全。

类型转换：保证方法体中的类型转换是否有效。例如把某个类强转成没继承关系的类

跳转指令：保证跳转指令不会跳转到方法体以外的字节码指令上；

保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作。

符号引用验证：确保后面解析阶段能正常执行。

类全限定名地址：验证类全限定名是否能找到对应的类字节码文件

引用地址：引用指向地址是否存在实例

引用权限：是否有权引用

准备：为类变量（即static变量）分配内存并赋零值。

解析：将方法区-运行时常量池内的符号引用（类的名字、成员名、标识符）转为直接引用（实际内存地址，不包含任何抽象信息，因此可以直接使用）。

初始化：类变量赋初值、执行静态语句块。

4、简述一个类的过程

一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历加载、验证、准备、解析、初始化、使用、卸载七个阶段，其中验证、准备、解析三个部分统称为连接，而前五个阶段则是类加载的完整过程。

1. 在加载阶段JVM需要在内存中生成一个代表这个类的Class对象，作为方法区这个类的各种数据的访问入口。

2. 验证阶段大致上会完成下面四个阶段的检验动作：文件格式验证、元数据验证、字节码验证、符号引用验证。

3. 准备阶段是正式为类中定义变量（静态变量）分配到内存并设置类变量初始值的阶段，这些变量所使用的内存都应当在方法区中进行分配，但必须注意到方法区本身是一个逻辑上的区域。

4. 解析阶段是Java虚拟机将常量池内的符号替换为直接引用的过程，符号引用以一组符号来描述所引用的目标，直接引用是可以直接指向目标的指针、相对偏移量或者一个能间接定位到目标的句柄。

5. 类的初始化阶段是类加载过程的最后一个步骤，直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。本质上，初始化阶段就是执行类构造器的过程。并不是程序员在Java代码中直接编写的方法，它是Javac编译器的自动生成物。

5、什么情况需要对类立即进行初始化

1. 使用new实例化对象、读写类的静态字段、调用类的静态方法时。

2. 使用java.lang.reflect包的方法对类型进行反射调用时。

3. 当初始化类时，若发现其父类还没有进行过初始化，则先初始化这个父类。

4. 虚拟机启动时，需要指定一个要执行的主类，虚拟机会先初始化这个主类。

5. 当使用JDK 7新加入的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四种类型的方法句柄，并且这个方法句柄对应的类没有进行过初始化，则需要先触发其初始化。

6. 当一个接口中定义了JDK 8新加入的默认方法（被default关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

6、对象的实例化过程

判断对应类是否加载过：首先JVM检查在方法区Metaspace（元空间）的常量池里能否定位到该类的符号引用，能的话通过符号引用检查该类是否加载链接初始化过；若没有则在双亲委派机制下，当前类加载器调用findClass()方法查找类的.class字节码文件，然后调用loadClass("类全限定名")方法遵循双亲委派机制加载链接初始化类到内存中，并生成类的class对象，作为方法区这个类各种数据的访问入口。

创建对象：

分配堆内存空间：如果内存规整：（例如标记整理算法），采用指针碰撞法为新对象分配内存。如果内存不规整：（有内存碎片，例如标记清除算法），在空闲列表里找到合适大小的空闲内存分配给新对象。现在主流虚拟机新生代都是使用标记复制算法，内存都是规整的。

处理并发安全问题：CAS失败重试，区域加锁，每个线程分配一块TLAB内存缓冲区。

设置对象头：将哈希码、GC分代年龄、锁信息、GC标记等存在对象头的Mark Word中；

成员变量赋初值：若指定了初值则赋指定的值。若未指定初值，则基本类型赋0或false、引用类型赋null。

执行构造方法：有父类的话，子类构造方法第一行会隐式或手动显式地加super()。

7、指针碰撞法

指针一直在空闲和已用内存中间，分配空间时，指针往空闲内存方向移动一段距离，使这段距离刚好满足新对象内存大小。如果垃圾收集器选择的是Serial、ParNew这种基于压缩算法的，虚拟机采用这种分配方式。一般使用带有compact( 整理)过程的收集器时，使用指针碰撞。

8、synchronized用到的对象头

synchronized锁基于对象头的Mark Word，锁升级四个状态里，偏向锁和轻量级锁基于CAS原子替换，重量级锁基于Monitor对象。对象头里Mark Word存哈希码、GC标记、锁信息。对象头里类型指针指向当前对象所在的类。

锁信息：

锁标志位：01未锁定、01可偏向、00轻量级锁、10重量级锁、11垃圾回收标记

偏向锁线程ID、时间戳等

轻量级锁的指针：指向锁记录的指针

重量级锁的指针：指向Monitor锁的指针

9、简单说下对象在JVM中的创建过程

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

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定，为对象分配空间的任务实际上便等同于把一块确定大小的内存块从Java堆中划分出来。

内存分配完成之后，虚拟机必须将分配到的内存空间都初始化为零值，如果使用了TLAB的话，这一项工作也可以提前至TLAB分配时顺便进行。这步操作保证了对象的实例字段在Java代码中可以不赋初始值就直接使用，使程序能访问到这些字段的数据类型所对应的零值。

接下来，虚拟机还要对对象进行必要的设置，例如这个对象是哪个类的实例、如何才能找到类的元数据信息、对象的哈希码、对象的GC分代年龄等信息。这些信息存放在对象的对象头之中。根据虚拟机当前运行状态的不同，如是否启用偏向锁等，对象头会有不同的设置方式。

在上面工作都完成之后，从虚拟机的视角来看，一个新的对象已经产生了。但是从Java程序的视角看来，对象创建才刚刚开始——构造函数，即Class文件中的`<init>()`方法还没有执行，所有的字段都为默认的零值，对象需要的其他资源和状态信息也还没有按照预定的意图构造好。

一般来说，new指令之后会接着执行`<init>()`方法，按照程序员的意愿对对象进行初始化，这样一个真正可用的对象才算完全被构造出来。

10、JVM的双亲委派模型

双亲委派模型：当一个类加载器接收到加载类的请求时，它首先会将这个请求委派给其父类加载器处理，只有在父类加载器无法完成加载任务时，才会由该类加载器自己去加载类。

JVM三个默认类加载器：

启动类加载器BootStrapClassLoader（最顶端）：

加载内容：负责加载java的核心类库，包括java.lang包中的类等。底层使用C++实现（不会继承ClassLoader），是虚拟机自身的一部分。

不能被直接引用：因为是C++实现的，所以无法被Java程序直接引用，只能加载委派过来的请求。这些类库存放在 JAVA_HOME\lib（具体解释看下文）目录下，或者被 -Xbootclasspath 参数指定的路径中。（启动类加载器主要加载java的核心类库，即加载lib目录下的所有class）

扩展类加载器ExtClassLoader：

加载内容：负责加载JAVA_HOME\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有类库。

可以被直接引用：它可以直接用来加载类，也可以通过委派加载类。Ext是Extract缩写，译为扩展、提取。

应用程序类加载器AppClassLoader（最低端）：

加载内容：负责加载类路径的所有类库，在大多数情况下，我们编写的 Java 程序都是由这个类加载器加载的。

可以被直接引用：可以直接在代码中使用这个类加载器。

11、双亲委派的工作过程

工作过程：

检查父类加载器是否已经加载过这个类：JVM 会首先询问父类加载器是否已经加载了该类。如果已经加载过了，直接返回该类的 Class 对象。如果没加载过，则：

委派给父类加载器加载：如果父类加载器没有加载过该类，那么 JVM 将委托给父类加载器进行加载。每一层都是这样继续委派，直到达到最顶层的启动类加载器。

尝试加载类：如果父类加载器无法加载该类（即所有的父类加载器都无法加载），那么 JVM 将尝试使用自己的类加载器来加载类。

实际流程：

JVM在加载一个类时，会调用应用程序类加载器的loadClass()方法来加载这个类，不过在这方法中，会先使用扩展类加载器的loadClass()方法来加载类，同样扩展类加载器的loadClass()方法中会先使用启动类加载器来加载类；

如果启动类加载器加载到了就直接成功，如果启动类加载器没有加载到，那扩展类加载器就会自己尝试加载该类，如果没有加载到，那么则会由应用程序类加载器来加载这个类。

双亲委派模型的作用：

避免类的重复加载：无论哪一个类加载器要加载某类，最终都是委派最顶端的启动类加载器。

防止核心API被篡改：如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为java.lang.Object的类，并放在程序的ClassPath中，那系统中就会出现多个不同的Object类，Java类型体系中最基础的行为也就无从保证，应用程序将会变得一片混乱。

12、双亲委派模型的3次被破坏

双亲委派模型并不是一个具有强制性约束的模型，而是Java设计者推荐给开发者们的类加载器实现方式。在Java的世界中大部分的类加载器都遵循这个模型，但也有例外的情况，双亲委派模型主要出现过3次较大规模的“被破坏”的情况。

1.双亲委派模型的第一次“被破坏”发生在双亲委派模型出现之前

双亲委派模型在JDK1.2之后才被引入，但是类加载器的概念和抽象类ClassLoader则在Java的第一个版本中就已经存在，面对已经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一些妥协。为了兼容这些已有代码，只能在之后的ClassLoader中添加一个protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码。双亲委派的具体逻辑就实现在这里面，按照loadClass()的逻辑，如果父类加载失败，会自动调用自己的findClass()来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器符合双亲委派规则。

2.双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的

双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题，基础类型之所以被称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户的代码，那该怎么办呢？

一个典型的例子便是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载，肯定属于Java中很基础的类型了。但JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口的代码，现在问题来了，启动类加载器是绝不可能认识、加载这些代码的，那该怎么办？

为了解决这个困境，Java的设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

有了线程上下文类加载器，程序就可以做一些“舞弊”的事情了。JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则，但也是无可奈何的事情。

3.双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的

这里所说的“动态性”指的是一些非常“热”门的名词：代码热替换、模块热部署等。说白了就是希望Java应用程序能像我们的电脑外设那样，接上鼠标、U盘，不用重启机器就能立即使用，鼠标有问题或要升级就换个鼠标，不用关机也不用重启。

早在2008年，在Java社区关于模块化规范的第一场战役里，由Sun/Oracle公司所提出的JSR-294、JSR-277规范提案就曾败给以IBM公司主导的JSR-291（即OSGi R4.2）提案。尽管Sun/Oracle并不甘心就此失去Java模块化的主导权，随即又再拿出Jigsaw项目迎战，但此时OSGi已经站稳脚跟，成为业界“事实上”的Java模块化标准。

OSGi实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块（OSGi中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构。</java_home></java_home>

13、JVM调优

JVM调优三步骤：

监控发现问题

工具分析问题

性能调优

监控发现问题：看服务器有没有以下情况，有的话需要调优：

GC频繁

CPU负载过高

OOM

内存泄露

死锁

程序响应时间较长

工具分析问题：使用分析工具定位oom、内存泄漏等问题

调优依据：吞吐量提高的代价是停顿时间拉长。如果应用程序跟用户基本不交互，就优先提升吞吐量。如果应用程序和用户频繁交互，就优先缩短停顿时间。

GC日志：使用GCViewer、VisualVM、GCeasy等日志分析工具打印GC日志；

JDK自带的命令行调优工具：

jps：查看正在运行的 Java 进程。jps -v查看进程启动时的JVM参数；

jstat：查看指定进程的 JVM 统计信息。jstat -gc查看堆各分区大小、YGC,FGC次数和时长。如果服务器没有 GUI 图形界面，只提供了纯文本控制台环境，它是运行期定位虚拟机性能问题的首选工具。

jinfo：实时查看和修改指定进程的 JVM 配置参数。jinfo -flag查看和修改具体参数。

jstack：打印指定进程此刻的线程快照。定位线程长时间停顿的原因，例如死锁、等待资源、阻塞。如果有死锁会打印线程的互相占用资源情况。

线程快照：该进程内每条线程正在执行的方法堆栈的集合。

JDK自带的可视化监控工具：例如jconsole、Visual VM。Visual VM可以监视应用程序的 CPU、GC、堆、方法区、线程快照，查看JVM进程、JVM 参数、系统属性。

MAT：解析Heap Dump（堆转储）文件dump.hprof，查看GC Roots、引用链、对象信息、类信息、线程信息。可以快速生成内存泄漏报表。

14、性能调优

排查大对象和内存泄漏：使用MAT分析堆转储日志中的大对象，看是否合理。大对象会直接进入老年代，导致Full GC频繁。具体排查步骤看下面OOM。

调整JVM参数：主要关注停顿时间和吞吐量，两者不可兼得，提高吞吐量会拉长停顿时间。

减少停顿时间：垃圾收集器做垃圾回收中断应用执行的时间。可以通过-XX:MaxGCPauseMillis参数进行设置，以毫秒为单位，至少大于1

提高吞吐量：吞吐量=运行时长/(运行时长+GC时长)。通过-XX:GCTimeRatio=n参数进行设置，99的话代表吞吐量为99%，一般吞吐量不能低于95%。吞吐量太高会拉长停顿时间，造成用户体验下降。

调整堆内存大小：根据程序运行时老年代存活对象大小（记为x）进行调整，整个堆内存大小设置为X的3~4倍。年轻代占堆内存的3/8。

-Xms：初始堆内存大小。默认：物理内存小于192MB时，默认为物理内存的1/2；物理内存大192MB且小于128GB时，默认为物理内存的1/4；物理内存大于等于128GB时，都为32GB。

-Xmx：最大堆内存大小，建议保持和初始堆内存大小一样。因为从初始堆到最大堆的过程会有一定的性能开销，而且现在内存不是稀缺资源。

-Xmn：年轻代大小。JDK官方建议年轻代占整个堆大小空间的3/8左右。

调整堆内存比例：调整伊甸园区和幸存区比例、新生代和老年代比例。Young GC频繁时，我们提高新生代比例和伊甸园区比例。默认情况，伊甸园区:S0:S1=8:1:1，新生代:老年代=1:2。

调整升老年代年龄：JDK8时Young GC默认把15岁的对象移动到老年代。JDK9默认值改为7。当Full GC频繁时，我们提高升老年龄，让年轻代的对象多在年轻代待一会，从而降低Full GC频率。JDK8默认Young GC时将15岁的对象移动到老年代。

调整大对象阈值：Young GC时大对象会不顾年龄直接移动到老年代。当Full GC频繁时，我们关闭或提高大对象阈值，让老年代更迟填满。默认是0，即大对象不会直接在YGC时移到老年代。

调整GC的触发条件：

CMS调整老年代触发回收比例：CMS的并发标记和并发清除阶段是用户线程和回收线程并发执行，如果老年代满了再回收会导致用户线程被强制暂停。所以我们修改回收条件为老年代的60%，保证回收时预留足够空间放新对象。CMS默认是老年代68%时触发回收机制。

G1调整存活阈值：超过存活阈值的Region，其内对象会被混合回收到老年代。G1回收时也要预留空间给新对象。存活阈值默认85%，即当一个内存区块中存活对象所占比例超过 85% 时，这些对象就会通过 Mixed GC 内存整理并晋升至老年代内存区域。

选择合适的垃圾回收器：最有效的方式是升级，根据CPU核数，升级当前版本支持的最新回收器。

CPU单核，那么毫无疑问Serial 垃圾收集器是你唯一的选择。

CPU多核，关注吞吐量，那么选择Parallel Scavenge+Parallel Old组合（JDK8默认）。

CPU多核，关注用户停顿时间，JDK版本1.6或者1.7，那么选择ParNew+CMS，吞吐量降低但是低停顿。

CPU多核，关注用户停顿时间，JDK1.8及以上，JVM可用内存6G以上，那么选择G1。

优化业务代码：绝大部分问题都出自代码。要尽量减少非必要对象的创建，防止死循环创建对象，防止内存泄漏，有些情景下需要以时间换空间，控制内存使用

增加机器：增加机器，分散节点压力

调整线程池参数：合理设置线程池线程数量

缓存、MQ等中间件优化：使用中间件提高程序效率，比如缓存、消息队列等

15、实际的JVM调优经验

1:CPU飙升

原因：CPU利用率过高，大量线程并发执行任务导致CPU飙升。例如锁等待（例如CAS不断自旋）、多线程都陷入死循环、Redis被攻击、网站被攻击、文件IO、网络IO。

定位步骤：

定位进程ID：通过top命令查看当前服务CPU使用最高的进程，获取到对应的pid（进程ID）

定位线程ID：使用top -Hp pid，显示指定进程下面的线程信息，找到消耗CPU最高的线程id

线程ID转十六进制：转十六进制是因为下一步jstack打印的线程快照（线程正在执行方法的堆栈集合）里线程id是十六进制。

定位代码：使用jstack pid | grep tid（十六进制），打印线程快照，找到线程执行的代码。一般如果有死锁的话就会显示线程互相占用情况。

解决问题：优化代码、增加系统资源（增多服务器、增大内存）。

2:GC调优

最差情况下能接受的GC频率：Young GC频率10s一次，每次500ms以内。Full GC频率10min一次，每次1s以内。

其实一小时一次Full GC已经算频繁了，一个不错的应用起码得控制一天一次Full GC。

监控发现问题：上午8点是我们的业务高峰，一到高峰的时候，用户感觉到明显卡顿，监控工具（例如Prometheus和Grafana）发现TP99（99%请求在多少ms内完成）时长明显变高，有明显的的毛刺；内存使用率也不稳定，会周期性增大再降低，于是怀疑是GC导致。

命令行分析问题：通过jstat -gc观察服务器的GC情况，发现Young GC频率提高成原来的10倍，Full GC频率提高成原来的四倍。正常YGC 10min一次，FGC 10h一次。异常YGC 1min一次，FGC 3h一次；

所以主要问题是Young GC频繁，进而导致Full GC频繁。Full GC频繁会触发STW，导致TP99耗时上升。

解决方案：

排查内存泄漏、大对象、BUG；

增大堆内存：服务器加8G内存条，同时提高初始堆内存、最大堆内存。-Xms、-Xmx。

提高新生代比例：新生代和老年代默认比例是1:2。-XX:NewRatio=由4改为默认的2

降低升老年龄：让存活对象更快进入老年代。-XX:InitialTenuringThreshold=15（JDK8默认）改成7（JDK9默认）

设置大对象阈值：让大于1M的大对象直接进入老年代。-XX:PretenureSizeThreshold=0（默认）改为1000000（单位是字节）

垃圾回收器升级为G1：因为是JDK8，所以直接由默认的Parallel Scavenge+Parallel Old组合，升级为低延时的G1回收器。如果是JDK7版本，不支持G1，可以修改成ParNew+CMS或Parallel Scavenge+CMS，以降低吞吐量为代价降低停顿时间。-XX:CMSInitiatingOccupancyFraction

降低G1的存活阈值：超过存活阈值的Region，其内对象会被混合回收到老年代。降低存活阈值，更早进入老年代。-XX:G1MixedGCLiveThresholdPercent=90设为默认的85

调优效果：调优后我们重新进行了一次压测，发现TP99耗时较之前降低60%。FullGC耗时降低80%，YoungGC次数减少30%。TP99耗时基本持平，完全符台预期。

16、内存溢出

内存溢出：申请的内存大于系统能提供的内存。

溢出原因：

本地直接内存溢出：本地直接内存设的太小导致溢出。设置直接内存最大值-XX：MaxDirectMemorySize，若不指定则默认与Java堆最大值一致。

虚拟机栈和本地方法栈溢出：如果虚拟机的栈内存允许动态扩展，并且方法递归层数太深时，导致扩展栈容量时无法申请到足够内存。

方法区溢出：运行时生成大量动态类时会内存溢出。

CGlib动态代理：CGlib动态代理产生大量类填满了整个方法区（方法区存常量池、类信息、方法信息），直到溢出。CGlib动态代理是在内存中构建子类对象实现对目标对象功能扩展，如果enhancer.setUseCache(false);，即关闭用户缓存，那么每次创建代理对象都是一个新的实例，创建过多就会导致方法区溢出。注意JDK动态代理不会导致方法区溢出。

JSP：大量JSP或动态产生JSP文件的应用（JSP第一次运行时需要编译为Java类）。

堆溢出：

死循环创建过多对象；

集合类中有对对象的引用，使用完后未清空，使得JVM不能回收；

内存中加载的数据量过于庞大，如一次从数据库取出的数据集太大、第三方接口接口传输的大对象、接收的MQ消息太大；

Tomcat参数设置不当导致OOM：Tomcat会给每个线程创建两个默认4M大小的缓冲区，高并发情况下会导致缓冲区创建过多，导致OOM。

程序计数器不会内存溢出。

17、内存泄漏

内存泄漏：不再使用的对象仍然被引用，导致GC无法回收；

内存泄露的9种情况：

静态容器里的对象：静态集合类的生命周期与 JVM 程序一致，容器里的对象引用也将一直被引用得不到GC；Java里不准静态方法引用非静态方法也是防止内存泄漏。

单例对象引用的外部对象：单例模式里，如果单例对象如果持有外部对象的引用，因为单例对象不会被回收，那么这个外部对象也不会被回收

外部类跟随内部类被引用：内部类持有外部类，这个内部类对象被长期引用了，即使那个外部类实例对象不再被使用，但由于内部类持有外部类的实例对象，这个外部类对象将不会被垃圾回收，这也会造成内存泄漏。

数据库、网络、IO等连接忘记关闭：在对数据库进行操作的过程中，首先需要建立与数据库的连接，当不再使用时，需要调用 close 方法来释放与数据库的连接。如果对 Connection、Statement 或 ResultSet 不显性地关闭，将会造成大量的对象无法被回收，从而引起内存泄漏。

变量作用域不合理：例如一个变量只会在某个方法中使用，却声明为成员变量，并且被使用后没有被赋值为null，将会导致这个变量明明已经没用了，生命周期却还跟对象一致。

HashSet中对象改变哈希值：当一个对象被存储进 HashSet 集合中以后，就不能修改这个对象中的那些参与计算哈希值的字段了。否则对象哈希值改变，找不到对应的value。

缓存引用忘删除：一旦你把对象引用放入到缓存中，他就很容易遗忘，缓存忘了删除，将导致引用一直存在。

逻辑删除而不是真实删除：监听器和其他回调：如果客户端在你实现的 API 中注册回调，却没有显示的取消，那么就会积聚。需要确保回调立即被当作垃圾回收的最佳方法是只保存它的弱引用，例如将他们保存成为软WeakHashMap 中的键。例如出栈只是移动了指针，而没有将出栈的位置赋值null，导致已出栈的位置还存在引用。

线程池时，ThreadLocal忘记remove()：使用线程池的时候，ThreadLocal 需要在使用完线程中的线程变量手动 remove()，否则会内存泄漏。因为线程执行完后没有销毁而是被线程池回收，导致ThreadLocal中的对象不能被自动垃圾回收。

性能分析工具判断是否有内存泄漏：

JDK自带的命令行调优工具：

每隔一段较长的时间通过jstat命令采样多组 OU（老年代内存量）的最小值；

如果这些最小值在上涨，说明无法回收对象在不断增加，可能是内存泄漏导致的。

MAT监视诊断内存泄漏：

生成堆转储文件：MAT直接从Java进程导出dump文件

可疑点：查看泄漏怀疑（Leak Suspects），找到内存泄漏可疑点

可疑线程：可疑点查看详情（Details），找到可疑线程

定位代码：查看线程调用栈（See stacktrace），找到问题代码的具体位置。

GC详细日志：启动参数开启GC详细日志，设置日志地址；-XX:+PrintGCDetails；

编译器警告：查看Eclipse等编译器的内存泄漏警告；

Java基准测试工具：分析代码性能；

解决办法：

牢记内存泄漏的场景，当一个对象不会被使用时，给它的所有引用赋值null，堤防静态容器，记得关闭连接、别用逻辑删除，只要用到了引用，变量的作用域要合理。

使用java.lang.ref包的弱引用WeakReference，下次垃圾收集器工作时被回收。

检查代码；

18、JVM中一次完整的GC流程是怎样的

首先，任何新对象都分配到 eden 空间。两个幸存者空间开始时都是空的。

当 eden 空间填满时，将触发一个Minor GC(年轻代的垃圾回收，也称为Young GC)，删除所有未引用的对象，大对象（需要大量连续内存空间的Java对象，如那种很长的字符串）直接进入老年代。

所有被引用的对象作为存活对象，将移动到第一个幸存者空间S0，并标记年龄为1，即经历过一次Minor GC。之后每经过一次Minor GC，年龄+1。GC分代年龄存储在对象头的Mark Word里。

当 eden 空间再次被填满时，会执行第二次Minor GC，将Eden和S0区中所有垃圾对象清除，并将存活对象复制到S1并年龄加1，此时S0变为空。

如此反复在S0和S1之间切换几次之后，还存活的年龄等于15的对象（JDK8默认15，JDK9默认7，-XX:InitialTenuringThreshold=7）在下一次Minor GC时将放到老年代中。

当老年代满了时会触发Major GC（也称为Full GC），Major GC 清理整个堆 – 包括年轻代和老年代。

19、GC的可达性分析算法

可达性分析算法：

以根对象集合(GC Roots)的每个跟对象为起始点，根据引用关系向下搜索，将所有与GC Roots直接或间接有引用关系的对象在对象头的Mark Word里标记为可达对象，即不需要回收的有引用关系对象。搜索过程所走过的路径称为“引用链” 。

GC Roots：即GC根节点集合，是一组必须活跃的引用。可作为GC Roots的对象：

栈引用的对象：Java方法栈、本地方法栈中的参数引用、局部变量引用、临时变量引用等。临时变量是方法里的中间操作结果。

方法区中常量、静态变量引用的对象；

所有被同步锁持有的对象；

所有线程对象；

所有跨代引用对象；

JVM内部的引用：如基本数据类型对应的Class对象，常驻的异常对象，以及应用程序类类加载器；

非可达对象被回收需要两次标记：

第一次标记后筛选非可达对象：第一次被标记后，会进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法，也就是是否有机会自救。假如对象没有覆盖或者已被JVM调用过finalize()方法，也就是说不想自救或已自救过，那么此对象需要被回收；假如对象覆盖并没被JVM调用过finalize()方法，该对象将会被放置在一个名为F-Queue的队列之中，并在稍后由一条由虚拟机自动建立的、低调度优先级的Finalizer线程去执行它们的finalize()方法。

第二次标记F-Queue里的未自救对象：稍后，收集器将对F-Queue中的对象进行第二次小规模的标记。如果对象要在finalize()中成功拯救自己——只要重新与引用链上的任何一个对象建立关联即可，譬如把自己（this）赋值给某个引用类型的类变量或者对象的成员变量，那在第二次标记时它将被移出“即将回收”的F-Queue。如果对象这时候还没有逃脱，那基本上它就真的要被回收了。

20、finalize()方法

finalize()方法是对象逃脱死亡命运的最后一次机会，需要注意的是，任何一个对象的finalize()方法都只会被系统自动调用一次，如果对象面临下一次回收，它的finalize()方法不会被再次执行。

另外，finalize()方法的运行代价高昂，不确定性大，无法保证各个对象的调用顺序，如今已被官方明确声明为不推荐使用的语法。

21、JVM的垃圾回收算法

标记清除算法（Mark-Sweep）：

标记、清除：当堆中有效内存空间被耗尽时，会STW（stop the world，暂停其他所有工作线程），然后先标记，再清除。

标记：可达性分析法，从GC Roots开始遍历，找到可达对象，并在对象头中进行标记。

清除：堆内存内从头到尾进行线性遍历，“清除”非可达对象。注意清除并不是真的置空，垃圾还在原来的位置。实际是把垃圾对象的地址维护在空闲列表，对象实例化的申请内存阶段会通过空闲列表找到合适大小的空闲内存分配给新对象。

优点：简单

缺点：

效率不高：需要可达性遍历和线性遍历，效率差。

STW导致用户体验差：GC时需要暂停其他所有工作线程，用户体验差。

有内存碎片，要维护空闲列表：回收垃圾对象后没有整理，导致堆中出现一块块不连续的内存碎片。

适用场景：适合小型应用程序，内存空间不大的情况。应用程序越大越不适用这种回收算法。

标记复制算法(Copying) ：

标记、复制、清除：将内存空间分为两块，每次只使用一块。在进行垃圾回收时，先可达性分析法标记可达对象，然后将可达对象复制到没有被使用的那个内存块中，最后再清除当前内存块中的所有对象。后续再按同样的流程来回复制和清除。

优点：

垃圾多时效率高：只需可达性遍历，效率很高。

无内存碎片：因为有移动操作，所以内存规整。

缺点：

内存利用率低，浪费内存：始终有一半以上的空闲内存。

需要调整引用地址：可达对象移动后，内存地址发生了变化，需要调整所有引用，指向移动后的地址。

垃圾少时效率相对差，但还是比其他算法强：如果可达对象比较多，垃圾对象比较少，那么复制算法的效率就会比较低。只为了一点垃圾而移动所有对象未免有些小题大做。所以垃圾对象多的情况下，复制算法比较适合。

适用场景：适合垃圾对象多，可达对象少的情况，这样复制耗时短。非常适合新生代的垃圾回收，因为新生代要频繁地把可达对象从伊甸园区移动到幸存区，而且是新生代满了适合再Minor GC，垃圾对象占比高，所以回收性价比非常高，一次通常可以回收70-90%的内存空间，现在的商业虚拟机都是用这种GC算法回收新生代。

标记整理算法(Mark-Compact) ：

标记、整理、清除：首先可达性分析法标记可达对象，然后将可达对象按顺序整理到内存的一端，最后清理边界外的垃圾对象。相当于内存碎片优化版的标记清楚算法，不用维护空闲列表。

优点：

无内存碎片：内存规整。

内存利用率最高：内存既规整又不用浪费一般空间。

缺点：

效率最低：效率比其他两种算法都低

需要调整引用地址：可达对象移动后，内存地址发生了变化，需要调整所有引用，指向移动后的地址。

STW导致用户体验差：移动时需要暂停其他所有工作线程，用户体验差。

分代收集算法：将堆分为新生代、老年代不同生命周期的对象放在不同的代，采用不同的收集算法，以提高回收效率。

22、垃圾回收器

Serial、Serial Old、PawNew、CMS、Parallel Scavenge、Parallel Old、G1

各版本默认回收器：JDK8默认回收器是Parallel+Parallel Old。

各区域对应算法：

新生代回收算法：标记复制算法；

老年代回收算法：标记清除/整理算法

整堆回收算法：分区算法。

Serial（串行收集器）：

介绍：单线程、单处理器回收新生代，回收时会STW。

STW：Stop The World，暂停其他所有工作线程直到收集结束。

算法：标记复制算法

回收区域：新生代

优点：简单、比其他单线程收集器效率高：单线程，不用线程切换，可以专心进行垃圾回收。

应用场景：适用于内存小的桌面应用，可以在较短时间完成收集。Serial GC是最基础、历史最悠久的收集器，曾是HotSpot虚拟机新生代收集器的唯一选择。

命令：指定新生代用Serial GC，老年代用Serial Old GC：-XX:+UseSerialGC

Serial Old（老年代串行收集器）：

介绍：Serial收集器的老年代版本。单线程、单处理器回收老年代，回收时会STW。

算法：标记-整理算法

ParNew（并行新生代收集器）：Par是Parallel（并行，平行）的缩写，New:只能处理的是新生代

介绍：Serial收集器的多线程并行版本。多线程并行回收新生代，回收时会STW。

算法：标记复制算法

回收区域：新生代

优点：多CPU场景下性能高，吞吐量大

缺点：单CPU场景下性能差，不如串行收集器

应用场景：多CPU场景下。

Parallel Scavenge（并行收集器）：

介绍：可控制高吞吐量，多线程并行回收新生代，回收时会STW。比ParNew优秀，可以动态调整内存分配情况。

算法：标记复制算法

回收区域：新生代

应用场景：后台运算量大而不需要太多交互的任务。JDK8默认回收器是Parallel+Parallel Old

Parallel Old（老年代并行收集器）：

介绍：Parallel Scavenge收集器的老年代版本。可控制高吞吐量，多线程并行回收老生代，回收时会STW。

算法：标记整理算法

回收区域：老年代

CMS（并发标记清除收集器）：

介绍：以最短停顿时间为目标，JDK1.5推出，第一次实现了垃圾收集线程和用户线程同时工作。多线程并行回收老生代，低stw。初始标记和重新标记需要stw，但耗时很短。

算法：标记清除算法。不使用标记整理算法是为了保证清除时不影响用户线程中的工作线程，如果使用标记整理算法的话工作线程引用指向的对象地址就都变了。

回收区域：老年代

步骤：

初始标记：标记GC Roots直接关联的对象。单线程且停顿用户线程，速度很快。

并发标记：从直接关联对象并发遍历整个图，标记可达对象。并发不停顿。

重新标记：修正上一步用户线程变动的标记。并发停顿。速度远比并发标记阶段快。注意只能修正原有对象不能修正新增对象，即只能修正原有对象非可达变可达、可达变非可达。

并发清除：并发线性遍历并清理未被标记的对象。并发不停顿。

优点：

并发速度快；

低停顿：用户线程和垃圾回收器同时执行，仅初始标记和重新标记阶段需要停顿，这两个阶段运行速度很快。

缺点：

并发占线程

有内存碎片：内存不规整，需要维护空闲列表。

无法处理浮动垃圾：并发标记阶段会产生新对象，重新标记阶段又只能修正不能新增，所以会出现浮动垃圾。

回收时要确保用户线程有足够内存：不能等老年代满了再回收，而是内存到达某个阈值后回收，防止用户线程在并发执行过程中新创建对象导致内存不够，导致虚拟机补偿使用Serial Old收集器进行回收并处理内存碎片，从而浪费更多时间。CMS默认是老年代68%时触发回收机制。-XX:CMSInitiatingOccupancyFraction

应用场景：因为底层是标记清除算法，所以有内存碎片，适合小应用。

G1（Garbage-First，垃圾优先收集器）：

介绍：以延迟可控并保证高吞吐量为目标，为了适应内存大小和处理器数量不断扩大而在JDK7推出的垃圾回收器。开创了收集器面向局部收集的设计思路和基于Region（区域）的内存布局形式。JDK8支持并发类卸载后被Oracle官方称为“全功能的垃圾收集器”。并行低停顿，除了并发标记外需要stw，但耗时很短（初始标记和最终标记是真短，筛选回收是有指定STW）。

实现机制：不再把堆划分为连续的分代，而是将堆内存分割成2048个大小相等的Region，各Region根据需要扮演伊甸园区、幸存区、老年代区、巨大区。垃圾优先收集器跟踪各Region里垃圾的回收价值（回收空间大小和预计回收时长），在后台维护一个优先级列表，每次根据用户设定允许的收集停顿时间，回收优先级最高的那些Region，以达到垃圾优先的效果。

设置最大停顿时间：-XX:MaxGCPauseMillis=默认0.2s

Humongous Region（巨大区）：存储大小超过Region一半空间的大对象，如果大对象的内存大小超过了Region大小，将会被存在几个连续的巨大区里。G1的大多数行为把巨大区看作老年代的一部分。

算法：分区收集算法（整体是标记整理算法、Region之间标记复制算法）

回收区域：整堆。整堆里哪个Region垃圾最多，回收收益最大。

步骤：

初始标记：标记GC Roots直接关联的可达对象。单线程且停顿用户线程，速度很快。

并发标记：从直接关联对象并发遍历整个图，标记可达对象。并发不停顿。

最终标记：重新标记所有存活的对象和上个阶段用户线程新产生的可达对象。并发停顿。采用SATB算法，效率比CMS重新标记高。并发停顿。

筛选回收：根据优先级列表，回收价值高的一些Region，将存活对象通过标记复制算法复制到同类型的空闲Region。根据指定的最大停顿时间回收，因此可能来不及回收所有垃圾对象，但能保证回收到最高回收价值的垃圾。并发停顿。

记忆集：是一个抽象概念。每个Region都维护一个记忆集Rset，用来记录其他Region对象对本Region对象的引用。本Region在回收后对象地址会改变，用记忆集就能直接知道直接找到对应引用修改指向的地址，从而不用全局扫描。

卡表（CardTable）：是记忆集的一种实现方式。卡表是一个字节数组，每个元素对应一个内存块，每个内存块大小都是2^n字节（Hotspot是2^9=512字节）。

写屏障：当前对象被其他Region对象通过引用关系赋值时，赋值前后会插入写前屏障和写后屏障中断当前Region垃圾回收。