【Java核心】JVM核心知识清单

梳理JVM最核心、最常用的知识点，覆盖小白入门到面试高频的核心内容，按照「基础架构→核心机制→性能调优→面试重点」的逻辑，把JVM的核心知识点系统化整理，每个知识点都用通俗的语言讲清「是什么、为什么、怎么用/怎么考」。

注：以下内容是JVM的「核心知识清单」，也是企业面试、日常开发调优最常接触的内容，优先掌握这些，就能搞定90%的JVM场景。

一、JVM核心架构（基础中的基础）

JVM的整体架构是理解所有机制的前提，核心分为五大模块，记住这个结构，后续知识点都能对应上：
类加载子系统
运行时数据区
执行引擎
本地方法接口JNI
垃圾回收器GC

1. 类加载子系统

核心作用 ：把.class字节码文件加载到内存，完成「加载→验证→准备→解析→初始化」5个阶段；
核心考点 ：
- 类加载的5个阶段（尤其是「准备阶段」：给静态变量分配内存并赋默认值，而非初始化值）；
- 类加载器的层级（启动类加载器Bootstrap→扩展类加载器Extension→应用类加载器Application）；
- 双亲委派模型（避免类重复加载，保证核心类的安全性，比如自己写的java.lang.String不会被加载）。

2. 运行时数据区（JVM内存模型，高频考点）

这是JVM最核心的模块，面试必考，小白必须吃透：

内存区域	作用	是否线程私有	垃圾回收	核心考点
程序计数器	记录当前线程执行的字节码行号	是	不回收	唯一不会OOM的区域；多线程切换的基础
虚拟机栈	存储方法的栈帧（参数、局部变量）	是	不回收	栈帧的结构；StackOverflowError（栈溢出）
本地方法栈	为native方法提供栈空间	是	不回收	和虚拟机栈类似，区别是服务于native方法
堆	存储对象实例和数组	否	核心回收	堆的分代（新生代Eden/S0/S1 + 老年代）；OOM的主要区域
方法区（元空间）	存储类信息、常量、静态变量	否	可回收	JDK8后用元空间（本地内存）替代永久代；常量池的分类（静态/运行时常量池）

3. 执行引擎

核心作用：执行字节码，包括解释器（逐行解释）+ JIT编译器（编译热点代码）+ 本地方法接口（调用C/C++代码）；
核心考点：解释器和JIT的配合机制；方法内联等JIT优化策略。

4. 本地方法接口（JNI）

核心作用 ：让Java调用C/C++写的本地方法（比如System.currentTimeMillis()底层是native方法）；
核心考点：native方法的执行流程；为什么需要JNI（Java无法直接操作底层硬件/系统调用）。

5. 垃圾回收器（GC）

核心作用：回收堆中不再使用的对象，释放内存；
核心考点：GC算法、常见回收器、GC触发时机（后面单独讲）。

二、JVM核心机制（面试/调优高频）

1. 垃圾回收（GC）：JVM的「内存清洁工」

（1）先搞懂：哪些对象需要回收？（可达性分析算法）

核心逻辑：以「GC Roots」为起点，遍历对象引用链，没有被引用的对象就是可回收对象；
GC Roots包括：虚拟机栈中的局部变量、方法区中的静态变量、本地方法栈中的native对象等；
面试考点：可达性分析的核心；finalize()方法的作用（对象回收前的最后一次自救机会，几乎不用）。

（2）GC算法（底层逻辑）

算法	核心逻辑	优点	缺点	适用区域
标记-清除	标记可回收对象 → 清除	简单	内存碎片、效率低	老年代
标记-复制	把存活对象复制到新区域 → 清空原区域	无内存碎片、效率高	浪费一半内存	新生代（Eden/S0/S1）
标记-整理	标记存活对象 → 移动到一端 → 清除剩余	无内存碎片	效率低（需要移动对象）	老年代

（3）常见GC回收器（实际调优用）

回收器	核心特点	适用场景	面试考点
Serial GC	单线程回收，暂停所有用户线程	单核心、小型程序	最简单的回收器；Stop The World（STW）时间长
ParNew GC	多线程版Serial GC	新生代、配合CMS使用	新生代默认回收器之一；多线程提升效率
Parallel GC	多线程、关注吞吐量	后台运算、批处理程序	吞吐量优先；JDK8默认回收器
CMS GC	并发标记清除、关注低延迟	高并发服务（如Web）	分4步（初始标记/并发标记/重新标记/并发清除）；会产生内存碎片
G1 GC	区域化分代式、兼顾吞吐量和延迟	大内存、高并发服务	JDK9默认回收器；把堆分成多个Region；可预测STW时间
ZGC/Shenandoah	几乎无STW、超低延迟	超大内存（TB级）场景	面试拔高考点；基于着色指针和读屏障

