Java类加载是分阶段按需触发的懒加载机制，分为加载、验证、准备、解析、初始化五阶段；初始化仅在首次主动使用类时执行，final static常量编译期内联，双亲委派是委托而非继承，类唯一性由“类名+ClassLoader实例”共同决定。
类加载不是“一锤子买卖”，而是分阶段按需触发
Java 类加载机制的本质，是 JVM 在真正需要使用某个类时，才逐步完成从字节码到可执行类型的转化。它不发生在编译期，也不在启动时全量加载——而是懒加载（lazy loading）。比如 Class.forName("com.example.User") 会触发完整加载+验证+准备+解析+初始化；而 ClassLoader.loadClass("com.example.User") 默认只做到解析前，不执行 （即静态块和静态变量赋值）。
- 常见错误现象：调用
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 变量的“零值”和“真值”差着一个
在准备阶段，JVM 仅为 static 变量分配内存并设“零值”（int→0、Object→null），哪怕代码里写了 public static int PORT = 8080 —— 这个 8080 是在初始化阶段，由编译生成的 方法执行时才真正写入的。
