类加载三阶段为加载、链接、初始化：加载读取字节码生成Class对象；链接含验证、准备、解析，校验并分配静态字段内存；初始化执行方法。
类加载的三个阶段到底在干什么
Java 类加载不是一气呵成的操作，而是严格分三步：加载（Loading）、链接（Linking）、初始化（Initialization）。这三步不可跳过、不可逆序，且每步失败都会抛出不同异常——比如 NoClassDefFoundError 多半卡在链接，而 ExceptionInInitializerError 一定发生在初始化阶段。
加载阶段只负责把字节码搞进来，不校验、不解析、不执行；链接才开始验证格式、准备静态字段内存、解析符号引用；初始化才是真正执行 <clinit></clinit> 方法（即静态块和静态变量赋值）的时候。
- 加载：从
ClassLoader.getResourceAsStream()或文件系统读取.class字节流，生成java.lang.Class对象 - 链接：包含验证（Verification）、准备（Preparation）、解析（Resolution）三个子阶段，其中解析可能延迟到首次主动使用时才做（称为“被动引用不触发解析”）
- 初始化：仅当首次主动使用该类时触发，比如 new 实例、调用静态方法、反射访问、子类初始化导致父类初始化等
为什么 static final 常量不会触发类初始化
因为编译期就内联了。只要 static final 的值是编译期常量（如 int、String 字面量），Javac 会直接把它的值复制到所有引用处，运行时根本不需要加载这个类。
反例：static final int X = Math.min(1, 2) 不算编译期常量，它会在运行时计算，所以访问 X 会触发类初始化；同理 static final String S = new String("a") 也不会内联。
立即学习“Java免费学习笔记（深入）”；
- 常见误判：以为所有
static final都不触发初始化，其实只看是否满足“编译期常量”定义 - 调试技巧：加
-XX:+TraceClassLoading启动参数，观察类何时被真正加载 - 影响：若类初始化里有副作用（如注册监听、改全局状态），而你依赖
static final访问却没触发它，逻辑就悄悄漏掉了
双亲委派被破坏的典型场景和风险
标准双亲委派要求子加载器先委托父加载器尝试加载，但现实中至少三处明确打破了它：SPI 机制（ServiceLoader）、热部署（OSGi / Tomcat）、以及 JDBC 驱动注册（DriverManager 要求用线程上下文类加载器）。
最危险的是自己重写 loadClass() 却忘了调用 super.loadClass()，结果 java.lang.String 这类核心类可能被你的类加载器重复加载，造成 ClassCastException——哪怕两个类名、字节码完全一样，只要加载器不同，JVM 就视为不同类。
- Tomcat 打破委派：每个 WebApp 用独立
WebAppClassLoader，优先加载自己WEB-INF/lib下的类，避免应用间冲突 - 自定义加载器陷阱：覆盖
findClass()是安全的，但覆盖loadClass()必须显式委托，否则破坏类型一致性 - 调试线索：遇到奇怪的
ClassNotFoundException或LinkageError，先查ClassLoader.getSystemClassLoader().getParent()链路是否完整
类卸载几乎不可能，但可以被 GC 回收的条件
类本身能被卸载的前提极其苛刻：该类的所有实例都被回收 + 加载该类的 ClassLoader 实例也被回收 + 该类的 java.lang.Class 对象没有被任何地方引用。现实中，只要类加载器还活着（比如 Spring 的 ApplicationContext 持有它），类就永远驻留内存。
这也是为什么热部署失败后内存泄漏频发——旧的 ClassLoader 没被回收，它加载的所有类（包括 Spring Bean、日志配置、甚至 Lambda 生成的类）全跟着留在老年代。
- 检查手段：用
jmap -histo:live <pid></pid>看java.lang.Class和ClassLoader实例数是否持续增长 - 关键点：类卸载不是“类自己决定”，而是取决于它的加载器能否被 GC，这点和对象回收逻辑完全不同
- 容易忽略：匿名内部类、Lambda 表达式、动态生成类（如 CGLIB）都会隐式绑定到当前类加载器，它们比你写的业务类更难清理