（4）GC触发时机（小白必记）

新生代GC（Minor GC）：Eden区满时触发，只回收新生代，STW时间短；
老年代GC（Major GC/Full GC）：老年代满时触发，回收新生代+老年代，STW时间长，要尽量避免；
Full GC的常见原因：老年代满、元空间满、System.gc()手动触发（不建议）。

2. 类加载机制：JVM的「类加载器」

（1）双亲委派模型（核心）

逻辑：加载类时，先让父类加载器加载，父类加载不了再自己加载；
作用：① 避免类重复加载；② 保证核心类的安全性（比如java.lang.String只能由启动类加载器加载，防止篡改）；
面试考点：如何打破双亲委派模型（比如Tomcat的自定义类加载器，为了实现不同应用加载不同版本的类）。

（2）类的生命周期

加载 → 验证 → 准备 → 解析 → 初始化 → 使用 → 卸载；
关键考点：初始化阶段的触发时机（比如new对象、调用静态方法/变量、反射、初始化子类时先初始化父类）。

3. 内存溢出（OOM）：JVM的「内存告警」

小白必须能识别常见OOM类型和解决思路：

OOM类型	原因	解决思路
Java堆溢出	创建对象过多，堆内存不足	调大堆内存（-Xmx）；排查内存泄漏（比如对象被长期引用）
虚拟机栈溢出	方法递归调用过深、栈帧过大	调大栈内存（-Xss）；优化递归逻辑
元空间溢出	加载的类过多（比如动态代理）	调大元空间（-XX:MetaspaceSize）；排查类重复加载
直接内存溢出	NIO使用的直接内存不足	调大直接内存（-XX:MaxDirectMemorySize）

三、JVM性能调优（实战核心）

调优是JVM知识的落地，小白先掌握「核心参数+调优思路」：

1. 核心JVM参数（必记）

参数	作用	示例
-Xms	堆初始内存	-Xms512m（初始512MB）
-Xmx	堆最大内存	-Xmx1024m（最大1GB）
-Xmn	新生代内存	-Xmn512m
-Xss	线程栈大小	-Xss1m
-XX:MetaspaceSize	元空间初始大小	-XX:MetaspaceSize=128m
-XX:+UseG1GC	使用G1回收器
-XX:+PrintGCDetails	打印GC详细日志
-XX:+HeapDumpOnOutOfMemoryError	OOM时生成堆转储文件

2. 调优核心思路（小白入门版）

先监控：用JDK自带工具（jps/jstat/jmap/jvisualvm）查看堆内存、GC频率、STW时间；
定目标：是追求吞吐量（后台程序）还是低延迟（Web服务）；
调参数 ：
- 堆内存：-Xms和-Xmx设为相同值（避免动态扩容）；
- 回收器：Web服务用G1，批处理用Parallel GC；
- 新生代比例：新生代占堆的1/3~1/2（新生代越大，Minor GC频率越低）；
验证效果：观察GC频率、STW时间是否符合预期，OOM是否解决。

四、面试高频考点清单（小白必背）

基础类

JVM的内存结构（堆、栈、方法区等的作用和区别）；
垃圾回收算法和常见回收器的区别；
双亲委派模型的原理和作用；
解释器和JIT编译器的配合机制；
OOM的常见类型和解决思路。

拔高类

G1回收器的工作原理；
如何排查内存泄漏（比如用MAT分析堆转储文件）；
打破双亲委派模型的场景（如Tomcat类加载器）；
元空间和永久代的区别；
方法内联等JIT优化策略。

总结

核心架构：JVM五大模块（类加载+运行时数据区+执行引擎+JNI+GC）是基础，其中「运行时数据区」和「GC」是重中之重；
核心机制：垃圾回收（算法/回收器/触发时机）、类加载（双亲委派）、OOM排查是面试/调优的核心；
实战调优：先监控再调参，核心参数（-Xms/-Xmx/-Xmn）+ 回收器选择是小白入门的关键。

常量池的分类（静态常量池/运行时常量池），并通过具体案例讲清楚两者的定义、存储内容、区别和关联，这是JVM中高频且容易混淆的知识点，

