_abab

JVM 性能调优

一、类加载机制

核心目标：理解 JVM 类加载全流程、类加载器体系及双亲委派机制。

类加载全过程
1. 加载：通过类加载器将.class 文件字节流加载为内存中的 Class 对象（如从 jar 包、网络或自定义源加载）。
2. 验证：确保字节流符合 JVM 规范（如文件格式验证、字节码验证）。
3. 准备：为类变量分配内存并设置初始值（如static int value = 123，此时 value 初始值为 0）。
4. 解析：将符号引用转为直接引用（如将类名转为内存地址）。
5. 初始化：执行类构造器()，初始化类变量和静态代码块。
类加载器体系
1. 启动类加载器（Bootstrap ClassLoader）：加载 JRE 核心类（如rt.jar中的java.lang.*），由 C++ 实现，不可被 Java 代码访问。
2. 扩展类加载器（Extension ClassLoader）：加载jre/lib/ext目录或-Djava.ext.dirs指定路径的类库。
3. 应用类加载器（Application ClassLoader）：加载应用程序类路径（ClassPath）下的类，是自定义类加载器的默认父加载器。
4. 自定义类加载器：继承ClassLoader，用于加载特定来源的类（如加密的.class 文件、动态生成的类）。
双亲委派机制
1. 工作原理：类加载时，先委托父加载器加载，直至启动类加载器；若父加载器无法加载，才由当前加载器加载。
2. 作用：确保核心类（如java.lang.Object）由启动类加载器加载，避免用户自定义类覆盖核心类，保障类型安全。
3. 打破场景：如 Tomcat 为支持多应用隔离，采用 “逆双亲委派” 机制，优先使用自定义类加载器加载应用类。

案例：手写自定义类加载器加载加密的.class 文件，通过重写findClass()方法解密字节流后生成 Class 对象。

二、JVM 内存结构

核心目标：掌握 JVM 内存分区、对象创建流程及垃圾回收机制。

运行时数据区域
1. 程序计数器：记录当前线程执行的字节码行号，是线程私有的 “指针”。
2. Java 虚拟机栈：存储栈帧（局部变量表、操作数栈、动态链接等），线程私有，生命周期与线程一致。
3. 本地方法栈：为 Native 方法服务，结构与虚拟机栈类似。
4. 堆：存储对象实例，线程共享，是垃圾回收的主要区域（分新生代、老年代，新生代含 Eden、Survivor 区）。
5. 方法区（元空间）：存储类元数据、常量、静态变量等，JDK 8 后由元空间（MetaSpace）替代永久代，使用本地内存。

对象创建与内存分配
1. 流程：
  1. 类加载检查（检查类是否已加载）→ 2. 分配内存（指针碰撞或空闲列表算法）→ 3. 初始化零值 → 4. 设置对象头（存储哈希码、GC 分代年龄等）→ 5. 执行()方法。
2. 并发安全：通过 CAS（Compare-And-Swap）保证原子性，或使用 TLAB（Thread Local Allocation Buffer）为每个线程分配专属内存块。

垃圾回收（GC）
1. 对象存活判断：
  1. 引用计数法：记录对象被引用次数，存在循环引用缺陷（如 A→B，B→A，两者均无法回收）。
  2. 可达性分析：从 GC Roots（如栈变量、类静态变量）出发，标记所有可达对象，不可达对象判定为垃圾。
2. 垃圾收集算法：
  1. 标记 - 清除：标记垃圾对象后统一清除，产生内存碎片。
  2. 复制算法：将存活对象复制到另一块区域，适合新生代（如 Eden→Survivor 区）。
  3. 标记 - 整理：标记后压缩内存，避免碎片，适合老年代。
3. 垃圾收集器：
  1. Serial：单线程收集器，STW（Stop The World）时间长，适合客户端应用。
  2. Parallel：多线程收集器，吞吐量优先（如-XX:+UseParallelGC）。
  3. CMS：并发收集器，低停顿，适合 Web 应用（如-XX:+UseConcMarkSweepGC）。
  4. G1：分代收集器，可预测停顿时间，适合大内存场景（如-XX:+UseG1GC）。

三、性能调优工具与实战

核心目标：掌握 JVM 调优工具使用及线上问题排查方法。

命令行工具
1. jps：查看 JVM 进程 ID。
2. jstat：监控 GC 状态（如jstat -gc 12345查看进程 12345 的 GC 数据）。
3. jmap：生成堆转储文件（如jmap -dump:format=b,file=heap.hprof 12345）。
4. jstack：查看线程栈信息，定位死锁或阻塞（如jstack 12345 | grep "WAITING"）。

可视化工具
1. JVisualVM：图形化监控工具，支持堆分析、线程分析、插件扩展（如安装 Visual GC 插件实时查看 GC 情况）。
2. Arthas：阿里开源诊断工具，支持实时查看变量、热更新代码、监控方法调用（如arthas --pid 12345启动后执行trace com.example.Service method追踪方法调用耗时）。

线上问题排查
1. CPU 飙高：通过top找到高 CPU 进程，top -Hp 定位线程，jstack打印线程栈，分析是否存在死循环或锁竞争。
2. 内存溢出（OOM）：配置-XX:+HeapDumpOnOutOfMemoryError生成 dump 文件，用 MAT（Memory Analyzer Tool）分析大对象或内存泄漏。
3. 频繁 GC：通过jstat -gcutil观察 GC 频率和耗时，调整堆大小（如-Xms2g -Xmx2g）或切换 GC 收集器。

四、高级主题

核心目标：深入理解 JVM 底层机制及优化策略。

字节码与类文件结构
1. Class 文件组成：魔数（0xCAFEBABE）、版本号、常量池、字段表、方法表、属性表等。
2. 常量池：存储字面量（如字符串、数字）和符号引用（如类名、方法名），分为 Class 常量池和运行时常量池。

性能调优参数
1. 堆设置：
  1. -Xms：初始堆大小，建议与-Xmx一致，避免堆自动扩展带来的性能波动。
  2. -Xmn：新生代大小，通常占堆的 1/3（如-Xmn1g）。
2. 元空间设置：-XX:MetaspaceSize=256m（JDK 8+），控制类元数据内存。
3. GC 参数：
  1. -XX:+UseG1GC：启用 G1 收集器。
  2. -XX:MaxGCPauseMillis=200：设置 GC 最大停顿时间（G1 可用）。

特殊场景优化
1. 大对象处理：通过-XX:PretenureSizeThreshold设置大对象直接进入老年代（如-XX:PretenureSizeThreshold=1048576表示 1MB 以上对象直接进入老年代）。
2. 字符串常量池优化：使用String.intern()将字符串入池，避免重复创建（如new String("abc").intern()）。

1.1 类加载运行全过程梳理

