Java类加载机制核心是“谁加载、何时加载、怎么加载、如何验证、能否替换”五环节，遵循懒加载原则，双亲委派保障安全但可打破，类类型由全限定名与ClassLoader共同决定。
Java 类加载机制是大厂面试高频考点，关键不在死记硬背，而在理解“谁加载、何时加载、怎么加载、如何验证、能否替换”这五个核心环节。掌握类加载的运行逻辑 + 典型场景分析，比背诵双亲委派模型更有效。
搞懂类加载的触发时机
不是所有类在启动时就加载，JVM 遵循“懒加载”原则——只有真正用到时才触发加载（注意：不是 new 才加载，而是首次主动使用时）。常见触发点包括：
- 创建类的实例（new）
- 访问类的静态变量（非 final 常量）或赋值静态变量
- 调用类的静态方法
- 反射调用（如 Class.forName("Xxx")）
- 初始化子类时，父类先被初始化（即使子类没直接引用父类静态成员）
- JVM 启动时指定的主类（main 方法所在类）
反例：引用 final static 基本类型常量（编译期已内联），不会触发类加载；单纯 import 或声明变量（未使用）也不触发。
双亲委派不是“必须遵守”，而是“默认策略”
双亲委派的核心价值是**保障类的唯一性与安全性**（比如防止用户自定义 java.lang.Object 替换系统类）。但它是可打破的——只要重写 ClassLoader 的 loadClass() 方法，绕过 parent.loadClass() 调用即可。
立即学习“Java免费学习笔记（深入）”；
典型破例场景：
- Tomcat：每个 WebApp 有自己的 URLClassLoader，优先加载 WEB-INF/lib 和 classes，实现应用隔离
- OSGi：模块化框架，按 bundle 粒度控制类可见性与加载顺序
- 热部署/热更新：自定义类加载器重新加载修改后的 class 文件
面试时如果只说“双亲委派不能破坏”，说明没真正理解设计意图和工程实践。
动手看懂类加载全过程
光看理论容易迷糊，用 JVM 参数直观观察最有效：
- -verbose:class：打印每个类的加载来源（如 [Loaded java.lang.Object from ...]）
- -XX:+TraceClassLoading：同上，更详细（JDK8+）
- -XX:+PrintGCDetails + -XX:+PrintGCTimeStamps：结合 GC 日志，观察类加载是否引发元空间扩容
写个简单测试类，加个 static { System.out.println("Clinit triggered"); }，配合 -verbose:class 运行，就能清晰看到“加载 → 链接（验证/准备/解析）→ 初始化”的时间点。
高频陷阱题怎么答出彩
面试官常考“两个 ClassLoader 加载同一个类，它们相等吗？”这类题。答案不是简单“不相等”，而要分层讲清：
- 类的“类型相同”由全限定名 + 加载它的 ClassLoader 实例共同决定
- 即使字节码完全一样，不同 ClassLoader 加载的 Class 对象在 JVM 中视为不同类型
- 会导致 ClassCastException（如 A 类由 CL1 加载，传给 CL2 加载的代码使用）、instanceof 失效、static 变量不共享等问题
- 解决思路：统一 ClassLoader、避免跨 loader 传递对象、用接口/字符串等中立类型通信
能说到第三层影响和第四层解法，基本就稳了。
