C 语言的链接过程将多个目标文件合并为可执行文件，地址在构建时确定。Java 的类加载机制完成的是类似的工作——将.class文件中的字节码读入 JVM，解析符号引用，最终形成运行时数据结构。但两者的核心差异在于：C 的链接是静态的、一次性的，Java 的类加载是动态的、延迟的、可以在程序运行中持续进行的。

一、类加载的生命周期

一个类从被 JVM 加载到卸载，经历加载、连接、初始化、使用和卸载五个阶段。其中连接阶段又细分为验证、准备和解析三个子阶段。JVM 规范没有强制规定解析发生的具体时机，允许在初始化之后、首次主动使用时再触发。

加载：通过类的全限定名获取二进制字节流，将字节流中的静态存储结构转换为方法区的运行时数据结构，在堆中生成代表该类的Class对象。这个Class对象是程序访问该类型元数据的入口。加载阶段是整个流程的入口，也是类加载器介入的起点。

验证：检查字节流是否符合 JVM 规范——文件格式校验（魔数、主次版本号）、元数据验证（父类继承链的合法性）、字节码验证（数据流和控制流分析）、符号引用验证。验证阶段是 JVM 安全性的第一道防线，防止恶意字节码破坏系统。Java 反序列化漏洞和部分字节码注入攻击，正是通过绕过验证阶段实现的。

准备：为类变量（静态变量）分配内存并设置默认初始值——int为 0，reference为null，boolean为false。static final常量在这个阶段就被赋予程序指定的值，而非默认值。

解析：将常量池中的符号引用替换为直接引用——方法调用从符号（invokevirtual #10指向常量池中的方法名和描述符）变为实际地址。解析的时机可以是类加载后立即执行，也可以是每个符号首次被使用时再解析，由-Xverify:none等参数控制。

初始化：执行类构造器<clinit>方法——编译器自动收集所有类变量赋值和静态代码块，按代码顺序合并生成的。<clinit>与实例构造器<init>不同，它只执行一次，且 JVM 保证它是线程安全的。如果多个线程同时初始化同一个类，只有一个线程执行<clinit>，其余线程阻塞等待。

二、类加载器与双亲委派模型

类加载器负责执行加载阶段。JVM 内置了三层类加载器，形成自上而下的树状结构：

Bootstrap ClassLoader：由 C++ 实现，嵌入 JVM 底层，加载JAVA_HOME/lib/rt.jar、resources.jar等核心类库，在 Java 中无对应对象。

Platform ClassLoader：JDK 9 之前的 Extension ClassLoader，加载JAVA_HOME/lib/ext/下的扩展类库。JDK 9 起改为 Platform ClassLoader，加载模块化系统中的平台模块。

Application ClassLoader：加载classpath上的用户类，是ClassLoader.getSystemClassLoader()的返回值。绝大多数用户代码由这个加载器加载。

双亲委派模型是这三层加载器之间的协作规则：当一个类加载器收到加载请求时，不会立即尝试加载，而是先委托父加载器处理。父加载器无法加载时，才由自己尝试。

这个模型的目的是保证核心类库的安全性。用户编写的java.lang.Object无法被加载，因为启动类加载器已经加载了官方版本。这种机制防止了恶意代码替换 JDK 核心类。

java

protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { // 检查是否已加载 Class<?> c = findLoadedClass(name); if (c == null) { try { if (parent != null) { c = parent.loadClass(name, false); } else { c = findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // 父加载器无法加载 } if (c == null) { c = findClass(name); // 自己加载 } } return c; } }

findClass是子类需要重写的方法。自定义类加载器通常重写findClass而非loadClass，这样既能保持双亲委派模型，又能自定义字节码获取方式。

三、打破双亲委派模型的场景

双亲委派模型是默认规则，但不是铁律。某些场景下需要打破这个模型，因为父加载器加载的类无法感知子加载器的类，这在某些架构中会成为限制。

OSGi 模块化：OSGi 为每个模块使用独立的类加载器，模块之间可以互相关联，打破了传统树状结构的线性委托链。这种机制让同一 JVM 中运行多个版本的同一个类成为可能。

Java SPI 机制：ServiceLoader.load()由启动类加载器加载，但需要加载应用类路径上的服务实现类，这导致了线程上下文类加载器的出现——允许父加载器请求子加载器加载类。

热部署：重新加载类时创建新的类加载器实例，加载更新后的字节码。旧类加载器及其加载的类被垃圾回收的前提是没有任何引用指向它们。热部署的实现依赖于类加载器的隔离性——新旧类被不同的加载器加载，在 JVM 内部视为不同的类型，即使包名类名完全一致。

Tomcat 类加载器：每个 Web 应用拥有独立的类加载器，隔离不同应用之间的类，防止版本冲突。Web 应用类加载器也打破了双亲委派——它优先加载自己的类，再委托父加载器。

自定义类加载器的典型应用场景包括：从加密文件或网络加载字节码、实现类版本管理、在运行时动态生成和加载类。Spring 的CGLIB动态代理和 Java 的Proxy类都涉及运行时类生成和加载。

四、类加载与 JDK 9 模块化

JDK 9 引入的模块化系统重塑了类加载器的结构。java.base模块是所有模块的基础，包含java.lang、java.util等核心包，由启动类加载器加载。每个模块声明其对其他模块的依赖（requires）和导出的包（exports），JVM 在加载时验证模块依赖的完整性。

模块化对类加载的影响在于：模块之间的访问控制不再只依赖访问修饰符，模块边界也成为一道屏障。一个包如果未在module-info.java中声明exports，即使它是public的，也无法被其他模块访问。这影响了类加载过程中对类可见性的判断。

五、类的卸载与内存泄漏

类由类加载器加载，类的生命周期与加载它的类加载器绑定。当类加载器不再被引用时，其加载的所有类才能被垃圾回收。这也解释了为什么热部署时必须扔掉旧的类加载器——旧类加载器持有的类无法被回收。

典型的类加载内存泄漏场景：缓存了类加载器或类的引用（如静态 Map 存储类名到 Class 的映射）、线程池线程的 ThreadLocal 中存储了类加载器相关对象、JDBC 驱动注册导致的引用泄漏——DriverManager持有驱动类的引用，驱动类又持有类加载器的引用，导致 Web 应用热部署后整个类加载器无法卸载。

六、常见异常与排查思路

七、小结

类加载机制是 Java 动态特性的根基——代理模式依赖运行时生成类，热部署依赖类的重新加载，SPI 依赖上下文类加载器的委托链，模块化依赖类加载边界的定义。理解类加载的生命周期、双亲委派模型的结构和打破它的原因、模块化对类加载的影响，是诊断类相关异常的前提，也是设计和实现类加载相关功能的前提。

C 的链接在编译期完成，Java 的类加载在运行期进行——这并不意味着 Java 运行得更慢，而是它把一部分工作从构建时挪到了运行时，换来了更高的灵活性和可扩展性。这种动态性是 Java 企业级生态中最核心的优势之一。