深入理解JVM类加载机制：双亲委派模型与打破它的实战案例

“你学类加载机制的时候，是不是旁边总有人告诉你‘双亲委派就是爹先吃，爹不吃儿子再吃’，然后你点头如捣蒜，面试一考全忘光？”

很多后端开发者对类加载和双亲委派的认知，都停留在能背出“先委托父加载器，父加载器加载不了才自己加载”这短短一句话。可一旦遇到真正的场景——Tomcat怎么做到多个应用隔离的、JDBC的驱动到底是谁加载的、为什么你写了System.out.println(ClassLoader.getSystemClassLoader())打印出来的东西跟想象中不一样——就彻底懵了。这篇文章不整虚的，直接从JVM源码逻辑、实际字节码行为、以及JDBC、Tomcat这类真实框架的“破壁”案例出发，把“类加载机制”和“打破双亲委派”这两件事一次讲透。不管你是准备面试的候选人，还是正在排查ClassNotFoundException、NoSuchMethodError到怀疑人生的维护者，这篇文章都值得你逐字读完。

1. JVM从哪儿“进货”：一个看似平常却暗藏杀机的问题

1.1 类加载的本质：把字节码变成能用的对象

我们平时写的Java代码，javac编译完之后是一堆.class文件，里面只有字节码（bytecode）。如果JVM直接拿这一堆字节码去执行，效率低而且没法做各种高级优化，所以JVM引入了一个“加载、连接、初始化”的三段式过程。简单说：

• 加载（Loading）：把字节码读进来，生成一个java.lang.Class对象，挂在JVM的方法区里。这一步的核心执行者就是ClassLoader。
• 连接（Linking）：包括验证（Verification）、准备（Preparation）、解析（Resolution）。验证是检查字节码合法性，准备是为静态变量分配内存并设置默认值，解析是把符号引用替换成直接引用。
• 初始化（Initialization）：执行<clinit>方法，给静态变量赋真正的初始值，执行静态代码块。

很多人把“类加载机制”理解成了“加载一个类”，这是个严重的认知偏差。类加载机制是一个管道，从磁盘/网络/数据库/动态代理里拿到字节流，一路走完加载、连接、初始化，最终变成一个可以new出实例的Class对象。

这里有个特别容易被忽略的点：加载阶段是程序员唯一能通过自定义ClassLoader干预的阶段。验证、准备、解析、初始化这几步，JVM全权接管，你插不上手。所以谈到“打破双亲委派”，本质上的操作空间，全部集中在加载这一步。

1.2 三种“默认加载器”的真实分工

JVM内置了三个重要的ClassLoader，很多人背诵“Bootstrap / Extension / Application”，但实际到了JDK 9以后，这套体系已经悄悄变了。

• Bootstrap ClassLoader（启动类加载器）：负责加载<JAVA_HOME>/lib目录下，或者被-Xbootclasspath指定的类。注意，它不是Java对象，在HotSpot虚拟机里是C++写的，你在Java代码里甚至拿不到它的引用，打印出来是null。比如String、Object这些核心类，通通是它加载的。
• Platform ClassLoader（平台类加载器）：JDK 9模块化之后，原本的“Extension ClassLoader（扩展类加载器）”被改名成了这个。负责加载<JAVA_HOME>/lib/modules里的一些非核心模块，像java.sql、java.xml之类的API。
• App ClassLoader（应用类加载器）：负责加载classpath下你自己写的业务类，还有第三方依赖的jar包。平时我们用ClassLoader.getSystemClassLoader()拿到的就是它。

这里有个非常有迷惑性的点：很多人以为是“App ClassLoader的下级是Extension，再下级是Bootstrap”，实际上App ClassLoader和Platform ClassLoader是平级关系，它们共同的父加载器才是Bootstrap。什么意思？一会儿讲双亲委派流程的时候，你把这个平级关系带进去，才不会推错。

再补一个底层细节：ClassLoader类里有个parent字段，这个“父加载器”不是Java意义上的继承父类，而是一个组合关系。你可以把一个自定义加载器的parent指定成任意一个已有的ClassLoader实例，这就为“打破双亲委派”留下了第一个活口。

2. 双亲委派的原貌：三层加载器、一次向上“甩锅”的过程