一、先理清核心概念：常量池的两类核心形态

常量池本质是存储「常量」的容器，但在不同阶段有不同形态，核心分为两类：

类型	别名	存在阶段	存储位置	核心作用
静态常量池	类文件常量池/字节码常量池	编译后（.class文件中）	.class文件的特定区域	存储编译期就能确定的常量，是运行时常量池的「原材料」
运行时常量池	运行时池	类加载后（JVM内存中）	方法区（元空间）	静态常量池的「运行时版本」，可动态添加常量

二、静态常量池（类文件常量池）：编译期的「常量仓库」

1. 核心定义

静态常量池是编译后的.class文件中专门存储常量的区域，是Java编译器在编译阶段就确定好的常量集合，不依赖JVM运行时环境。

2. 存储内容（小白易懂版）

静态常量池里存的是「编译期可知的常量」，主要包括：

字面量：字符串字面量（如"hello"）、数字字面量（如100、3.14）；
符号引用：类/接口的全限定名、方法名+参数+返回值、字段名+类型（这些不是最终内存地址，只是「符号」）；
其他常量：final修饰的静态变量（编译期确定值的）、基本类型的包装类常量（如Integer.valueOf(100)）。

3. 具体案例（看得到的静态常量池）

案例1：通过javap命令查看静态常量池

先写一段简单代码：

java 复制代码

// TestConstant.java
public class TestConstant {
    // 编译期确定的final静态常量
    public static final String FIX_STR = "fixed string";
    public static final int FIX_NUM = 100;
    
    public static void main(String[] args) {
        String s1 = "hello jvm"; // 字符串字面量
        int num = 200; // 数字字面量
        System.out.println(s1 + num);
    }
}

执行编译和反编译命令：

bash 复制代码

# 1. 编译生成.class文件
javac TestConstant.java

# 2. 反编译查看字节码（重点看Constant pool部分）
javap -v TestConstant.class

反编译结果中会看到「Constant pool」区域（这就是静态常量池），关键内容如下（简化版）：

复制代码

Constant pool:
   #1 = Methodref          #6.#20         // java/lang/Object."<init>":()V
   #2 = String             #21            // fixed string （FIX_STR的字面量）
   #3 = Integer            100            // FIX_NUM的数字字面量
   #4 = String             #22            // hello jvm （s1的字面量）
   #5 = Integer            200            // num的数字字面量
   #6 = Class              #23            // TestConstant （类的全限定名）
   #7 = Methodref          #24.#25        // java/lang/System.out:Ljava/io/PrintStream;
   ...

✅ 解读：

#2 存储了字符串字面量"fixed string"（对应代码中的FIX_STR）；
#3 存储了数字字面量100（对应FIX_NUM）；
#4 存储了"hello jvm"，#5存储了200；
#1/#6/#7 是符号引用（方法、类、字段的引用符号）。

案例2：静态常量池的核心特征（编译期确定）

修改代码，把final常量改成「运行时才能确定的值」：

java 复制代码

public class TestConstant2 {
    // 这个值编译期无法确定，不会进入静态常量池
    public static final int DYNAMIC_NUM = new Random().nextInt(100);
    
    public static void main(String[] args) {
        System.out.println(DYNAMIC_NUM);
    }
}

反编译后会发现：静态常量池中没有DYNAMIC_NUM的数值（因为编译期不知道它的值），它的赋值会延迟到类初始化阶段。

三、运行时常量池：JVM内存中的「动态常量仓库」

1. 核心定义

当JVM通过类加载器把.class文件加载到内存时，会把静态常量池中的内容「拷贝」到方法区（元空间） 中，形成「运行时常量池」------它是静态常量池的「运行时版本」，且支持动态添加常量（这是和静态常量池的核心区别）。

2. 核心特点

动态性 ：静态常量池只能存编译期确定的常量，而运行时常量池可以在运行时新增常量（最典型的是String.intern()方法）；
符号引用转直接引用：类加载的「解析阶段」，运行时常量池中的「符号引用」（如方法名）会被替换成实际的内存地址（直接引用）；
每个类独有：每个类加载后，都会在方法区生成对应的运行时常量池，互不干扰。

3. 具体案例（运行时常量池的动态性+解析过程）

案例1：String.intern()动态添加常量

这是运行时常量池最典型的使用场景，代码如下：

java 复制代码

