Java类加载本质是将.class文件二进制数据转化为Class对象的过程，分为加载、验证、准备、解析、初始化五阶段，遵循双亲委派模型以保障安全，且按需懒加载。
Java 类加载机制的本质，是把磁盘上的 .class 文件二进制数据变成 JVM 能直接操作的 java.lang.Class 对象的过程；ClassLoader 就是干这件事的执行者——它不是“一次性加载全部类”，而是按需触发、分阶段转化、带安全校验的懒加载流水线。
类加载五阶段到底在做什么？
加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）这五个阶段顺序固定，但执行常交叉。关键不是背顺序，而是知道每步谁在动、动了什么：
-
加载：由ClassLoader子类（如AppClassLoader）完成，核心是调用findClass(String name)获取字节流，再用defineClass(byte[] b)注入 JVM 内存（方法区/元空间），最后在堆里 new 出一个Class对象； -
验证：JVM 自己做，检查魔数、版本号、符号引用合法性等，防止恶意字节码崩溃虚拟机； -
准备：为static变量分配内存并设默认值（如int设为0，不是你代码里写的5）； -
解析：把常量池里的符号引用（比如"java/lang/Object"）替换成内存中真实地址（直接引用），可能延迟到初始化后，以支持动态绑定； -
初始化：真正执行() static{}块，且 JVM 保证多线程下只执行一次。
双亲委派模型不是设计选择，而是安全刚需
当你调用 cl.loadClass("java.util.ArrayList")，实际走的是：AppClassLoader → ExtClassLoader → BootstrapClassLoader 逐级委托。这不是为了“优雅”，而是防止你写个假的 java.lang.String 替换掉真正的核心类：
- Bootstrap 加载
rt.jar（JDK 8）或modules（JDK 9+）里的java.*类，用 C++ 实现，没有 Java 父类； - ExtClassLoader 加载
$JAVA_HOME/lib/ext下的扩展包（已逐步淘汰）； - AppClassLoader（即
sun.misc.Launcher$AppClassLoader）加载-cp或CLASSPATH下的应用类； - 自定义加载器必须显式调用
super(parent)，否则会断掉委派链，容易引发NoClassDefFoundError或LinkageError。
什么时候类真的被加载？别被“编译通过”骗了
类加载是“被动触发”的——哪怕你写了 new MyClass()，只要这行代码没被执行，MyClass 就不会加载。常见主动触发点：
立即学习“Java免费学习笔记（深入）”；
- 执行
new实例化（首次）； - 访问非
final static字段或调用静态方法（MyClass.field或MyClass.method()）； - 反射调用
Class.forName("xxx")（注意：Class.forName("xxx", false, cl)第二个参数为false时跳过初始化）； - JVM 启动时加载含
main方法的主类； - 子类初始化前，父类必须先初始化（但仅限“首次主动使用子类”时才触发父类初始化）。
陷阱示例：System.out.println(MyClass.CONSTANT) 不会加载 MyClass，因为 CONSTANT 是 public static final 编译期常量，已被内联进调用方字节码。
自定义 ClassLoader 的典型场景与雷区
绕过双亲委派（重写 loadClass 而不调用 super.loadClass）只应在明确需要隔离或热替换时使用，比如插件系统、OSGi、JSP 容器或热部署工具：
public class MyClassLoader extends ClassLoader {
private final String baseDir;
public MyClassLoader(String baseDir, ClassLoader parent) {
super(parent); // 必须传 parent，否则无法访问系统类
this.baseDir = baseDir;
}
@Override
protected Class findClass(String name) throws ClassNotFoundException {
byte[] bytes = loadClassBytes(name); // 自己读 .class 文件
return defineClass(name, bytes, 0, bytes.length);
}
}
容易踩的坑：
- 忘记调用
super(parent)导致java.lang.*类找不到； - 重复定义同一个类名（不同加载器）→ 生成不兼容的
Class对象，强制转型会抛ClassCastException； - 未正确实现资源查找（
getResource/getResources），导致Properties、配置文件、SPI 服务加载失败； - 类卸载困难：只有整个
ClassLoader实例不可达，且其加载的所有类对象都无引用时，JVM 才可能回收元空间中的类元数据（JDK 8+）。
真正难的从来不是“怎么写一个加载器”，而是想清楚：这个类该不该由当前加载器负责？它依赖的其他类是否能被同一层级访问到？一旦打破委派，整个类可见性边界就变了。
