Java类加载是分阶段按需触发的懒加载机制，分为加载、验证、准备、解析、初始化五阶段；初始化仅在首次主动使用类时执行，final static常量编译期内联，双亲委派是委托而非继承，类唯一性由“类名+ClassLoader实例”共同决定。
类加载不是“一锤子买卖”，而是分阶段按需触发
Java 类加载机制的本质，是 JVM 在真正需要使用某个类时，才逐步完成从字节码到可执行类型的转化。它不发生在编译期，也不在启动时全量加载——而是懒加载（lazy loading）。比如 Class.forName("com.example.User") 会触发完整加载+验证+准备+解析+初始化；而 ClassLoader.loadClass("com.example.User") 默认只做到解析前，不执行 <clinit></clinit>（即静态块和静态变量赋值）。
- 常见错误现象：调用
loadClass后发现静态字段还是默认值、静态块没执行——不是 bug，是设计如此 - 初始化时机很关键：只有当首次主动使用类（
new、读写静态字段、调用静态方法、反射forName带initialize=true）才会走到初始化阶段 - 注意
final static常量是例外：编译期就内联进调用处，连类都不用加载（如Integer.MAX_VALUE）
双亲委派不是继承，是委托链上的“先问长辈再自己干”
每个 ClassLoader 实例都有一个父加载器（getParent()），但这个“父子”关系不是 Java 的 extends 继承，而是构造时显式传入或由 JVM 自动设置的委托引用。加载类时，loadClass 方法默认先调用父类的 loadClass，层层向上，直到 Bootstrap（C++ 实现，无 parent，返回 null）。
- 为什么不能随便重写
loadClass？破坏委派会导致java.lang.String被你自己的类加载器重复加载，产生两个不兼容的Class对象，引发LinkageError - 正确扩展方式：只重写
findClass(String name)，在里面读取字节流并调用defineClass；把委托逻辑留给父类 - 典型破例场景：OSGi、Tomcat、JDBC 的
DriverManager（需线程上下文类加载器打破委派）
准备阶段 ≠ 初始化，static 变量的“零值”和“真值”差着一个 <clinit></clinit>
在准备阶段，JVM 仅为 static 变量分配内存并设“零值”（int→0、Object→null），哪怕代码里写了 public static int PORT = 8080 —— 这个 8080 是在初始化阶段，由编译生成的 <clinit></clinit> 方法执行时才真正写入的。
-
public static final int VERSION = 1;是特例：编译期放入常量池，准备阶段直接赋值，不依赖<clinit></clinit> - 验证手段：用
javap -c看字节码，能找到<clinit></clinit>方法体里包含putstatic指令 - 容易踩的坑：在类加载早期（如自定义 ClassLoader 的
findClass中）试图读取尚未初始化的 static 字段，得到的是零值而非预期值
类是否相同，看的是“类名 + 加载它的 ClassLoader”两个条件
同一个 .class 文件被两个不同 ClassLoader 实例加载，会产生两个互不兼容的 Class 对象。它们的 getClassLoader() 不同，== 和 equals() 都返回 false，强制转型会抛 ClassCastException。
立即学习“Java免费学习笔记（深入）”；
- 典型问题场景：Web 应用热部署、插件系统、自定义加密类加载器未隔离 ClassLoader 实例
- 排查技巧：打印
obj.getClass().getClassLoader()和Class.forName("X").getClassLoader()对比是否一致 - 关键提醒：即使你确保字节码完全一样，只要 ClassLoader 实例不同，JVM 就认为是两个不同的类——这是安全模型的基石，不是 bug
NoClassDefFoundError 或 IllegalAccessError，而不是直观的 ClassNotFoundException。 