public class RuntimeConstantPoolDemo {
    public static void main(String[] args) {
        // 1. s1是new出来的，字符串对象在堆中，不在常量池
        String s1 = new String("hello"); 
        // 2. intern()：如果常量池没有"hello"，就把堆中的"hello"引用添加到运行时常量池
        String s2 = s1.intern(); 
        // 3. s3直接引用常量池中的"hello"
        String s3 = "hello"; 
        
        // 输出false：s1是堆对象，s3是常量池引用
        System.out.println(s1 == s3); 
        // 输出true：s2是常量池中的引用，和s3一致
        System.out.println(s2 == s3); 
    }
}

✅ 底层逻辑：

编译期：静态常量池中有"hello"字面量；
类加载后："hello"被拷贝到运行时常量池；
运行时：new String("hello")在堆中创建对象，s1.intern()检查运行时常量池，发现已有"hello"，直接返回常量池引用；
如果把代码改成String s1 = new String("hello" + "world");（编译期能确定拼接结果），静态常量池会有"helloworld"；如果是new String("hello" + new Random().nextInt())（运行时拼接），静态常量池没有，intern()会把运行时生成的字符串添加到运行时常量池。

案例2：符号引用转直接引用（运行时常量池的解析）

还是看之前的TestConstant类，其中System.out.println()在静态常量池中是「符号引用」（#7 = Methodref #24.#25 // java/lang/System.out:Ljava/io/PrintStream;），类加载的「解析阶段」，JVM会把这个符号引用替换成System.out的实际内存地址（直接引用），这样运行时才能真正调用println()方法。

案例3：运行时常量池溢出（OOM）

JDK7前，运行时常量池在永久代，容易溢出；JDK8后移到元空间，默认内存上限高，但仍可通过参数限制：

java 复制代码

// JDK8下测试运行时常量池溢出（元空间溢出）
public class RuntimeConstantPoolOOM {
    public static void main(String[] args) {
        List<String> list = new ArrayList<>();
        int i = 0;
        while (true) {
            // 不断生成新字符串并添加到运行时常量池
            list.add(String.valueOf(i++).intern());
        }
    }
}

执行命令（限制元空间大小）：

bash 复制代码

java -XX:MetaspaceSize=10m -XX:MaxMetaspaceSize=10m RuntimeConstantPoolOOM

最终会抛出java.lang.OutOfMemoryError: Metaspace（元空间溢出），本质是运行时常量池占用的元空间不足。

四、静态常量池 vs 运行时常量池（核心区别总结）

对比维度	静态常量池	运行时常量池
存在形式	.class文件中的字节码区域	JVM方法区（元空间）中的内存区域
生成时机	编译期（javac编译时）	类加载阶段（加载到JVM后）
内容特性	仅存储编译期确定的常量	继承静态常量池内容，可动态添加
核心作用	存储编译期常量，供类加载使用	运行时解析符号引用、提供常量访问
溢出风险	无（只是文件中的数据）	有（元空间/OOM）

总结

静态常量池：是.class文件里的「编译期常量仓库」，存字面量和符号引用，编译期确定，是运行时常量池的原材料；
运行时常量池：是JVM内存中（元空间）的「动态常量仓库」，由静态常量池拷贝而来，支持动态添加（如intern()），并完成符号引用到直接引用的解析；
核心案例：通过javap查看静态常量池、String.intern()操作运行时常量池，是理解两者的关键。

两个核心问题：一是标记-清除（Mark-Sweep）算法为什么效率低，二是效率低的它为何又适合老年代。从「算法执行流程→效率低的根源→老年代的特性匹配」三个维度，用通俗的逻辑+底层原理讲清楚，小白也能理解。

一、先拆解：标记-清除算法的完整执行流程

要理解效率低的原因，先搞懂它的执行步骤（这是基础）：

标记-清除算法分为两个核心阶段，且全程会触发「Stop The World（STW）」------暂停所有用户线程，只执行GC操作。
开始GC
标记阶段：遍历所有GC Roots，标记存活对象
清除阶段：遍历整个内存区域，清除未标记的可回收对象
GC结束，恢复用户线程

举个通俗例子：把内存看作一个「大仓库」，里面堆满了箱子（对象），标记-清除就像：

标记阶段：仓库管理员逐个检查箱子，给「还在用的箱子」贴红标签（标记存活）；
清除阶段：管理员再逐个检查箱子，把没贴红标签的箱子搬走（清除垃圾）。

