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），它不直接动手，而是按以下顺序执行：
立即学习“Java免费学习笔记（深入）”；
- 先检查自己是否已加载过该类（缓存命中则直接返回）
- 没加载过，就委托给父加载器（
loadClass()调用父类的同名方法） - 一路向上，直到Bootstrap；若Bootstrap也无法加载（比如找不到
com.example.User），就逐级向下回退 - 最终由最初发起请求的加载器（如AppClassLoader）真正去读取字节码、解析并定义类
整个过程像“先请示、再动手”，不是所有加载器都平等竞争，而是有明确优先级。
为什么必须用双亲委派？
它解决三个关键问题：
-
防止核心类被篡改：比如你自己写了
java.lang.String，双亲委派会让Bootstrap先尝试加载——它早就在rt.jar里加载过了，所以你的版本根本不会被用上 -
避免重复加载：同一个类（相同全限定名 + 相同加载器）只被加载一次，不同加载器加载的同名类也被视为不同类（
ClassA != ClassB），保证类型安全 -
保障类的唯一性与一致性：所有
java.*类都由Bootstrap加载，所有javax.*扩展类由Extension加载，应用类由App加载——层级即信任等级
什么时候会破坏双亲委派？
标准机制很健壮，但某些场景需要绕过它：
-
Tomcat等Web容器：每个Web应用有自己的类加载器，优先加载
WEB-INF/classes和lib，而不是委派给AppClassLoader，避免应用间类冲突 -
SPI服务加载（如JDBC）：用线程上下文类加载器（
Thread.currentThread().getContextClassLoader()）反向委托，让Bootstrap能加载到应用提供的Driver实现 -
热部署/插件化系统：如JVM-Sandbox、OSGi，通过自定义
loadClass()逻辑实现隔离与动态替换
破坏的前提是清楚后果——比如绕过委派后，要自行处理类可见性、资源隔离和内存泄漏风险。
基本上就这些。理解双亲委派，关键不在背流程，而在明白它用“层级+缓存+委派”换来了安全、稳定和可预测——不是设计得复杂，而是不敢简单。