2.1 标准的委派流程，到底绕了几个弯

先上结论性流程：当一个类加载器收到“加载某个类”的请求时，它不会自己先去加载，而是先把这个请求交给父加载器，父加载器又交给祖父加载器，一直传到顶层。顶层加载器发现自己加载不了，再一层层往回退，让子加载器尝试加载。

用“甩锅”来形容特别贴切：每个加载器都先问“爹，你能搞定吗？”，爹搞不定再问爷爷，爷爷也不行，最后才轮到自己上。

这里涉及到核心代码，我看过无数人背过，但真能读懂的没几个。ClassLoader里的loadClass(String name)，即Java的入口，它提供了一个模板：

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) { c = parent.loadClass(name, false); // 有爹就甩给爹 } else { c = findBootstrapClassOrNull(name); // 没爹就找“爷爷的爷爷” } } catch (ClassNotFoundException e) { // 爹也加载不了，那就算了，自己上 } if (c == null) { long t1 = System.nanoTime(); c = findClass(name); // 真正干活的地方 // ...记录日志 } } if (resolve) { resolveClass(c); } return c; } }

重点看三个方法：findLoadedClass、loadClass、findClass。默认的loadClass实现了双亲委派，而findClass是个空壳方法，专门留给子类去覆盖。标准的自定义类加载器套路是：只覆盖findClass，不碰loadClass。这样父加载器能加载的类不会被子类重复加载，父加载器加载不了的类，子类才有机会接手。这保证了全JVM范围内同一个类只会被同一个加载器加载一次，核心类库不会被随意替换。

2.2 为什么源码用synchronized包住整个加载流程

细心的读者可能已经看到了，loadClass方法一开始就synchronized (getClassLoadingLock(name))。这个锁不是可有可无的。

想象一下多线程场景：两个线程同时执行Class.forName("com.example.User")，如果没加锁，两个线程可能各自走一遍加载流程，生成两份Class对象，最后JVM里出现两个com.example.User，类型上完全不一致，强转直接ClassCastException，这种Bug极其诡异。

getClassLoadingLock这个方法是HotSpot里的一个套路，它返回什么取决于一个全局开关UseParallelLoading。默认情况下的具体实现是先到ClassLoader类自己的一个ParallelLockMap里查，有就复用锁，没有就新建一个。这样设计是为了平衡颗粒度：锁太粗（全局单锁）会导致所有类加载互相阻塞，锁太细（每个类一个锁）又浪费内存。

这个细节对“打破双亲委派”也很重要，因为一旦你自己重写了loadClass方法，就必须自己保证线程安全。很多人写破壁代码时把synchronized丢了，高并发下一会儿能加载成功一会儿失败，排查起来欲哭无泪。后面的实操环节会再强调。

2.3 全盘负责与缓存机制，是委派之外的隐性规则

双亲委派其实依赖两条隐性规则：

• 全盘负责：一个类加载器加载了A.class，那么A里所引用的其他类，默认也由同一个加载器负责。比如你的UserService里用到User，如果UserService是App ClassLoader加载的，那User大概率也是App ClassLoader去加载，而不是它的子加载器。
• 缓存机制：一个类被加载后，会长期存在ClassLoader内部的一个Vector（早期版本）或ConcurrentHashMap（现代版本）里。下次再要加载同名类，直接查缓存拿结果，不会再去磁盘扫一遍。

这两条规则和“打破双亲委派”是天然矛盾的。你一旦破了委派，就得自己处理“这个类的依赖类由谁来加载”的问题，不然就容易出现“主类加载成功了，结果内部引用java.util.HashMap都被你自定义加载器重新加载了一遍”的荒唐局面。后面章节里我会演示这个坑有多深。

3. 破壁的动机：面试题之外的强理由

3.1 Java SPI：一个“接口在顶层，实现在底层”的拧巴局面

很多人觉得“打破双亲委派”就是个面试造火箭的题目，实际上它背后藏着Java生态里一个非常现实的拧巴问题：SPI（Service Provider Interface）机制。

以java.sql.DriverManager为例。DriverManager这个类在JDK里，属于java.sql模块，由Bootstrap / Platform ClassLoader加载。但真正干活的MySQL驱动com.mysql.cj.jdbc.Driver，却躺在你项目的lib目录下，得由App ClassLoader加载。

问题来了：DriverManager初始化的时候要加载驱动实现类，可Bootstrap加载器不可能知道你的lib目录在哪，它根本加载不了MySQL驱动。按照双亲委派的逻辑，父加载器加载不了的类会往下传，但这有个前提——是“子加载器主动发起请求”才能触发向下传递。现在是顶层那帮“老爷类”要主动找底层的实现类，双亲委派这条路走不通了。

JDK的解法是Thread.currentThread().getContextClassLoader()——线程上下文类加载器。在DriverManager源码里，加载驱动实现类时用的不是自己的类加载器，而是当前线程上下文中“借”来的App ClassLoader。这等于在双亲委派的正统路线上开了一扇侧门，让父加载器可以“向下”借用子加载器的能力。这就是打破双亲委派的第一种常见姿势，后面我们用Tomcat再看到类似操作。

3.2 热部署与多版本共存：同一个类名，必须能加载两次

第二类强动机是热部署和版本隔离。生产环境里，你不可能每次改一行代码就重启整个JVM。像IDEA的JRebel、阿里开源的Arthas、各类RPC框架的热更新插件，底层都要求“同一个类名可以重新加载一份新字节码”。

但双亲委派有一个特性：一旦一个类被某个加载器加载过，就不会再加载第二遍。你改了代码，类名没变，加载器缓存里还是旧的那个，根本不会去读你新编译的class文件。所以热部署必须另起一个ClassLoader，让它加载新版本的类，旧的加载器连同旧类一起丢掉，实现“类替换”。

同理，很多中间件需要同时支持多个版本的同一个库。比如一个应用里既要跑旧版Netty又要跑新版Netty，双亲委派下“全盘负责”的规则会让你死得很惨——你依赖的框架里写死了io.netty:netty-all，一个JVM里只能有一个io.netty.channel.EventLoopGroup类定义。唯一的出路是自定义加载器，将不同版本的类路径隔离开。这也是OSGi和Java模块化系统（JPMS）想从根本上解决的问题。

3.3 安全隔离：让“不信任的代码”只能看到它该看的东西

第三类动机是安全隔离。如果你写的是一个插件系统，允许第三方上传代码运行，那你一定不希望插件里的代码能随意调用System.exit()、能访问宿主的内部类。

双亲委派模型默认情况下，插件类加载器的父加载器是App ClassLoader，插件代码可以通过Class.forName去加载任意classpath下的类，这等于打开了所有大门。如果打破双亲委派，让插件类加载器走一个独立的、无法向上回溯的加载路径，插件代码就只能看到特定的类，访问不了宿主应用的敏感对象。很多沙箱机制、Web容器隔离就是这么干的。

4. 动手实现：手写一个打破双亲委派的加载器

4.1 核心思想：重写loadClass，绕开父加载器的“先手权”

现在进入正题，实操一个最简单的破壁加载器。

先说思路。标准的loadClass流程是“先父后子”，打破双亲委派最简单的做法就是把这个顺序倒过来——先自己尝试加载，加载不了再交给父加载器。所谓“打破”并不是完全抛弃父加载器，而是剥夺它“先手”的机会。

来看代码。我们新建一个BreakParentClassLoader，继承java.lang.ClassLoader：

public class BreakParentClassLoader extends ClassLoader { private String classPath; public BreakParentClassLoader(String classPath) { // 注意：故意把 parent 传成 null，不继承 App ClassLoader // 但这里为了演示委派反转，我们还是把默认 parent 传进来 super(Thread.currentThread().getContextClassLoader()); this.classPath = classPath; } @Override protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { Class<?> c = findLoadedClass(name); if (c == null) { try { // 第一步：自己先尝试从指定目录加载 c = findClass(name); System.out.println("[BreakParentClassLoader] 自己加载了 " + name); } catch (ClassNotFoundException e) { // 第二步：自己搞不定，才丢给父加载器 c = super.loadClass(name, false); System.out.println("[BreakParentClassLoader] 交给父加载器加载 " + name); } } if (c == null) { throw new ClassNotFoundException(name); } if (resolve) { resolveClass(c); } return c; } } @Override protected Class<?> findClass(String name) throws ClassNotFoundException { String fileName = classPath + "/" + name.replace('.', '/') + ".class"; try { FileInputStream fis = new FileInputStream(fileName); ByteArrayOutputStream bos = new ByteArrayOutputStream(); byte[] buf = new byte[1024]; int len; while ((len = fis.read(buf)) != -1) { bos.write(buf, 0, len); } byte[] classBytes = bos.toByteArray(); // defineClass 是把字节码变成 Class 对象的唯一入口 return defineClass(name, classBytes, 0, classBytes.length); } catch (Exception e) { throw new ClassNotFoundException(name, e); } } }

这段代码有四个关键点值得单独展开：

• 重写了loadClass本身：不是只写findClass，而是把整个委派流程颠倒。这是“打破”模型和“标准自定义加载器”的最大区别。
• 先findClass后super.loadClass：顺序完全颠倒，所以叫“打破”。
• defineClass是唯一合法通道：任何加载器最终都要通过ClassLoader.defineClass这个方法把字节数组变成Class对象，你可以在字节码落地前做解密、做字节码增强。
• 同步锁别丢：前面讲过，并发加载同一个类会出大问题，这里用synchronized包住保证线程安全。

4.2 测试：亲手验证“同一个类，被两个加载器各加载一次”的后果

为了看出打破的效果，我们准备一个简单的类，把它放到两个不同的目录：

package demo; public class Hello { static { System.out.println("Hello 被初始化了，当前加载器：" + Hello.class.getClassLoader()); } public String say() { return "Hello from " + getClass().getClassLoader(); } }

编译之后，把Hello.class分别复制到/tmp/cl1/demo/和/tmp/cl2/demo/。然后写一个测试类：

public class TestBreakParent { public static void main(String[] args) throws Exception { BreakParentClassLoader cl1 = new BreakParentClassLoader("/tmp/cl1"); BreakParentClassLoader cl2 = new BreakParentClassLoader("/tmp/cl2"); Class<?> cls1 = cl1.loadClass("demo.Hello"); Class<?> cls2 = cl2.loadClass("demo.Hello"); System.out.println("cls1 == cls2 ? " + (cls1 == cls2)); System.out.println("cls1 classLoader: " + cls1.getClassLoader()); System.out.println("cls2 classLoader: " + cls2.getClassLoader()); Object obj1 = cls1.getDeclaredConstructor().newInstance(); Object obj2 = cls2.getDeclaredConstructor().newInstance(); // 强转会不会成功？答案是：ClassCastException！ try { demo.Hello h1 = (demo.Hello) obj1; } catch (ClassCastException e) { e.printStackTrace(); } } }

两个不同的加载器加载同一个类名，产生的Class对象不同，强转必抛异常。这其实正是热部署隔离的基础——为了让新版本替代旧版本，必须允许同名类以不同加载器身份同时存在，同时也要注意别在业务代码里跨加载器强转。

同样的道理，如果我们用标准双亲委派的加载器，上面代码的运行结果会是：cl1.loadClass("demo.Hello")的时候，父加载器发现demo.Hello已经在classpath里了，直接返回App ClassLoader加载的那份；第二次cl2.loadClass时，因为父加载器缓存里有同名类，也会直接返回同一份。两个Class完全相等，强转成功。这就是双亲委派“防止重复加载”的价值。

4.3 实操中必犯的经典错误：把parent传成null就万事大吉？

我第一次写破壁加载器时，觉得“全面打破”就得把父加载器置空，于是写了super(null)。结果发现几乎所有JDK核心类在我自己的加载器里都尝试加载，然后报出一堆ClassNotFoundException。

为什么？因为我的loadClass是“先自己上，不行再找爹”，而我把爹设成了null。当它尝试加载java.lang.String时，findClass("/tmp/cl1/java/lang/String.class")找不到——这没问题，但接下来找爹的时候，爹是null，直接抛异常。这等于把JDK整个核心类库的加载路径给掐断了。

标准做法是：打破双亲委派，不等于抛弃父加载器。正确的姿势是“先查缓存→自己尝试→不行再委派给父加载器”，始终保留父加载器作为兜底。JDK核心类一定得让Bootstrap加载器去加载，否则JVM直接崩。

另外还有一个坑：有些人在findClass里自己去读字节码时，没有对IOException做正确处理，导致找不到类时抛的不是ClassNotFoundException，而是一个莫名其妙的FileNotFoundException。JVM的委派机制是靠捕获ClassNotFoundException来触发“找父加载器”的路径的，如果你抛的是别的异常，父加载器那一层根本接不住，整个加载流程直接中断。这是一个非常隐蔽的Bug。

5. 现实世界的破壁者：JDBC、Tomcat、热部署

5.1 Tomcat的WebAppClassLoader：既是隔离，也是破坏

Tomcat是最典型的“打破双亲委派”案例。一个Tomcat容器里可以部署十几个Web应用，每个应用都有自己的lib依赖。如果采用标准的双亲委派，多个应用之间会出现两个致命问题：

1. 应用A引用了spring-core-5.x，应用B引用了spring-core-4.x，两个版本冲突，类加载器只能加载其中一份。
2. 应用A和B互不信任，但通过双亲委派，A的代码可以加载到B的classpath下的类，等于隔离被打破。

Tomcat的解法是为每个Web应用创建一个WebappClassLoader，它的加载策略被设计成：先从自己的/WEB-INF/classes目录加载，再从/WEB-INF/lib下的jar加载，这两步搞不定，才丢给父加载器去加载。Java核心类库从JDK里加载，但Web应用自身的类和依赖，优先从自己应用内加载。这样一来，不同应用的同名类互不干扰，真正实现了应用级隔离。

Tomcat还做了另一个精细操作：用父加载器去加载JSP文件对应的类，但JSP编译也适度委派，因为它要保证JSP能访问到Servlet API等Tomcat提供的类，同时避免JSP和容器之间的类冲突。这就是为什么你在Tomcat里自定义类加载器时，经常会看到它同时处理“目录加载”和“jar加载”两条路径。

5.2 JDBC驱动加载：线程上下文类加载器的精妙之处

再回到JDBC。我们平时写Class.forName("com.mysql.cj.jdbc.Driver")或直接用DriverManager.getConnection，很多人不明白为什么还需要一个上下文类加载器出来兜底。

咱们一步一步看DriverManager的源码关键节点。DriverManager在静态初始化时执行：

static { loadInitialDrivers(); }

loadInitialDrivers内部会去读META-INF/services/java.sql.Driver这个SPI文件，拿到所有驱动的实现类名，然后执行：

Class<?> driverClass = Class.forName(driverName, true, classLoader);

这里的classLoader不是DriverManager自己的类加载器，而是：

ClassLoader classLoader = Thread.currentThread().getContextClassLoader();

也就是说，JDK核心类库里想加载“业务侧”的驱动实现，走了“线程上下文”的捷径。线程上下文类加载器本质上是一个可以动态设置的属性，父类加载器用它可以“反向”调用子类加载器的能力。这不算真正意义上的“打破双亲委派”，而是“绕过”委派，所以严格来说JDBC的SPI是旁路突破。

类似的还有java.util.ServiceLoader，Spring Boot的spring.factories加载机制，本质上用的都是SPI + 线程上下文类加载器。

5.3 热部署框架：销毁加载器，重建加载器，类就换新了

热部署最核心的原理是“类加载器交换”。以IDEA的HotSwap为例，它的行为分两级：

• 第一次修改：JVM自带的HotSwap能力可以直接用调试模式替换方法体，不改变类结构，不需要重开加载器。
• 结构性修改（增加字段/方法、改变继承关系）：JVM自身HotSwap做不了，框架会新建一个ClassLoader去加载新版本的类。

热部署框架（比如Arthas的redefine命令、JRebel）的实际操作是：新类加载器的父加载器指向旧的App ClassLoader，但加载同名类时，它直接走自己的资源路径（通常是新编译好的class文件目录）。加载完成后，框架会通过Instrumentation的redefineClasses把JVM里已存在的类替换掉。之所以能替换成功，是因为redefineClasses不要求类加载器换新，它只要求新旧类的类名一致、方法签名兼容。

这里有个热部署的实现细节：如果你没有框架帮忙，想自己实现“热加载新类”，那么做完新加载器后，还需要注意旧类实例还存活在内存里。你new出来的对象是旧类的实例，它的方法执行还是旧逻辑。要实现真正的“热替换”，不只是换个加载器那么简单，还得有代理层/门面层去转发。

6. 踩坑复盘：打破委派容易，打破之后不乱才难

6.1 NoSuchMethodError、LinkageError、ClassCastException：三兄弟的辨别套路

打破委派之后，最常遇到的问题就是LinkageError家族三兄弟：NoSuchMethodError、NoClassDefFoundError、ClassCastException。很多人分不清它们的区别，我把自己的排查套路整理出来：

• ClassCastException：几乎可以断定是“同一个类被两个加载器各加载了一次”，强转时JVM会检查两个Class对象是否属于同一个加载器定义，不一致直接抛出来。排查方向：打印对象的getClass().getClassLoader()，看它到底是谁加载的。
• NoClassDefFoundError：类加载时，类的静态初始化引用的其他类找不到。通常在“主类加载成功，依赖类加载失败”时出现。重点查全盘负责规则有没有被破坏，尤其注意getResourceAsStream拿配置文件的路径。
• NoSuchMethodError：新版方法没找到，多数是同一jar包被加载了两份不同版本。和你打破委派后的类路径顺序有直接关系。

排查这三兄弟，基本思路是：先确定目标类实际由哪个加载器加载，再检查加载路径，再看ClassLoader的父链是否如你所想。

6.2 线程上下文类加载器的一个隐蔽陷阱

线程上下文类加载器（Thread.currentThread().getContextClassLoader()）是Java生态中一个“全局可变”的状态。它由Thread.setContextClassLoader()方法设置，但这个设置行为不随线程池复用自动清理。

举个典型的线上事故：一个业务线程在进入某个框架时，框架把线程上下文类加载器设置成了WebappClassLoader，处理完业务后没恢复。线程回到线程池，下个任务拿到这个线程，发现上下文类加载器还是上个Web应用的，直接用它去加载SPI类，结果加载了错误版本的实现类。排查极难，因为事故现场“毫无规律”，一会儿好一会儿坏，完全取决于线程池复用了哪根线程。

破局的方法也很简单：使用线程上下文类加载器的地方，一定要在finally里恢复原上下文：

ClassLoader original = Thread.currentThread().getContextClassLoader(); try { Thread.currentThread().setContextClassLoader(targetLoader); // 业务逻辑 } finally { Thread.currentThread().setContextClassLoader(original); }

这个习惯我是在被线上事故毒打之后才养成的，写在这里希望能帮看到这篇文章的人提前避雷。

6.3 自定义加载器与Class.forName的“双加载”陷阱

还有一个高频Bug：自定义加载器加载了一个类，然后业务代码里又用Class.forName("com.example.Demo")去加载同一个类。这里要说清楚，Class.forName默认用的是调用方的类加载器，如果调用方是由App ClassLoader加载的，那它会找到App ClassLoader缓存的旧类，而不是你新加载器加载的新类。

这种“同一个类，两种引用”的问题在多模块项目里极其常见。Spring的ClassUtils.forName、MyBatis的Resources.classForName本质上都绕不过这个逻辑。如果你希望整个链路都用自定义加载器，必须保证所有Class.forName调用都显式传入同一个类加载器，或者把自定义加载器设置为线程上下文加载器。

6.4 给你一份自检清单

如果打算在项目里引入“打破双亲委派”的代码，以下自检项是我反复踩坑后的经验汇总，建议对照排查：

以上每一条，都是我实际写破壁代码时被坑出来的经验。打破双亲委派，本质上是在告诉JVM“我比你更懂类从哪里来”，你用这个权力之前，必须想清楚后果。

写到这里，“类加载机制”和“如何打破双亲委派”这两个话题，算是从抽象原理到实际场景都串了一遍。我个人最大的体会是：双亲委派不是一条死规则，它是一条有明确边界的工程惯例。JVM官方在JDBC SPI里自己就带头“绕过”了它，Tomcat在隔离场景里也堂而皇之地“逆转”了它。真正的高手，不是能背出模型，而是知道自己写的每一行加载逻辑到底放弃了什么安全性、换来了什么灵活性。下次面试官再问到“如何打破双亲委派”，你可以不只是回答“重写loadClass”了，而是把Tomcat、JDBC、热部署、线程上下文加载器、LinkageError这些真实世界的连锁反应一并讲给他听。