二、标记-清除算法「效率低」的核心原因

它的效率低体现在标记、清除两个阶段都有严重的性能损耗，且是「全量遍历」导致的硬伤：

1. 标记阶段：全量遍历，耗时随内存规模线性增长

底层逻辑：标记阶段需要从GC Roots出发，遍历整个对象引用链，不管是存活对象还是垃圾对象，都要遍历到------老年代内存空间大、对象数量多，这个遍历过程会非常慢；
效率问题：比如老年代有10GB内存、百万级对象，标记阶段需要逐个检查这些对象的引用关系，耗时可达几百毫秒甚至秒级，STW时间长，直接影响用户线程的响应。

2. 清除阶段：全量扫描+随机IO，效率极低

问题1：全量扫描内存区域。清除阶段不是只扫垃圾对象，而是遍历整个内存空间，检查每个内存块是否被标记（存活），未标记的才清除------相当于管理员要把仓库每个角落都走一遍，而不是只找垃圾；
问题2：随机IO损耗。清除后的内存是「碎片化」的（后面讲），但清除过程本身需要对内存块做「释放标记」，这些内存块分散在整个老年代，CPU需要频繁切换内存地址（随机访问），相比连续内存的顺序访问，效率差一个量级；
极端情况：如果老年代中存活对象占90%，清除阶段依然要遍历100%的内存，只清除10%的垃圾，做了大量无用功。

3. 额外损耗：内存碎片导致后续分配效率低（间接降低整体效率）

这不是GC阶段的直接效率问题，但会影响程序运行时的内存分配效率：

标记-清除后，内存中会出现大量「零散的空闲内存块」（碎片），就像仓库搬走垃圾后，地面剩下很多零散的空位，无法放下大箱子；
后续分配大对象（如大数组、大POJO）时，JVM需要「遍历所有空闲碎片」，找到能容纳大对象的连续空间------这个遍历过程会增加内存分配的耗时，间接降低程序整体效率。

总结效率低的核心：「全量遍历+STW长」

标记-清除的两个核心步骤都是「全量操作」，没有任何「局部化优化」（比如只处理部分内存），导致GC耗时和内存规模、对象数量强绑定，内存越大、对象越多，效率越低。

三、为什么效率低的标记-清除，却「适合老年代」？

核心原因是：老年代的特性，让标记-清除的「缺点可接受」，而其他算法的「缺点更致命」。我们先明确老年代的核心特性，再对比分析：

1. 老年代的核心特性（关键前提）

特性1：对象「存活率极高」（90%以上）。老年代存放的是存活时间长的对象（比如缓存对象、全局对象），每次GC只有少量对象需要回收；
特性2：对象「体积大、移动成本高」。老年代的对象大多是大对象，且内存空间大（通常占堆的2/3），移动这些对象需要大量的内存拷贝，耗时远超标记-清除；
特性3：对「内存碎片的容忍度高于移动成本」。老年代的大对象分配频率远低于新生代，内存碎片的影响可以通过「空间分配担保」「碎片整理（Mark-Compact）兜底」来缓解。

2. 标记-清除适配老年代的核心逻辑

我们对比「标记-清除」和其他GC算法，看为什么老年代选它：

算法	核心缺点	是否适合老年代	原因
标记-清除	效率低、内存碎片	适合	无需移动对象，适配老年代高存活率、大对象的特性
标记-复制	浪费50%内存、移动对象	极不适合	老年代内存大，浪费50%内存不可接受；移动大对象耗时极长
标记-整理	效率低（需要移动对象）	可作为补充	效率比标记-清除更低，但能解决碎片问题，通常和标记-清除配合使用

（1）对比标记-复制：老年代绝对不能用标记-复制

标记-复制（新生代的核心算法）需要把内存分成「Eden区+两个Survivor区」，每次只使用其中一半，另一半作为复制目标------老年代如果用这种方式：

内存浪费：比如老年代有20GB，就要预留10GB空内存，这在生产环境中完全不可接受；
移动成本：老年代大对象多，复制这些对象需要大量内存拷贝，STW时间会比标记-清除更长（比如移动10GB对象，耗时可达秒级）。

（2）标记-清除的「缺点」在老年代中是「次优解」