类加载是 JVM 将.class 文件转换为可执行字节码的核心流程，分为加载、验证、准备、解析、初始化五个阶段：

加载
1. 目标：通过类加载器获取类的二进制字节流（如从本地文件系统、网络、jar 包加载）。
2. 关键动作：
  1. 通过类的全限定名（如com.example.User）查找对应的.class 文件。
  2. 将字节流转换为内存中的java.lang.Class对象。
3. 示例：当执行new User()时，若User类未加载，JVM 会触发类加载器加载User.class。
验证
1. 目标：确保字节流符合 JVM 规范，防止恶意代码破坏 JVM。
2. 验证阶段：
  1. 文件格式验证：检查魔数（0xCAFEBABE）、版本号是否合法。
  2. 字节码验证：确保字节码指令合法（如操作数栈深度正确）。
  3. 符号引用验证：确保类之间的引用有效（如引用的类存在）。
准备
1. 目标：为类变量（static修饰的变量）分配内存并设置初始值。
2. 注意：
  1. 实例变量（非static）在对象创建时分配内存，此处不处理。
  2. 初始值为数据类型的默认值（如static int value = 123，准备阶段value为 0，初始化阶段才赋值 123）。
解析
1. 目标：将符号引用转为直接引用（如将类名java.lang.Object转为内存地址）。
2. 符号引用 vs 直接引用：
  1. 符号引用：一组符号（如字符串）描述引用目标，与虚拟机实现无关。
  2. 直接引用：指向目标的指针、句柄或偏移量，直接指向内存地址。
初始化
1. 目标：执行类构造器()，初始化类变量和静态代码块。
2. 触发时机：
  1. 首次使用类（如创建实例、调用静态方法）。
  2. 子类初始化前，先初始化父类（除非父类已初始化）。
3. 示例：

