Java类加载机制是什么 Java双亲委派模型【原理】

Java类加载机制是按需懒加载.class文件并生成Class对象的过程，采用双亲委派模型：启动类加载器（C++实现）、扩展类加载器、应用程序类加载器构成父子委派链，确保核心类不被篡改、避免重复加载、保障类唯一性；可自定义加载器或在Tomcat、SPI等场景破坏委派。

Java类加载机制，本质是把.class字节码文件读入JVM内存，并生成对应的java.lang.Class对象的过程。它不是一次性全量加载，而是按需懒加载——只有在首次使用（如new对象、调用静态方法、反射获取Class等）时才触发。

类加载器的三层结构

JVM自带三类核心类加载器，构成逻辑上的父子委派链（非Java继承关系）：

• 启动类加载器（Bootstrap ClassLoader）：C++实现，加载JAVA_HOME/jre/lib下的核心类（如rt.jar中的java.lang.Object），Java代码中不可见（返回null）
• 扩展类加载器（Extension ClassLoader）：加载JAVA_HOME/jre/lib/ext目录下的扩展jar，父加载器是Bootstrap
• 应用程序类加载器（Application ClassLoader）：也叫系统类加载器，加载classpath路径下的用户类，父加载器是Extension

你还可以继承java.lang.ClassLoader写自定义加载器，用于从网络、数据库或加密包中加载类。

双亲委派模型的核心流程

当某个类加载器收到加载请求（比如AppClassLoader要加载com.example.User），它不直接动手，而是按以下顺序执行：

• 先检查自己是否已加载过该类（缓存命中则直接返回）
• 没加载过，就委托给父加载器（loadClass()调用父类的同名方法）
• 一路向上，直到Bootstrap；若Bootstrap也无法加载（比如找不到com.example.User），就逐级向下回退
• 最终由最初发起请求的加载器（如AppClassLoader）真正去读取字节码、解析并定义类

整个过程像“先请示、再动手”，不是所有加载器都平等竞争，而是有明确优先级。

为什么必须用双亲委派？

它解决三个关键问题：

• 防止核心类被篡改：比如你自己写了java.lang.String，双亲委派会让Bootstrap先尝试加载——它早就在rt.jar里加载过了，所以你的版本根本不会被用上
• 避免重复加载：同一个类（相同全限定名 + 相同加载器）只被加载一次，不同加载器加载的同名类也被视为不同类（ClassA != ClassB），保证类型安全
• 保障类的唯一性与一致性：所有java.*类都由Bootstrap加载，所有javax.*扩展类由Extension加载，应用类由A

  

  pp加载——层级即信任等级

什么时候会破坏双亲委派？

标准机制很健壮，但某些场景需要绕过它：

• Tomcat等Web容器：每个Web应用有自己的类加载器，优先加载WEB-INF/classes和lib，而不是委派给AppClassLoader，避免应用间类冲突
• SPI服务加载（如JDBC）：用线程上下文类加载器（Thread.currentThread().getContextClassLoader()）反向委托，让Bootstrap能加载到应用提供的Driver实现
• 热部署/插件化系统：如JVM-Sandbox、OSGi，通过自定义loadClass()逻辑实现隔离与动态替换

破坏的前提是清楚后果——比如绕过委派后，要自行处理类可见性、资源隔离和内存泄漏风险。

基本上就这些。理解双亲委派，关键不在背流程，而在明白它用“层级+缓存+委派”换来了安全、稳定和可预测——不是设计得复杂，而是不敢简单。