虽然标记-清除效率低，但「无需移动对象」是最大优势：老年代高存活率意味着「清除阶段要处理的垃圾少」，相比移动大量存活对象（标记-整理），标记-清除的STW时间反而更短；
内存碎片的问题可以缓解：比如CMS回收器（老年代核心回收器）采用「标记-清除」为主，只在碎片过多时触发「标记-整理」，既兼顾效率，又解决碎片问题。

3. 实际应用：CMS回收器的验证

老年代主流的CMS回收器，核心就是基于「标记-清除」算法设计的，它的优化思路也印证了标记-清除适配老年代：

CMS把「标记阶段」拆分为「初始标记（快速）+ 并发标记（和用户线程并行）+ 重新标记（快速）」，只让「初始标记、重新标记」短暂STW，「并发标记」不阻塞用户线程------解决了标记阶段的STW长问题；
CMS的「清除阶段」也是并发执行（和用户线程并行），进一步降低STW时间；
只有当CMS检测到内存碎片过多时，才会触发「标记-整理」做碎片整理------用偶尔的低效率，换取大部分时间的高响应。

四、核心总结（面试必背）

1. 标记-清除效率低的原因

标记阶段：全量遍历对象引用链，耗时随内存规模增长；
清除阶段：全量扫描内存区域，随机IO损耗大；
间接影响：内存碎片导致后续大对象分配效率低。

2. 标记-清除适合老年代的原因

老年代对象存活率高、移动成本高，标记-清除无需移动对象，相比标记-复制（浪费内存）、标记-整理（移动对象耗时），是「次优解」；
老年代对内存碎片的容忍度高于移动成本，且可通过标记-整理兜底解决碎片问题；
CMS等老年代回收器通过「并发标记/清除」优化标记-清除的STW问题，进一步适配老年代的低延迟需求。

Tomcat自定义类加载器的根本原因------核心是为了解决「不同Web应用加载不同版本类」的问题，我会从「JVM默认类加载器的局限性→Tomcat的核心需求→自定义类加载器的底层逻辑」三个层面，讲清楚为什么必须自定义，以及背后的核心设计思想。

一、先明确前提：JVM默认类加载器的「双亲委派模型」的局限性

Tomcat自定义类加载器的根本原因，是JVM默认的双亲委派模型无法满足Tomcat作为「多应用容器」的核心需求。

1. 双亲委派模型的核心规则（复习）

加载类时，先委托「父类加载器」加载，父类加载器加载不了，才自己加载；
核心目标：保证核心类（如java.lang.String）的唯一性，避免篡改，同时避免类重复加载。

2. 双亲委派模型对Tomcat的「致命限制」

如果Tomcat用JVM默认的类加载器（应用类加载器AppClassLoader），会出现两个核心问题：

问题1：不同Web应用的类无法隔离
所有Web应用（如app1、app2）共用一个AppClassLoader，一旦加载了com.mysql.cj.jdbc.Driver（MySQL驱动），其他应用只能用同一个版本------如果app1需要mysql-8.0.jar，app2需要mysql-5.1.jar，就会冲突（类版本不一致，抛出NoSuchMethodError或ClassCastException）。
问题2：Web应用的类无法独立卸载
AppClassLoader加载的类，只有JVM停止才会卸载；而Tomcat需要支持「热部署」（不重启Tomcat，直接更新Web应用），如果类无法卸载，热部署时会出现类内存泄漏，最终导致OOM。
问题3：Tomcat自身的类和应用类无法隔离
Tomcat自身依赖的类（如catalina.jar）和Web应用的类如果重名（比如都有com.test.Util），会被AppClassLoader优先加载Tomcat的类，导致应用类无法正常加载。

二、Tomcat自定义类加载器的「根本原因」：满足「类隔离+独立加载/卸载」需求

Tomcat的核心定位是「多Web应用容器」，必须让每个Web应用的类加载完全独立------这是双亲委派模型做不到的，因此必须自定义类加载器，核心目标有三个：

1. 核心原因1：实现「应用间类隔离」（解决版本冲突）

这是你提到的「不同应用加载不同版本类」的核心底层逻辑：

Tomcat为每个Web应用创建一个独立的「WebAppClassLoader」（自定义类加载器）；
每个WebAppClassLoader只加载自己应用WEB-INF/classes和WEB-INF/lib下的类；
不同WebAppClassLoader加载的类，即使全类名相同（如com.mysql.cj.jdbc.Driver），也被JVM视为「不同的类」（JVM判断类唯一性的规则：全类名 + 类加载器）。

通俗案例：

