Java双亲委派模型原理与安全机制解析

文章不知道大家是否熟悉？今天我将给大家介绍《Java双亲委派模型详解与安全机制解析》，这篇文章主要会讲到等等知识点，如果你在看完本篇文章后，有更好的建议或者发现哪里有问题，希望大家都能积极评论指出，谢谢！希望我们能一起加油进步！

双亲委派是类加载的向上委托责任链机制：AppClassLoader先委托ExtClassLoader，再委托BootstrapClassLoader，仅当顶层失败才自救加载；其核心在loadClass()三步逻辑，且打破需重写loadClass()而非仅findClass()。

双亲委派不是“父母双亲”，而是“向上委托”的加载规则

双亲委派模型本质是一条类加载的「责任链」：当 AppClassLoader 收到加载 com.example.User 的请求时，它不会立刻去 classpath 查，而是先调用 parent.loadClass() 把请求甩给 ExtClassLoader；后者再甩给 BootstrapClassLoader；只有顶层加载器在 $JAVA_HOME/jre/lib/rt.jar 里找不到，请求才一级级退回，最终由应用类加载器自己调用 findClass() 去磁盘加载。

这个机制不是靠继承实现的——BootstrapClassLoader 是 C++ 实现、没有 Java 对象，ExtClassLoader 和 AppClassLoader 虽然继承自 URLClassLoader，但父子关系靠的是构造时传入的 parent 引用，不是 extends 关系。

为什么必须有这层委托？三个现实问题逼出来的

不走双亲委派，JVM 立刻出事：

• 安全崩塌：你写个 java.lang.String 类，放在 lib/ 下，若应用类加载器直接加载，就覆盖了 JVM 自带的 String——所有 equals()、hashCode() 都可能被篡改，System、ClassLoader 等核心类同理
• ClassCastException 频发：两个不同加载器（比如 Tomcat 的两个 WebApp）各自加载了同一个 org.apache.commons.lang3.StringUtils，JVM 视为两个完全无关的类，哪怕字节码一模一样，强制转型就会抛异常
• 内存浪费+启动变慢：每个类加载器都重复加载 java.util.ArrayList，元空间里堆一堆相同类，GC 压力大，类初始化逻辑还可能执行多次

loadClass() 方法里藏着整个模型的开关

真正实现双亲委派的是 ClassLoader.loadClass(String, boolean) 的默认逻辑。它的关键分支就三步：

• 先查缓存：findLoadedClass(name) —— 已加载过直接返回，避免重复加载
• 再委派父类：if (parent != null) parent.loadClass(name, false)；父为 null 时调用 findBootstrapClassOrNull(name)（底层 native 方法）
• 最后自救：c == null 且父全部失败 → 调用 findClass(name)，这个方法是空的，**必须由子类重写**才能真正从文件/网络/数据库读取字节码

注意：findClass() 不做委派，只负责“找字节码”；而 defineClass() 才是把字节码转成 Class 对象的临门一脚。很多自定义加载器漏掉 defineClass()，结果字节码读到了却没变成类，报 NoClassDefFoundError。

打破双亲委派不是“破坏”，而是解决特定场景的刚需

Tomcat、OSGi、JDBC 驱动加载都在主动绕开它：

• JDBC 4.0+：ServiceLoader.load(Driver.class) 用线程上下文类加载器（Thread.currentThread().getContextClassLoader()）去加载 META-INF/services/java.sql.Driver，否则 BootstrapClassLoader 根本看不见你 mysql-connector-java.jar 里的实现类
• Web 容器隔离：Tomcat 为每个 WebApp 创建独立的 WebAppClassLoader，并**重写 loadClass()，先自己 findClass()，失败再委派父类**——这样就能让两个 App 各自用不同版本的 Spring，互不干扰
• 热更新/插件化：每次重新加载插件时 new 一个新类加载器，旧类加载器连同它加载的所有类可被 GC，避免内存泄漏；但要注意静态字段、线程局部变量、JNI 资源等残留引用

真正容易踩的坑是：以为重写了 findClass() 就算打破委派，其实没动 loadClass()，请求照样先往上跑；或者打破后忘了清理类加载器引用，导致 PermGen / Metaspace 溢出。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~