public class ClassLoadingDemo {

static {

System.out.println("Class is initializing...");

}

public static void main(String[] args) {

System.out.println("Main method executed.");

}

执行main方法时，触发ClassLoadingDemo类初始化，输出 “Class is initializing...”。

1.2 Java.exe 运行一个类时 JVM HotSpot 底层做了什么

当我们在命令行输入java.exe运行一个 Java 类（如java com.example.MyApp）时，JVM HotSpot 虚拟机的底层会执行一系列复杂操作，其核心流程如下：

1. 启动 JVM 进程java.exe作为 Java 虚拟机的启动程序，会首先创建一个 JVM 进程。在此过程中，HotSpot 虚拟机初始化底层环境，包括分配内存空间、加载必要的动态链接库（如libjvm.so或jvm.dll）。这些动态链接库包含了 JVM 运行的核心功能，如内存管理、字节码执行引擎等。同时，JVM 会根据启动参数（如-Xms、-Xmx）初始化堆内存大小，并设置其他关键组件（如方法区、虚拟机栈）。

2. 加载引导类加载器JVM 启动后，首先加载启动类加载器（Bootstrap ClassLoader），该加载器由 C++ 编写，负责加载 JRE 核心类库，如rt.jar中的java.lang.Object、java.util.List等。这些核心类是 Java 程序运行的基础，Bootstrap ClassLoader 将其加载到内存中，为后续类加载奠定基础。由于其由 C++ 实现，在 Java 代码层面无法直接访问和操作。

3. 触发目标类加载当 JVM 执行java com.example.MyApp时，会触发com.example.MyApp类的加载。此时，应用类加载器（Application ClassLoader）开始工作，它会按照双亲委派机制，先将加载请求委托给父加载器（扩展类加载器 Extension ClassLoader），扩展类加载器再委托给启动类加载器。由于com.example.MyApp属于应用程序自定义类，不在 JRE 核心类库中，启动类加载器和扩展类加载器均无法加载，最终由应用类加载器从 ClassPath 路径下找到对应的.class文件，并将其字节流加载为内存中的Class对象。

4. 执行类加载流程在加载com.example.MyApp类时，JVM 严格遵循加载→验证→准备→解析→初始化的流程：

加载：应用类加载器将.class文件字节流转换为Class对象；
验证：检查字节流是否符合 JVM 规范，防止恶意代码入侵；
准备：为类的静态变量分配内存并设置初始值（如static int count = 10，此时count为 0）；
解析：将符号引用（如类名、方法名）转换为直接引用（内存地址）；
初始化：执行类构造器()，初始化静态变量和静态代码块。若MyApp类有父类，会先初始化父类。

5. 创建主线程并执行类初始化完成后，JVM 创建主线程（main线程），并执行com.example.MyApp类中的main方法。在此过程中，虚拟机栈为main方法创建栈帧，用于存储局部变量、操作数栈和方法调用信息。随着main方法中代码的执行，JVM 通过字节码执行引擎解析和执行字节码指令，操作堆内存中的对象，完成程序的业务逻辑。

6. 运行时动态管理在程序运行期间，JVM 持续监控内存使用情况，通过垃圾回收机制清理不再使用的对象，释放内存空间。同时，HotSpot 虚拟机利用 ** 即时编译（JIT）** 技术，将频繁执行的字节码编译为机器码，提升程序执行效率。例如，对于循环次数较多的代码块，JIT 会将其编译为机器码，避免每次执行都进行字节码解释，从而显著提高性能。

示例场景假设我们有一个简单的 Java 程序：

public class HelloWorld {

static {

System.out.println("HelloWorld class is initializing");

}

public static void main(String[] args) {

System.out.println("Hello, World!");

}

当执行java HelloWorld时，JVM HotSpot 底层会先加载HelloWorld类，执行静态代码块输出 “HelloWorld class is initializing”，然后创建主线程执行main方法，输出 “Hello, World!”。在这个过程中，JVM 完成了从类加载到程序执行的全流程操作，并在后台持续管理内存和优化执行效率。

1.3 初识符号引用、静态链接与动态链接

在 Java 类加载的解析阶段，符号引用与链接过程是连接字节码和运行时内存地址的关键环节，理解它们对掌握 JVM 底层运作至关重要。

1. 符号引用（Symbolic References）

符号引用是一组符号来描述所引用的目标，这些符号以文本形式存在，与虚拟机实现无关，在.class文件中广泛使用。它可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。具体包括：

类和接口的全限定名：如java/util/List，用于标识类或接口的唯一性。
字段的名称和描述符：例如nameLjava/lang/String;，其中name是字段名，Ljava/lang/String;是描述符，表示该字段为String类型。
方法的名称和描述符：像toString()Ljava/lang/String;，toString是方法名，()Ljava/lang/String;描述了方法的参数和返回值类型。

示例：在如下 Java 代码编译后的.class文件中：

public class SymbolicRefDemo {

private String message;

public String getMessage() {

return message;

}

.class文件会使用符号引用记录message字段和getMessage方法，如字段message记录为messageLjava/lang/String;，方法getMessage记录为getMessage()Ljava/lang/String;。这些符号引用在类加载阶段暂时无法直接访问目标内存地址，需要通过链接过程转换。

2. 静态链接（Static Linking）

静态链接发生在类加载的解析阶段，主要任务是将符号引用转换为直接引用。直接引用是指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄，它直接指向内存中的具体位置。

核心操作：
- 查找类、字段、方法的内存地址：JVM 通过类加载器找到对应的类元数据，获取字段和方法在内存中的具体位置。
- 验证访问权限：检查当前类是否有权限访问目标字段或方法，例如检查私有方法是否被非法调用。
特点：静态链接的结果在程序运行期间不会改变，适用于不会被修改的类、字段和方法，比如java.lang.Math类中的静态方法，在类加载时完成静态链接后，后续调用直接使用已确定的内存地址。

3. 动态链接（Dynamic Linking）

动态链接与静态链接不同，它发生在程序运行期间，用于处理一些无法在编译期确定的引用。

触发场景：
- 多态调用：当使用接口或抽象类进行方法调用时（如List list = new ArrayList(); list.add("元素");），具体调用的是ArrayList的add方法还是其他List实现类的add方法，只有在运行时才能确定。
- JIT 编译：即时编译器（JIT）在运行时将频繁执行的字节码编译为机器码，编译过程中需要将符号引用转换为直接引用。
实现机制：JVM 通过运行时常量池来管理动态链接。运行时常量池存储了类加载过程中解析得到的直接引用，当遇到动态链接需求时，JVM 在运行时常量池中查找或创建对应的直接引用。

4. 两者对比与应用

特性	静态链接	动态链接
执行阶段	类加载的解析阶段	程序运行期间
适用场景	确定的类、字段、方法引用	多态调用、JIT 编译等动态场景
性能影响	类加载时开销较大，运行时效率高	类加载时开销小，运行时可能有额外查找开销

示例：在如下多态代码中：

interface Shape {

double calculateArea();

}

class Circle implements Shape {

private double radius;

public Circle(double radius) {

this.radius = radius;

}

@Override

public double calculateArea() {

return Math.PI * radius * radius;

}

class Rectangle implements Shape {

private double width;

private double height;

public Rectangle(double width, double height) {

this.width = width;

this.height = height;

}

@Override

public double calculateArea() {

return width * height;

}

public class LinkingDemo {

public static void main(String[] args) {

Shape shape1 = new Circle(5);

Shape shape2 = new Rectangle(4, 6);

System.out.println(shape1.calculateArea());

System.out.println(shape2.calculateArea());

}

shape1.calculateArea()和shape2.calculateArea()的具体调用方法在编译期无法确定，需要在运行时通过动态链接，根据对象实际类型（Circle或Rectangle）确定调用的方法地址，实现多态特性。

1.4 war 包或 jar 包是如何加载的

在 Java 应用部署中，war 包和 jar 包是常见的打包形式，它们的加载过程与 JVM 类加载器体系紧密相关。

jar 包加载
- 普通 jar 包：当 Java 程序依赖外部 jar 包时（如通过CLASSPATH环境变量或-cp参数指定），应用类加载器（Application ClassLoader）会负责加载。例如，在命令行执行java -cp myapp.jar;lib/* com.example.Main，lib目录下的所有 jar 包会被应用类加载器扫描并加载，加载时遵循双亲委派机制，优先委托父加载器尝试加载类。
- 可执行 jar 包：通过jar -cvfm命令生成的可执行 jar 包，包含META-INF/MANIFEST.MF文件指定主类（如Main-Class: com.example.Main）。执行java -jar myapp.jar时，JVM 会先解析MANIFEST.MF获取主类，再由应用类加载器加载主类及相关依赖类。
war 包加载
- Tomcat 场景：Tomcat 处理 war 包时，会创建自定义的类加载器（如WebappClassLoader）。每个 war 包对应一个独立的类加载器实例，确保不同应用的类相互隔离。Tomcat 启动时，先将 war 包解压到工作目录，WebappClassLoader从指定目录加载类文件和资源，其加载顺序优先于系统类加载器，打破了传统双亲委派机制。例如，多个 war 包中存在不同版本的commons - lang依赖，各自的类加载器可独立加载对应版本，避免冲突。
- 加载流程：WebappClassLoader首先加载WEB - INF/classes目录下的类，再加载WEB - INF/lib目录中的 jar 包。在加载过程中，若遇到类加载请求，会先尝试自行加载，若无法加载再委托给父加载器（通常是应用类加载器），实现应用隔离与依赖管理。

1.5 jvm 中类加载器分类与核心功能

JVM 中的类加载器分为以下几类，各自承担不同的加载职责：

启动类加载器（Bootstrap ClassLoader）
- 实现方式：由 C++ 编写，是 JVM 的一部分，在 JVM 启动时自动创建。
- 加载范围：负责加载 JRE 核心类库，如rt.jar、resources.jar等，存储在%JAVA_HOME%/jre/lib目录下的类。这些类是 Java 运行的基础，如java.lang.Object、java.util.List等。
- 特点：无法通过 Java 代码直接引用，在 Java 程序中表现为null。
扩展类加载器（Extension ClassLoader）
- 实现方式：由 Java 编写，继承自URLClassLoader，是启动类加载器的子类。
- 加载范围：加载%JAVA_HOME%/jre/lib/ext目录或java.ext.dirs系统属性指定路径下的类库。常用于加载第三方扩展包，如加密算法库等。
- 特点：可以通过ClassLoader.getSystemClassLoader().getParent()获取实例。
应用类加载器（Application ClassLoader）
- 实现方式：同样由 Java 编写，继承自URLClassLoader，是扩展类加载器的子类。
- 加载范围：负责加载应用程序类路径（ClassPath）下的类和 jar 包，包括命令行参数-cp指定的路径、环境变量CLASSPATH中的内容。它是自定义类加载器的默认父加载器。
- 特点：可通过ClassLoader.getSystemClassLoader()获取实例，在普通 Java 程序中，大部分自定义类由此加载器加载。
自定义类加载器
- 实现方式：继承自ClassLoader类，开发者可重写findClass、loadClass等方法，实现自定义加载逻辑。
- 核心功能：用于加载特定来源的类，如从网络下载的字节码、加密的类文件、动态生成的类等。例如，在热部署场景中，自定义类加载器可实现类的动态替换。

1.6 类加载器在 jvm 中是如何初始化的

类加载器在 JVM 中的初始化过程涉及创建实例、设置父加载器及资源路径配置：

启动类加载器初始化
- JVM 启动触发：JVM 启动时，由底层代码直接创建启动类加载器实例，它是所有类加载器的根。
- 加载核心库：启动类加载器会立即加载 JRE 核心类库，并将其存储在内存中，为后续类加载提供基础。
扩展类加载器与应用类加载器初始化
- 默认构造：在 JVM 初始化阶段，通过反射创建扩展类加载器实例。其构造函数会将启动类加载器设置为父加载器，并读取java.ext.dirs属性，确定扩展类库的加载路径。
- 链式初始化：应用类加载器在创建时，会将扩展类加载器设置为父加载器，并根据系统环境获取ClassPath路径，用于加载应用程序类和依赖包。例如，在 Linux 系统下，通过export CLASSPATH=.:/path/to/libs/*设置的路径，会在应用类加载器初始化时被读取。
自定义类加载器初始化
- 手动创建：开发者通过new关键字实例化自定义类加载器（如MyClassLoader loader = new MyClassLoader()），在构造函数中通常会指定父加载器（若不指定，默认使用应用类加载器），并配置自定义的类加载路径（如从指定文件夹或网络地址加载类）。

动态配置：在运行时，可通过修改自定义类加载器的属性，动态调整加载行为。例如，为自定义类加载器添加新的 URL 路径，使其能加载新的类文件。

1.7 面试中经常问到的类加载双亲委派机制是怎么回事

双亲委派机制是 JVM 类加载过程中的核心机制，它保障了 Java 程序的稳定性和安全性，在面试中是高频考点。

机制定义：当一个类加载器收到类加载请求时，它首先不会自己尝试加载这个类，而是把请求委托给父类加载器去完成，父类加载器又会委托它的父类加载器，如此向上递归，直到启动类加载器。只有当父类加载器无法完成加载任务时（即在它的加载范围内找不到所需的类），子类加载器才会尝试自己去加载。
工作流程示例：假设应用程序中自定义了一个类com.example.MyClass，当 JVM 需要加载这个类时，应用类加载器（Application ClassLoader）会先将加载请求委托给扩展类加载器（Extension ClassLoader），扩展类加载器再委托给启动类加载器（Bootstrap ClassLoader）。由于com.example.MyClass不属于 JRE 核心类库和扩展类库，启动类加载器和扩展类加载器都无法加载，最后由应用类加载器从应用程序类路径中加载该类。
作用与意义：
- 避免类的重复加载：确保一个类在 JVM 中只有一份实例，防止多个类加载器加载同一类产生混乱。
- 保障核心类安全：保证核心类（如java.lang.Object）始终由启动类加载器加载，避免用户自定义类覆盖核心类，防止恶意代码篡改 Java 核心功能。例如，即使在应用程序中编写一个java.lang.Object类，也不会被加载，从而保障 JVM 运行的安全性。

1.8 从 jdk 源码级别看下双亲委派机制实现原理

双亲委派机制在 JDK 源码中通过ClassLoader类的loadClass方法实现，其核心逻辑如下：

public Class loadClass(String name) throws ClassNotFoundException {

return loadClass(name, false);

}

protected Class loadClass(String name, boolean resolve) throws ClassNotFoundException {

synchronized (getClassLoadingLock(name)) {

// 首先，检查请求的类是否已经被加载过

Class c = findLoadedClass(name);

if (c == null) {

long t0 = System.nanoTime();

try {

if (parent != null) {

// 如果父加载器不为null，委托父加载器加载

c = parent.loadClass(name, false);

} else {

// 如果父加载器为null，说明当前是启动类加载器，尝试加载

c = findBootstrapClassOrNull(name);

}

} catch (ClassNotFoundException e) {

// 父加载器无法加载时，抛出异常

}

if (c == null) {

long t1 = System.nanoTime();

// 父加载器无法加载，尝试自己加载

c = findClass(name);

sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);

sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);

sun.misc.PerfCounter.getFindClasses().increment();

}

if (resolve) {

resolveClass(c);

}

return c;

}

关键步骤解析：
1. 首先调用findLoadedClass方法检查类是否已被加载，若已加载则直接返回。
2. 若类未被加载，判断父加载器是否存在，若存在则调用父加载器的loadClass方法进行委托加载。
3. 若父加载器为null（即当前是启动类加载器），调用findBootstrapClassOrNull尝试加载。
4. 若父加载器无法加载，调用自身的findClass方法进行类加载，findClass方法需要子类（如自定义类加载器）重写以实现具体的加载逻辑，比如从指定路径读取字节码并转换为Class对象。
5. 最后，如果需要解析类（resolve参数为true），调用resolveClass方法完成类的解析过程。

1.9 jvm 双亲委派机制设计初衷

双亲委派机制的设计主要是为了解决 Java 程序中类加载的安全性、稳定性和资源管理问题，其设计初衷体现在以下几个方面：

确保核心类的唯一性与安全性：Java 核心类库（如java.lang包下的类）由启动类加载器加载，并且在整个 JVM 生命周期中只有一份实例。这防止了用户自定义类对核心类的覆盖，避免恶意代码通过创建同名核心类来破坏 JVM 的正常运行。例如，若没有双亲委派机制，恶意程序可以创建一个自定义的java.lang.String类，替换真正的String类功能，导致程序出现严重错误和安全漏洞。
避免类的重复加载：通过双亲委派机制，类只会被其最上层合适的类加载器加载一次。比如，多个应用类加载器都需要加载log4j依赖包中的某个类，该类只会由应用类加载器的父加载器（扩展类加载器或启动类加载器，如果在其加载范围内）加载一次，后续其他应用类加载器直接使用已加载的类，减少了内存占用和加载开销，提高了系统性能和资源利用率。
实现类加载的层次化管理：明确了不同类加载器的职责范围，启动类加载器负责核心类，扩展类加载器负责扩展类库，应用类加载器负责应用程序类，自定义类加载器处理特殊需求。这种层次化结构使得类加载过程清晰有序，便于 JVM 进行管理和维护，同时也为开发者提供了灵活的扩展空间，在不破坏整体机制的前提下实现自定义加载逻辑。

1.10 面试常问的沙箱安全机制是怎么回事

JVM 的沙箱安全机制用于限制 Java 程序对系统资源的访问，确保程序在安全的环境中运行，防止恶意代码对主机系统造成损害。其核心实现依赖于类加载器隔离、安全管理器（SecurityManager）和字节码验证：

类加载器隔离：不同来源的类由不同类加载器加载，彼此隔离。例如，从网络下载的 Applet 由自定义类加载器加载，与本地类库隔离，避免恶意代码篡改核心类。
安全管理器：Java 通过SecurityManager类控制程序对系统资源（如文件系统、网络、进程）的访问。当程序尝试执行敏感操作（如读写文件）时，SecurityManager会检查操作是否被授权，若未授权则抛出SecurityException异常。
字节码验证：在类加载的验证阶段，JVM 会检查字节码是否合法，防止包含非法指令或恶意操作的字节码被执行。

1.11 类加载全盘负责委托机制又是怎么回事

全盘负责委托机制是双亲委派机制的延伸，指当一个类加载器加载某个类时，该类的所有依赖类也由同一个类加载器负责加载。例如，应用类加载器加载A类，若A类依赖B类，那么B类也由应用类加载器加载，而不会由其他类加载器加载。这确保了类与类之间的依赖关系一致性，避免因不同类加载器加载同一类的不同版本导致的兼容性问题，维护了程序运行的稳定性。

1.12 彻底理解类加载机制后，我们自己手写一个类加载器

自定义类加载器需继承ClassLoad

er，并通常重写findClass方法（若需打破双亲委派机制，还需重写loadClass方法）：

public class MyClassLoader extends ClassLoader {

private String classPath;

public MyClassLoader(String classPath) {

this.classPath = classPath;

}

@Override

protected Class findClass(String name) throws ClassNotFoundException {

byte[] classData = loadClassData(name);

if (classData == null) {

throw new ClassNotFoundException(name);

}

return defineClass(name, classData, 0, classData.length);

}

private byte[] loadClassData(String name) {

String fileName = classPath + File.separator + name.replace('.', File.separator) + ".class";

try (InputStream is = new FileInputStream(fileName)) {

ByteArrayOutputStream bos = new ByteArrayOutputStream();

byte[] buffer = new byte[1024];

int length;

while ((length = is.read(buffer)) != -1) {

bos.write(buffer, 0, length);

}

return bos.toByteArray();

} catch (IOException e) {

e.printStackTrace();

}

return null;

}

上述代码实现了从指定路径加载.class文件并转换为Class对象的功能，可用于加载加密类、动态生成的类等特殊场景。

1.13 面试常问的打破双亲委派机制是怎么回事

在某些场景下（如热部署、类隔离），需要打破双亲委派机制，即让子类加载器优先于父类加载器加载类：

原理：重写ClassLoader的loadClass方法，改变类加载的委托顺序。例如，Tomcat 的WebappClassLoader通过先尝试自身加载类，若失败再委托给父加载器，实现应用间的类隔离。
应用场景：在微服务框架中，不同服务可能依赖同一库的不同版本，通过打破双亲委派机制，每个服务可使用独立的类加载器加载所需版本的库，避免冲突。

1.14 Tomcat 底层类加载是用的双亲委派机制吗

Tomcat 的类加载机制部分遵循但不完全等同于双亲委派机制：

特殊处理：Tomcat 为每个 Web 应用创建独立的WebappClassLoader，该加载器会优先尝试加载应用自身的类（即WEB-INF/classes和WEB-INF/lib下的类），若无法加载再委托给父加载器。这种 “逆委派” 模式打破了传统双亲委派机制，确保不同 Web 应用的类相互隔离，避免版本冲突。
父加载器关系：WebappClassLoader的父加载器是系统类加载器（应用类加载器），但在加载类时，Tomcat 通过自定义逻辑实现了应用的独立性和隔离性。

1.15 揭开 Tomcat 底层类加载机制的神秘面纱

Tomcat 的类加载机制核心在于应用隔离与灵活加载：

独立类加载器：每个 Web 应用拥有专属的WebappClassLoader，相互隔离。例如，应用 A 和应用 B 可分别加载不同版本的spring - core库，互不干扰。
加载顺序：优先加载WEB-INF/classes目录下的类，再加载WEB-INF/lib中的 jar 包；若仍未找到，则委托给父加载器。
资源隔离：不同应用的资源（如配置文件）也由各自的类加载器管理，确保应用间资源不冲突。

1.16 一个 Tomcat 进程是如何加载多个 war 包中不同 spring 版本的相同类

Tomcat 通过为每个 war 包创建独立的WebappClassLoader实现类版本隔离：

类加载器隔离：每个WebappClassLoader维护独立的类空间，当加载类时，只会在自身管理的类路径中查找。例如，war 包 A 依赖 Spring 5.0，war 包 B 依赖 Spring 5.3，各自的WebappClassLoader会加载对应版本的 Spring 类，避免冲突。
父加载器委托：若WebappClassLoader无法加载类（如核心 Java 类），则委托给父加载器（应用类加载器），确保基础类的共享。

1.17 在理解 Tomcat 类加载机制后，我们自己实现下 Tomcat 的类加载机制

模拟 Tomcat 类加载机制需实现类加载器隔离与自定义加载顺序：

public class CustomWebappClassLoader extends ClassLoader {

private List classPaths;

public CustomWebappClassLoader(List classPaths, ClassLoader parent) {

super(parent);

this.classPaths = classPaths;

}

@Override

protected Class findClass(String name) throws ClassNotFoundException {

for (String path : classPaths) {

byte[] classData = loadClassData(name, path);

if (classData != null) {

return defineClass(name, classData, 0, classData.length);

}

throw new ClassNotFoundException(name);

}

private byte[] loadClassData(String name, String path) {

// 从指定路径加载class文件逻辑

}

通过为每个 “应用” 创建独立的CustomWebappClassLoader，并指定不同的类路径，可模拟 Tomcat 的类隔离加载效果。

1.18 jdk 体系组成结构梳理

JDK（Java Development Kit）是 Java 开发的核心工具包，由以下部分组成：

JRE（Java Runtime Environment）：包含 JVM、核心类库（如rt.jar）和支持文件，是 Java 程序运行的基础环境。
开发工具：如javac（编译器）、java（运行工具）、jar（打包工具）、jdb（调试工具）等，用于开发、编译和调试 Java 程序。
源码：部分核心类库的源代码（如java.lang包下的类），供开发者学习和参考。
其他组件：如 Javadoc（文档生成工具）、JVM 监控和调优工具（如jstat、jmap）。

1.19 JVM 内存结构总览

Java 虚拟机（JVM）在执行 Java 程序过程中，会将其所管理的内存划分为不同的数据区域，这些区域共同构成了 JVM 的运行时数据区。JVM 内存结构主要包括程序计数器、Java 虚拟机栈、本地方法栈、堆、方法区（在 JDK 8 及之后为元空间）以及运行时常量池（作为方法区的一部分）。这些区域各司其职，有的与线程紧密相关，是线程私有的；有的则被所有线程共享，承担着存储对象实例、类元数据等关键信息的重任。准确理解 JVM 内存结构，对于编写高效、稳定的 Java 程序，以及排查内存相关问题至关重要。

1.20 JVM 内存结构与内存溢出异常详解

JVM 内存结构分为多个区域，每个区域都可能因不当使用导致内存溢出（OOM）：

程序计数器：线程私有，记录当前执行的字节码行号，不会发生 OOM。 Java 虚拟机栈：存储方法调用的栈帧（局部变量表、操作数栈等）。若线程请求的栈深度超过 JVM 允许的最大值，抛出StackOverflowError；若 JVM 栈可动态扩展且无法申请到足够内存，抛出OutOfMemoryError。 本地方法栈：与虚拟机栈类似，为 Native 方法服务，同样可能抛出StackOverflowError和OutOfMemoryError。堆：存储对象实例，是垃圾回收的主要区域。若堆空间不足且无法扩展，抛出OutOfMemoryError: Java heap space。 方法区（元空间）：存储类元数据、常量池等。若加载的类过多或常量池过大，导致元空间溢出，抛出OutOfMemoryError: Metaspace。

1.21 运行时常量池与字符串常量池详解

运行时常量池：是方法区的一部分，存储类加载时生成的各种字面量和符号引用。每个类的Class对象都有对应的运行时常量池，在类加载后被创建。
字符串常量池：是运行时常量池的特殊部分，存储字符串字面量。在 JDK 7 之前，字符串常量池位于方法区（永久代）；JDK 7 及以后，移至堆中。例如：

String s1 = "abc"; // 字面量直接入字符串常量池

String s2 = new String("abc"); // 堆中创建新对象，常量池可能已有"abc"

s1指向常量池中的 "abc"，s2指向堆中的对象，两者内存地址不同。

1.22 对象在内存中的存储布局

Java 对象在内存中由三部分组成：

对象头（Object Header）：
- Mark Word：存储对象哈希码、GC 分代年龄、锁状态等信息，长度在 32 位和 64 位 JVM 中分别为 32bit 和 64bit。
- 类型指针：指向对象所属类的元数据，JVM 通过此指针确定对象是哪个类的实例。
- 数组长度（仅数组对象有）：记录数组的长度。
实例数据（Instance Data）：存储对象的字段值，包括父类继承的和子类定义的字段。
对齐填充（Padding）：JVM 要求对象起始地址必须是 8 字节的整数倍，不足时通过对齐填充补齐。

1.23 对象头 Mark Word 详解

Mark Word 是对象头的核心部分，根据对象锁状态不同，存储的信息也不同：

无锁状态：存储对象哈希码、分代年龄。
偏向锁状态：存储偏向线程 ID、时间戳、分代年龄。
轻量级锁状态：存储指向线程栈中锁记录的指针。
重量级锁状态：存储指向互斥量（重量级锁）的指针。
GC 标记：存储是否被垃圾回收的标记信息。

Mark Word 的内容会随锁状态变化而动态调整，通过 CAS 操作实现高效的锁升级和降级。

1.24 对象如何定位访问，句柄与直接指针两种方式

JVM 有两种方式通过引用定位对象：

句柄访问：引用指向句柄池中的句柄，句柄包含对象实例数据和类型数据的地址。优点是引用稳定，对象移动时只需修改句柄，无需修改引用；缺点是访问效率低，需两次寻址。
直接指针：引用直接指向对象地址，对象内部包含类型数据的指针。优点是访问效率高，只需一次寻址；缺点是对象移动时（如 GC 后）需修改所有引用。HotSpot JVM 使用直接指针方式，提高对象访问性能。

1.25 对象创建的完整过程，从字节码层面深入分析

以new Object()为例，字节码执行流程如下：

new #1：在堆中为Object对象分配内存，同时初始化对象头，此时对象字段值为默认值（如int为 0，引用为null）。
dup：复制栈顶的对象引用（即刚创建的Object对象的引用）。
invokespecial #1：调用Object的构造方法()，初始化对象字段值。
astore_1：将对象引用存入局部变量表。

若Object类未加载，会先触发类加载过程，再执行对象创建。

1.26 类初始化与对象初始化的区别与联系

类初始化：执行类构造器()，初始化静态变量和静态代码块，由 JVM 保证线程安全，每个类只初始化一次。
对象初始化：执行实例构造器()，初始化对象字段和实例代码块，每次创建对象时执行。

联系：创建对象前，若类未初始化，会先触发类初始化。例如：

public class InitDemo {

static { System.out.println("Class init"); } // 类初始化时执行

{ System.out.println("Instance init"); } // 对象初始化时执行

public InitDemo() { System.out.println("Constructor"); } // 构造器在最后执行

}

执行new InitDemo()时，输出顺序为：Class init→Instance init→Constructor。

1.27 方法区（元空间）详细介绍

方法区是 JVM 规范中的概念，在不同 JDK 版本有不同实现：

JDK 7 及以前：方法区由 ** 永久代（PermGen）** 实现，使用 JVM 内存，通过-XX:MaxPermSize限制大小。
JDK 8 及以后：方法区由 ** 元空间（MetaSpace）** 实现，使用本地内存，通过-XX:MetaspaceSize和-XX:MaxMetaspaceSize控制。元空间存储类元数据（如类结构、方法字节码）、运行时常量池等，类卸载时会回收元空间内存。

1.28 栈帧的内部结构详解

栈帧是虚拟机栈的基本单位，每个方法调用对应一个栈帧，包含：

局部变量表：存储方法参数和局部变量，以槽（Slot）为单位，32 位类型占 1 个槽，64 位类型（如long、double）占 2 个槽。
操作数栈：执行字节码指令时，用于临时存储操作数和结果。例如，执行i + j时，先将i和j压入操作数栈，再执行加法运算，结果压回栈顶。
动态链接：指向运行时常量池中该方法的符号引用，用于支持方法调用的动态链接。
方法返回地址：记录方法执行完毕后返回的地址，恢复上层方法的执行状态。

1.29 方法调用的字节码指令详解

JVM 提供多种方法调用指令，根据方法类型和调用方式选择：

invokestatic：调用静态方法，编译时确定方法版本。
invokespecial：调用实例构造器()、私有方法和父类方法。
invokevirtual：调用虚方法（非final、非静态、非私有方法），支持多态，运行时根据对象实际类型确定方法版本。
invokeinterface：调用接口方法，运行时动态查找实现类的方法。
invokedynamic：动态语言支持，运行时动态确定方法版本，如 Lambda 表达式的实现。

这些指令通过符号引用定位方法，在类加载的解析阶段或运行时将符号引用转换为直接引用。

1.30 本地方法栈深度解析

本地方法栈（Native Method Stack）与 Java 虚拟机栈功能类似，区别在于它为 JVM 调用 Native 方法（由 C/C++ 实现的方法）服务。

作用：存储 Native 方法的调用状态，包括局部变量、操作数栈等。例如，当 Java 代码调用System.currentTimeMillis()（底层为 Native 方法）时，本地方法栈会为该调用创建栈帧。实现：HotSpot JVM 将本地方法栈与虚拟机栈合并实现，通过-Xoss参数设置本地方法栈大小（如-Xoss 256k），若未显式设置，默认与虚拟机栈大小一致。异常：若 Native 方法递归深度过深或申请内存失败，会抛出StackOverflowError或OutOfMemoryError。

1.31 堆内存的新生代与老年代划分

Java 堆是 JVM 内存管理的核心区域，根据对象生命周期不同，划分为新生代和老年代：

新生代：
- 占比：默认占堆空间的 1/3（可通过-Xmn参数调整）。
- 分区：
  - Eden 区：对象初始分配的区域，占新生代的 8/10。
  - Survivor 区：分为 From Survivor 和 To Survivor，各占新生代的 1/10，用于存放 Minor GC 后存活的对象。
- 特点：对象存活率低，频繁执行 Minor GC（复制算法）。
老年代：
- 占比：默认占堆空间的 2/3。
- 作用：存放新生代中多次 GC 后存活的对象（如长期存活的缓存对象）。
- 特点：对象存活率高，执行 Full GC（标记 - 整理算法）频率较低。

1.32 垃圾回收机制核心概念：GC Roots 与可达性分析

GC Roots 是可达性分析的起点，用于判断对象是否存活。

GC Roots 包括：
- 虚拟机栈（栈帧中的局部变量表）中的引用对象。
- 方法区中的类静态属性引用的对象（如static List list）。
- 方法区中的常量引用的对象（如static final String str = "abc"）。
- 本地方法栈中 Native 方法引用的对象。
可达性分析：从 GC Roots 出发，通过引用链遍历所有可达对象，标记为存活；不可达对象判定为垃圾，等待回收。

示例：若一个对象仅被某个局部变量引用，当该变量所在方法执行完毕，栈帧销毁，对象失去引用，变为不可达，成为垃圾。

1.33 垃圾回收算法：标记 - 清除、复制、标记 - 整理

JVM 根据内存区域特点选择不同垃圾回收算法：

标记 - 清除算法：
- 步骤：先标记所有垃圾对象，再统一清除。
- 缺点：产生内存碎片，导致大对象无法分配内存。
- 应用：老年代（如 CMS 收集器的初始标记和重新标记阶段）。
复制算法：
- 步骤：将存活对象复制到另一块区域，清除原区域。
- 优点：无碎片，执行高效；缺点：浪费一半内存空间。
- 应用：新生代（如 Serial 收集器、ParNew 收集器）。
标记 - 整理算法：
- 步骤：标记存活对象，将其压缩到连续内存空间，清除边界外的垃圾。
- 优点：消除碎片，充分利用内存；缺点：耗时较长。
- 应用：老年代（如 Serial Old 收集器、Parallel Old 收集器）。

1.34 常见垃圾收集器：Serial、Parallel、CMS、G1

JVM 提供多种垃圾收集器，适用于不同场景：

Serial 收集器：
- 类型：单线程、新生代收集器。
- 特点：STW（Stop The World）时间长，适用于客户端应用（如桌面程序）。
Parallel 收集器：
- 类型：多线程、新生代收集器，吞吐量优先（-XX:+UseParallelGC）。
- 特点：通过多线程缩短 STW 时间，适合计算密集型任务。
CMS 收集器：
- 类型：多线程、老年代收集器，低停顿优先（-XX:+UseConcMarkSweepGC）。
- 步骤：初始标记（STW）→ 并发标记 → 重新标记（STW）→ 并发清除。
- 应用：Web 服务器（如 Tomcat），减少响应延迟。
G1 收集器：
- 类型：多线程、分代收集器，可预测停顿时间（-XX:+UseG1GC）。
- 特点：将堆划分为多个 Region，优先回收价值高的 Region，适合大内存（如 8GB+）和低延迟场景。

1.35 垃圾回收日志分析核心参数与示例

通过配置 GC 日志参数，可记录 GC 过程，用于性能调优：

[GC (Allocation Failure) [PSYoungGen: 20480K->5120K(30720K)] 20480K->15360K(102400K), 0.012345s]

1.36 JVM 参数调优核心原则与常用参数

JVM 参数调优需根据应用场景平衡吞吐量与延迟，核心原则：

关键参数：
- -XX:+PrintGC：输出简单 GC 日志。
- -XX:+PrintGCDetails：输出详细 GC 日志（推荐）。
- -XX:+PrintGCTimeStamps：记录 GC 发生的时间戳。
- -Xloggc:/path/to/gc.log：指定日志文件路径。
日志示例：
- PSYoungGen：Parallel 收集器的新生代。
- 20480K->5120K：GC 前后新生代大小。
- 30720K：新生代总容量。
- 102400K：堆总容量。
- 0.012345s：GC 耗时。
堆大小设置：
- -Xms（初始堆大小）与 -Xmx（最大堆大小）建议设为相同值，避免堆自动扩展的性能开销。
- 经验值：生产环境建议-Xmx设为物理内存的 60%~80%（如服务器内存 32GB，设为-Xmx24g）。
新生代大小：
- 通过-Xmn设置，通常为堆大小的 1/3（如堆 12GB，新生代设为-Xmn4g）。
垃圾收集器选择：
- 高吞吐量场景：-XX:+UseParallelGC（Parallel 收集器）。
- 低延迟场景：-XX:+UseG1GC（G1 收集器，JDK 9 + 默认）。
元空间设置：
- -XX:MetaspaceSize=256m（初始元空间大小），-XX:MaxMetaspaceSize=512m（最大元空间大小）。

1.37 日均百万级订单系统 JVM 参数调优实战

以日均百万订单的电商系统为例，JVM 参数调优方案：

-XX:+UseG1GC # 使用G1收集器，适合大内存和低延迟

-XX:MaxGCPauseMillis=200 # 目标GC停顿时间200ms

-XX:G1HeapRegionSize=16m # 设置Region大小为16MB，适应对象大小分布

-Xms8g -Xmx8g # 堆大小8GB，避免动态扩展

-Xmn2g # 新生代2GB（约占堆25%，根据对象存活情况调整）

-XX:MetaspaceSize=512m # 元空间初始512MB

-XX:MaxMetaspaceSize=1024m # 元空间最大1GB，防止类加载过多导致溢出

-XX:+HeapDumpOnOutOfMemoryError # OOM时生成堆转储文件

-XX:HeapDumpPath=/data/heapdump # 堆转储文件路径

调优逻辑：

使用 G1 收集器，通过MaxGCPauseMillis控制停顿时间，满足接口响应延迟要求。
固定堆大小，减少 GC 频率；新生代占比 25%，适应订单系统中短生命周期对象（如订单临时对象）较多的场景。
元空间根据类加载情况调整，避免因动态生成类（如反射、动态代理）导致的 Metaspace 溢出。

1.38 线上系统 GC 调优步骤与案例

GC 调优一般遵循以下步骤：

监控现状：通过jstat -gcutil 1000实时监控 GC 频率和耗时，确定是否存在频繁 GC 或长时间 STW。
分析日志：启用详细 GC 日志，分析 GC 前后内存变化、对象存活率等。
调整参数：根据应用特点调整堆大小、新生代比例、收集器类型等。

验证效果：压测验证 GC 停顿时间、吞吐量是否满足需求。

案例：某系统频繁 Full GC，分析日志发现老年代内存增长快，且大对象较多。

优化前：使用 Parallel 收集器，堆大小 4GB（新生代 1GB），大对象直接进入老年代导致老年代快速填满。
优化措施：
- 启用 G1 收集器（-XX:+UseG1GC），利用 Region 机制管理大对象（Humongous Region）。
- 增大堆大小至 8GB（-Xms8g -Xmx8g），新生代设为 2GB（-Xmn2g）。
结果：Full GC 频率从每小时 10 次降至每小时 1 次，系统响应时间降低 50%。

1.39 内存泄漏排查核心思路与工具

内存泄漏指不再使用的对象未被 GC 回收，导致内存占用持续升高。

排查思路：
1. 监控内存趋势：通过jmap -heap 查看堆内存使用情况，确认是否持续增长。
2. 生成堆转储文件：使用jmap -dump:format=b,file=heap.hprof 生成 dump 文件。
3. 分析大对象：用 MAT（Memory Analyzer Tool）打开 dump 文件，查看Histogram或Dominator Tree，定位占用内存最大的对象。
4. 查找引用链：通过 MAT 的Path to GC Roots功能，查看对象是否被错误引用（如静态变量、长生命周期集合）。

常见原因：

静态集合类持有对象引用（如static List

指标	优化方向	典型工具 / 参数
吞吐量	减少 GC 时间占比，优先选择 Parallel/G1 收集器	-XX:+UseParallelGC, -XX:GCTimeRatio
延迟	降低 STW 时间，选择 CMS/ZGC/Shenandoah 收集器	-XX:+UseConcMarkSweepGC, -XX:MaxGCPauseMillis
内存占用	减少堆和元空间大小，优化对象生命周期，避免内存泄漏	jmap, MAT, -XX:MetaspaceSize

工具	优势	适用场景
MAT	强大的对象引用分析，支持 OQL 查询	离线分析大型堆转储文件
VisualVM	轻量级实时监控，集成 GC 日志分析	快速定位实时内存增长问题
JProfiler	深度性能分析，支持内存分配追踪	复杂内存泄漏与性能瓶颈定位

JVM 性能调优

一、类加载机制

二、JVM 内存结构

三、性能调优工具与实战

四、高级主题

1.1 类加载运行全过程梳理

1.2 Java.exe 运行一个类时 JVM HotSpot 底层做了什么

1.3 初识符号引用、静态链接与动态链接

1. 符号引用（Symbolic References）

2. 静态链接（Static Linking）

3. 动态链接（Dynamic Linking）

4. 两者对比与应用

shape1.calculateArea()和shape2.calculateArea()的具体调用方法在编译期无法确定，需要在运行时通过动态链接，根据对象实际类型（Circle或Rectangle）确定调用的方法地址，实现多态特性。

1.4 war 包或 jar 包是如何加载的

1.5 jvm 中类加载器分类与核心功能

1.6 类加载器在 jvm 中是如何初始化的

1.7 面试中经常问到的类加载双亲委派机制是怎么回事

1.8 从 jdk 源码级别看下双亲委派机制实现原理

1.9 jvm 双亲委派机制设计初衷

1.10 面试常问的沙箱安全机制是怎么回事

1.11 类加载全盘负责委托机制又是怎么回事

1.12 彻底理解类加载机制后，我们自己手写一个类加载器

1.13 面试常问的打破双亲委派机制是怎么回事

1.14 Tomcat 底层类加载是用的双亲委派机制吗

1.15 揭开 Tomcat 底层类加载机制的神秘面纱

1.16 一个 Tomcat 进程是如何加载多个 war 包中不同 spring 版本的相同类

1.17 在理解 Tomcat 类加载机制后，我们自己实现下 Tomcat 的类加载机制

1.18 jdk 体系组成结构梳理

1.19 JVM 内存结构总览

1.20 JVM 内存结构与内存溢出异常详解

1.21 运行时常量池与字符串常量池详解

1.22 对象在内存中的存储布局

1.23 对象头 Mark Word 详解

1.24 对象如何定位访问，句柄与直接指针两种方式

1.25 对象创建的完整过程，从字节码层面深入分析

1.26 类初始化与对象初始化的区别与联系

1.27 方法区（元空间）详细介绍

1.28 栈帧的内部结构详解

1.29 方法调用的字节码指令详解

1.30 本地方法栈深度解析

1.31 堆内存的新生代与老年代划分

1.32 垃圾回收机制核心概念：GC Roots 与可达性分析

1.33 垃圾回收算法：标记 - 清除、复制、标记 - 整理

1.34 常见垃圾收集器：Serial、Parallel、CMS、G1

1.35 垃圾回收日志分析核心参数与示例

1.36 JVM 参数调优核心原则与常用参数

1.37 日均百万级订单系统 JVM 参数调优实战

1.38 线上系统 GC 调优步骤与案例

1.39 内存泄漏排查核心思路与工具

1.40 JVM 线程模型与栈帧生命周期详解

1.41 偏向锁、轻量级锁与重量级锁原理剖析

1.42 锁优化策略：自旋锁、锁消除与锁粗化

1.43 逃逸分析及其对性能优化的影响

1.44 即时编译（JIT）技术详解

1.45 JVM 监控工具：jps、jstat、jmap 与 jstack

1.46 死锁检测与定位实战

1.47 类卸载机制与触发条件

1.48 JVM 内存屏障原理与应用场景

1.49 多线程环境下的伪共享（False Sharing）问题

1.50 对象动态年龄判断机制

1.51 老年代空间分配担保机制

1.52 判断对象是否是垃圾的引用计数法缺陷

1.53 可达性分析算法如何找垃圾对象

1.54 强引用、软引用、弱引用与虚引用实战应用

1.55 不可达对象的 “最后存活机会”

1.56 什么样的类能被回收（类卸载条件）

1.57 深挖 Class 文件内部结构组成

1.58 结合字节码理解抽象的常量池

1.59 常量池项的分类与解析

1.60 字节码指令执行引擎工作流程

1.61 常见字节码指令分类与功能详解

1.62 深入理解 JVM 内存分配策略

1.63 多线程环境下的对象内存分配竞争优化

1.64 JVM 中的内存分配担保失败场景分析

1.65 类加载过程中的验证阶段详细解析

1.66 类加载过程中解析阶段的作用与实现

1.67 JVM 多线程模型中的线程同步原语

1.68 线程池实现原理与 JVM 资源管理

1.69 JVM 内存压缩（Compressed Oops）技术解析

1.70 字节码指令重排序与 Happens-Before 原则