app1的WebAppClassLoader加载mysql-8.0.jar中的Driver类；
app2的WebAppClassLoader加载mysql-5.1.jar中的Driver类；
两个Driver类在JVM中是独立的，互不干扰，彻底解决版本冲突。

2. 核心原因2：实现「类的独立加载/卸载」（支持热部署）

每个WebAppClassLoader和对应的Web应用绑定：当卸载Web应用（如热部署）时，只需销毁对应的WebAppClassLoader，该加载器加载的所有类都会被JVM标记为可回收，从而实现类的卸载；
如果用默认的AppClassLoader，类加载器是全局的，无法单独卸载某个应用的类，热部署就成了空谈。

3. 核心原因3：实现「Tomcat自身类和应用类隔离」

Tomcat设计了多层自定义类加载器（经典的「双亲委派模型变种」）：
BootstrapClassLoader（启动类加载器）
CommonClassLoader（Tomcat通用类加载器）
CatalinaClassLoader（Tomcat核心类加载器）
SharedClassLoader（共享类加载器）
WebAppClassLoader（应用类加载器）

CommonClassLoader：加载Tomcat所有组件共享的类；
CatalinaClassLoader：加载Tomcat核心（catalina）的类，不共享给应用；
SharedClassLoader：加载所有应用共享的类（可选）；
WebAppClassLoader：每个应用独立的类加载器，优先加载自己的类，再委托父类加载器。

这种层级设计，让Tomcat自身的类和应用类完全隔离，避免类名冲突。

三、Tomcat自定义类加载器的「关键设计：打破双亲委派模型」

为了实现类隔离，Tomcat的WebAppClassLoader主动打破了双亲委派模型的默认规则：

常规双亲委派：「先父后子」（先委托父加载器加载，加载不到自己再加载）；
Tomcat的规则：「先子后父」（优先加载自己应用WEB-INF下的类，加载不到再委托父加载器）。

底层逻辑：

当WebAppClassLoader加载类时，首先检查自己的WEB-INF/classes和WEB-INF/lib；
如果找到类，直接加载（不管父加载器是否有这个类）；
如果没找到，再委托父加载器（SharedClassLoader/CommonClassLoader）加载；
核心目的：保证应用的类优先加载，避免父加载器的类覆盖应用类（比如Tomcat的Util类不会覆盖应用的Util类）。

四、总结：Tomcat自定义类加载器的根本原因

核心需求驱动：Tomcat作为多Web应用容器，需要解决「类隔离（不同应用加载不同版本类）、类独立卸载（热部署）、自身类和应用类隔离」三大问题；
技术限制：JVM默认的双亲委派模型无法满足上述需求（全局类加载器、类无法隔离/卸载）；
解决方案：通过自定义类加载器（WebAppClassLoader）为每个应用创建独立的类加载上下文，打破双亲委派的「先父后子」规则，实现类的隔离、独立加载和卸载。

关键补充（面试考点）

JVM判断类唯一性的规则：全限定类名 + 加载该类的类加载器实例------这是类隔离的底层基础；
Tomcat热部署的核心：销毁旧的WebAppClassLoader，创建新的WebAppClassLoader加载更新后的应用类；
自定义类加载器的核心重写方法：findClass()（指定类的加载路径）和loadClass()（修改类加载的委派规则）。

Tomcat为何要在默认类加载器体系外新增Common（通用）、Catalina（核心）、Shared（共享）这三个加载器，以及Common和Shared看似都是「通用/共享」却要分开设计的原因，核心是理解这三个加载器的分工边界和Tomcat「分层隔离」的设计思想。

先纠正一个小前提：Tomcat并没有「去掉」JVM的扩展类加载器（Extension ClassLoader），而是在「应用类加载器（AppClassLoader）」之下，新增了自己的三层加载器体系，和JVM原生加载器是「层级叠加」而非替换。

一、先明确Tomcat类加载器的完整层级（避免混淆）

先把层级理清楚，后面的分工才好理解：
BootstrapClassLoader（JVM启动类加载器）
ExtensionClassLoader（JVM扩展类加载器）
AppClassLoader（JVM应用类加载器）
CommonClassLoader（Tomcat通用类加载器）
CatalinaClassLoader（Tomcat核心类加载器）
SharedClassLoader（Tomcat共享类加载器）
WebAppClassLoader（每个应用独立）

二、Common/Catalina/Shared三个加载器的核心分工（通俗版）

