类加载是JVM将.class字节码转化为可执行运行时对象的动态过程，核心在于按需加载、分阶段处理、双亲委派与安全隔离；涵盖加载→验证→准备→解析→初始化五阶段（顺序开始、交叉执行），强调双亲委派的安全价值（避免重复加载、防止核心类篡改、支撑框架隔离），并体现动态性、唯一性、可扩展性及与SPI、Tomcat等实际场景的深度关联。
面试中讲类加载机制，重点不是背流程，而是说清逻辑、抓住关键点、体现理解深度。一句话概括：类加载是 JVM 把 .class 字节码变成可执行运行时对象的动态过程，核心在于按需加载、分阶段处理、双亲委派、安全隔离。
说清楚生命周期五阶段（加载→验证→准备→解析→初始化）
这五个阶段是类加载的主线，但要注意它们不是严格串行，而是“按顺序开始、交叉混合执行”：
-
加载：找到字节码（可来自文件、jar、网络、动态生成），转成方法区运行时结构，并在堆中创建
java.lang.Class实例——这是后续所有反射和类型操作的入口； -
验证：四层校验（文件格式、元数据、字节码、符号引用），确保不破坏 JVM 安全；生产环境可考虑用
-Xverify:none略过部分验证提速，但需权衡风险； -
准备：只给类变量（static 变量）分配内存并设默认值（如
int a = 123;此时 a=0），final static 常量例外，会直接赋值为 123； - 解析：把常量池里的符号引用（比如类名、方法名）替换成内存中的具体地址（直接引用）；它可延迟到初始化后，支撑多态和动态绑定；
-
初始化：真正执行 Java 代码——运行
<clinit>()方法，按源码顺序赋值静态变量、执行静态块；父类优先于子类初始化，接口则不强制先初始化其父接口。
讲透双亲委派模型及其作用
这不是一个设计选择，而是 JVM 的安全基石：
- 每个类加载器收到请求时，先委托父加载器尝试加载；只有父加载器无法加载（返回 null），才自己查找；
- 从底向上是：启动类加载器（C++，加载 rt.jar）→ 扩展类加载器（jre/lib/ext）→ 应用类加载器（classpath）→ 自定义加载器；
- 核心价值有三点：
✓ 避免重复加载（同一类由同一加载器加载，保证 Class 对象唯一）；
✓ 防止核心类被篡改（比如你写个java.lang.String，应用类加载器不会加载，启动类加载器已加载且受保护）；
✓ 支撑框架能力（Spring 的组件扫描、Tomcat 的 WebApp 隔离、SPI 服务发现都依赖该模型的类可见性与隔离性）。
点明关键特性与实际意义
面试官想听你跳出流程，看到机制背后的设计意图：
立即学习“Java免费学习笔记（深入）”；
- 动态性：类不是启动时全加载，而是首次主动使用（如 new、调用静态方法、反射等）才触发，降低内存占用、加快启动；
- 唯一性：同一个全限定名 + 同一个类加载器 = 唯一 Class 对象；不同加载器加载的相同类，在 JVM 中视为不同类型（这就是热部署、OSGi、模块化隔离的基础）；
-
可扩展性：通过继承
ClassLoader并重写findClass()，就能实现加密加载、网络拉取、热替换、插件化等高级场景； -
与框架强耦合：Spring 的 @Component 扫描靠类加载器定位 classpath 下的类；MyBatis Mapper 接口代理类由自定义加载器动态生成；JDBC 的
DriverManager通过 SPI + 线程上下文类加载器（TCCL）加载驱动，绕过双亲委派限制。
补充一个高频追问点：什么时候打破双亲委派？怎么破？
典型场景有两个：
-
SPI 机制（如 JDBC）：标准接口（
java.sql.Driver）由启动类加载器加载，但具体实现（MySQL Driver）在应用 classpath 下，必须由应用类加载器加载——这时用Thread.currentThread().getContextClassLoader()获取应用加载器来加载，属于“父委托子”反向调用； - 热部署/模块化容器（如 Tomcat、OSGi）：每个 WebApp 或 Bundle 需要独立的类空间，避免冲突，所以自定义加载器会优先自己加载，找不到再委托父——即“先子后父”，覆盖默认委派逻辑。
