在Java里类加载过程是怎样的_Java类加载机制解析

类加载发生在运行时按需触发，如new实例化、调用静态方法、访问静态字段（非final）、Class.forName()、初始化子类等；被动引用不触发。

类加载发生在什么时候

Java 类加载不是在编译时完成的，而是在运行时按需触发。最常见的情况是首次主动使用某个类：比如 new 实例化、调用静态方法、访问静态字段（非 final 常量）、反射（Class.forName()）、初始化子类（会先加载并初始化父类）等。被动引用（如子类引用父类静态字段、数组定义 MyClass[]）不会触发加载。

注意：ClassLoader.loadClass(String name) 默认只执行加载和链接（验证、准备），不触发初始化；而 Class.forName(String name) 默认会初始化类 —— 这个差异常被忽略，导致静态块没执行、配置未加载。

加载、链接、初始化三阶段分别干啥

类加载过程严格分为三个阶段，不可跳过或逆序：

• 加载（Loading）：通过类名定位字节码（从 classpath、jar、网络、动态生成等），读入二进制流，生成 java.lang.Class 对象。此时类还没“活”起来，只是有了内存里的结构。
• 链接（Linking） 又分三步：
  　• 验证（Verification）：检查字节码是否符合 JVM 规范（比如方法签名是否合法、栈是否溢出）；
  　• 准备（Preparation）：为类变量（static 字段）分配内存并设默认值（如 int 设为 0，Object 设为 null），注意：不执行 = 后的赋值或静态代码块；
  　• 解析（Resolution）：把符号引用（如类名、方法名字符串）转为直接引用（内存地址或句柄）。
• 初始化（Initialization）：真正执行类构造器 方法，也就是静态变量赋值语句 + 静态代码块，按源码顺序执行。这是唯一允许用户代码介入的阶段。

双亲委派模型怎么打破又为何要打破

默认情况下，每个 ClassLoader 先委托父加载器尝试加载，直到启动类加载器（Bootstrap）。这种机制保证了核心类（如 java.lang.Object）不会被用户自定义版本替换，增强安全性。

但有些场景必须打破它：

• 热部署 / 模块隔离：OSGi、T

  

  omcat 的 webapp 类加载器，需要各自独立加载相同类名的不同版本；
• 基础类依赖实现类：JDBC 的 DriverManager 在 rt.jar 中，但它要加载用户提供的 com.mysql.cj.jdbc.Driver，只能靠 Thread.currentThread().getContextClassLoader() —— 这就是典型的“父加载器请求子加载器干活”；
• 自定义加载逻辑：比如从加密 ZIP 或远程 HTTP 加载 class，需重写 findClass()，而非 loadClass()（否则破坏委派）。

打破的关键是：重写 loadClass() 并去掉 super.loadClass() 调用，或直接调用 findClass()；但务必小心，避免重复加载或类冲突（LinkageError）。

如何观察类加载过程

最直接的方式是加 JVM 参数：

-verbose:class

它会打印每一行 “[Loaded xxx from yyy]”，但信息太泛。更精准可配合：

• -XX:+TraceClassLoading（同 -verbose:class）
• -XX:+TraceClassResolution：看符号引用解析细节
• JDK9+ 推荐用 jcmd VM.native_memory summary 或 JFR（Java Flight Recorder）抓取类加载事件
• 代码中监听：注册 java.lang.instrument.ClassFileTransformer，或用 ManagementFactory.getClassLoadingMXBean() 查统计量

别依赖 IDE 的 “Debug Class Loading” 插件——它们往往只捕获部分事件，且干扰真实加载路径。真要调试，得在自定义 ClassLoader 的 defineClass() 和 resolveClass() 里打日志。