这三个加载器的设计核心是「按"使用范围"分层隔离」------把不同使用场景的类分开加载，避免互相干扰，先看每个加载器的核心职责：

加载器名称	核心分工（加载哪些类）	使用范围	核心目标
CommonClassLoader	Tomcat全局通用类（所有组件都用）	整个Tomcat容器	让Tomcat核心组件共享基础类，避免重复加载
CatalinaClassLoader	Tomcat核心业务类（容器自身用）	仅Tomcat容器内部（如Catalina）	隔离Tomcat核心类，不让应用访问
SharedClassLoader	所有Web应用共享的类（可选）	所有Web应用（app1/app2等）	让应用共享通用类（如通用工具包），但不影响Tomcat核心

举个生活化例子：

把Tomcat比作一个「写字楼」：

CommonClassLoader：写字楼的「公共设施」（电梯、水电系统），所有租户（Tomcat组件）和公司（Web应用）都能用；
CatalinaClassLoader：写字楼的「物业办公室专属设备」（管理系统、监控设备），只有物业（Tomcat核心）能用，租户碰不到；
SharedClassLoader：写字楼的「租户共享区」（会议室、打印机），所有租户（Web应用）都能用，但和物业设备隔离；
WebAppClassLoader：每个公司的「独立办公室」，里面的东西只有自己公司能用。

三、为什么要拆分这三个加载器？（核心原因）

1. 核心原因1：「Tomcat核心类」和「应用类」必须严格隔离

如果把CatalinaClassLoader的功能合并到CommonClassLoader，会导致：

Tomcat的核心类（如org.apache.catalina.core.StandardContext）会被所有Web应用访问到，存在安全风险（应用可能篡改Tomcat核心逻辑）；
应用如果引入和Tomcat核心类重名的类（比如自定义org.apache.catalina.Util），会覆盖Tomcat的核心类，导致容器崩溃；
CatalinaClassLoader加载的类不允许被Web应用访问，而CommonClassLoader加载的类是「全局可见」的------这种访问权限的差异，必须用不同加载器隔离。

2. 核心原因2：「Tomcat全局类」和「应用共享类」的生命周期不同

CommonClassLoader加载的是Tomcat自身的基础类（如日志包、通用工具类），这些类的生命周期和Tomcat容器一致（Tomcat启动时加载，停止时卸载）；
SharedClassLoader加载的是应用共享类（如通用的JSON包、数据库驱动），这些类的生命周期和「应用集群」相关------如果需要更新应用共享类，只需重启应用，无需重启Tomcat；
如果合并成一个加载器，更新应用共享类时会牵连Tomcat核心类，导致容器需要重启，违背「热部署」的设计目标。

3. 核心原因3：「通用」和「共享」的语义完全不同（回答你的核心疑问）

你觉得「通用」和「共享」是一个意思，但在Tomcat的设计里，两者的「作用域」完全不同：

Common（通用）：作用域是「整个Tomcat容器」（包括Tomcat核心组件+所有Web应用）------是「容器级通用」；
Shared（共享） ：作用域是「所有Web应用」------是「应用级共享」，不包含Tomcat核心组件；

举个具体例子：

CommonClassLoader加载log4j-core.jar（Tomcat自身和所有应用都用这个日志包）；
SharedClassLoader加载commons-lang3.jar（所有应用共享这个工具包，但Tomcat核心代码不用）；
如果把Shared合并到Common，会导致：即使某个应用不需要commons-lang3.jar，Tomcat启动时也会加载它，浪费内存；且更新commons-lang3.jar时，会影响Tomcat核心的类加载（虽然不会崩溃，但增加了不必要的耦合）。

四、总结：三个加载器的设计逻辑

分层隔离：按「使用范围」拆分（容器全局→容器核心→应用共享），避免类的互相干扰和权限泄露；
语义区分：Common是「Tomcat+应用都能用」，Shared是「仅应用之间共享」，Catalina是「仅Tomcat核心用」，三者作用域边界清晰；
生命周期解耦：不同加载器加载的类，生命周期独立（更新应用共享类不影响Tomcat核心，更新Tomcat核心类不影响应用）；
资源优化：按需加载------Shared的类只在应用启动时加载，Common的类在Tomcat启动时加载，避免无用类占用内存。

简单来说，这三个加载器的设计，本质是Tomcat把「不同使用场景、不同权限、不同生命周期」的类，放到不同的「加载器容器」里，既保证共享（减少重复加载），又保证隔离（避免冲突和安全问题）。