类加载与字节码

• OSGi bundle 的类加载模型
• 类加载器的委托关系
• 模块可见性控制

OSGi 采用基于 bundle（模块）的类加载模型，每个 bundle 有独立的类加载器，并有自己的 Import-Package / Export-Package / Require-Bundle 声明。bundle 加载类时，遵循"类加载委托 + 模块可见性"的规则：先看自身 bundle 内是否包含该类，再看声明的 Import-Package 是否来自其他 bundle，并可委托给其他 bundle 的类加载器。OSGi 的类加载器不是简单的双亲委派，而是按 bundle 依赖图（bundle 图）进行委托，支持动态安装/卸载 bundle 而不影响其他模块。这种机制提供了模块隔离与版本控制，但类加载器数量多、依赖复杂，也带来性能与调试复杂度。

OSGi 的创新在于"模块可见性由声明控制"，而非纯粹按类加载器层级。这实现了模块化、版本隔离与热插拔，代价是类加载器图复杂、易出现类加载冲突。

• 并行类加载（Parallel Class Loading）
• 类加载的锁与并发
• 不同类加载器的并行能力

JVM 负责类加载的加锁以确保同一类只被加载一次，且类加载是"递归"的：加载类 A 可能触发加载其父类/接口。为提高并发，JDK 提供了并行类加载能力：若类加载器注册为并行能力（Parallel Capable），JVM 会对每个类名做细粒度加锁（按类名分锁），使不同类名的加载可并行，从而提升并发加载性能。Boot/Platform/App 类加载器默认支持并行；自定义类加载器需在静态初始化中注册（ClassLoader.registerAsParallelCapable）才能受益。锁粒度从"类加载器级"细化为"类名级"，避免不同类互相阻塞。

类加载的并发通过"按类名加锁"实现并行。并行能力让不同类同时加载，而同一类仍保证互斥加载，兼顾正确性与并发性能。

• 类加载器命名空间
• 同名类在不同加载器中的隔离
• 跨加载器类型不匹配

每个类加载器构成一个命名空间，同一二进制名（如 com.example.Order）由不同类加载器加载时，是两个完全不同的 Class 对象，两者类型不兼容。Java 判定类型相等不仅看类名，还看"类 + 定义它的类加载器"（defineClass 的加载器）。因此，若对象由类加载器 A 加载的 Order 创建，而代码用类加载器 B 加载的 Order 去强制转换，会抛 ClassCastException（即使二进制完全一致）。这是隔离机制（防止类被篡改、保证模块边界）的必然结果，也是 Tomcat/OSGi 等各加载器场景下常见的坑。

类加载器命名空间实现了"同名类隔离"，但要求跨模块传递对象时类型必须由同一加载器加载。ClassCastException 常源于"两个加载器加载了同名类"或 TCCL 混乱。

• TCCL 的概念
• 打破双亲委派的场景
• 典型应用（JDBC、SPI）

线程上下文类加载器（Thread Context ClassLoader，TCCL）是 JVM 为每个线程设置的一个类加载器，可通过 Thread.currentThread().setContextClassLoader() 设置。它的作用场景是"打破双亲委派"：当上层（如 JDK 的 DriverManager、ServiceLoader）需要加载由应用/第三方提供的实现类（如 JDBC 驱动），而应用类加载器又无法被 JDK 引导类加载器间接访问时，就通过 TCCL 让当前线程能加载到应用类路径上的类。典型应用：JDBC 的 DriverManager 用 TCCL 加载数据库驱动、SPI（ServiceLoader）用 TCCL 加载服务实现、Web 容器（Tomcat）、框架加载依赖等。

TCCL 是"从下往上"加载的桥梁，让父加载器（JDK）能加载子加载器（应用）的类，从而支持 SPI 机制。它破坏了双亲委派，但也是框架加载第三方实现的必要手段。

• 类卸载的条件
• 类加载器可达性
• 与 Metaspace 回收的关系

类卸载要求"类加载器 + 其加载的所有类"都不可达。具体而言，驻留在 Metaspace 的类元数据只有在满足以下条件时才会被卸载：该类的所有实例都不可达、该类对应的 Class 对象不可达、以及定义该类的类加载器不可达（无任何引用）。关键点在于"类加载器可达性"：只要类加载器仍被引用（如静态字段、ThreadLocal、缓存持有），其加载的类就永远无法卸载。因此，运行时卸载类通常依赖自定义类加载器 + 及时释放加载器引用，配合显式触发 GC。这也是动态类（如 JSP、插件）热挂载/卸载与 Metaspace 回收的基础。

类卸载的抓手是"类加载器不可达"。只要加载器被引用，类就存活；因此元空间泄漏常源于类加载器泄漏。合理使用自定义类加载器并释放引用可支持类卸载与热更新。

• 双亲委派模型
• SPI 打破双亲委派
• Tomcat 的类加载隔离

双亲委派模型让类加载器先委托父加载器加载，父加载不到才自己加载，保证核心类（如 java.lang）一致性。但某些场景需要打破：SPI（如 JDBC DriverManager）中，JDK 的 DriverManager 由引导类加载器加载，无法加载应用类路径上的数据库驱动，于是通过线程上下文类加载器（TCCL）从子加载器加载驱动实现，从而打破"父无法加载子"的限制。Tomcat 的类加载隔离则采用"先加载自己、再委托父"的相反顺序：每个 Web 应用有独立 WebAppClassLoader，优先加载 WEB-INF/classes 和 lib 中的类，实现应用间类隔离（不同应用可用不同版本的库），同时避免破坏 JDK 核心类。实现方式通常是自定义类加载器重写 loadClass 打破默认委托顺序。

打破双亲委派的两类典型：SPI 用 TCCL 让父加载子（自上而下），Tomcat 用逆序委派让子加载自己（自下而上）。核心都是"父加载器无法按需加载子路径类"问题。

• 类加载的五个阶段
• 初始化时机与主动引用
• 被动引用不触发初始化

类加载过程分为加载、验证、准备、解析、初始化五个阶段。加载：通过字节流读取类并生成 Class 对象；验证：校验字节码合法性；准备：为静态变量分配内存并设置默认值；解析：把常量池中的符号引用转为直接引用；初始化：执行静态字段赋值与静态块（）。初始化时机由"主动引用"触发：new 对象、访问静态字段/方法、反射调用、初始化子类（父类先初始化）、作为主类启动等。被动引用（如通过子类引用父类静态字段、定义数组、引用常量）不会触发初始化。理解主动/被动引用有助于判断类何时被真正初始化。

五个阶段中，加载到解析是"被动"准备元数据，初始化才真正执行用户代码。主动引用触发初始化，被动引用不触发，这是理解类加载时机与静态块执行的关键。

• 重写 findClass 与 defineClass
• 加密 class 的解密加载
• 热部署的类加载器替换

自定义类加载器实现加密 class 加载的关键是重写 findClass（或 loadClass）方法：在其中读取加密的 class 字节流，用密钥解密后得到字节数组，再调用 defineClass 生成 Class 对象，从而绕过默认的字节码读取路径。实现热部署的关键是：每次部署用新的类加载器实例加载新版本类，并让业务代码通过该加载器引用；配合"类加载器 + 类不可达"的卸载机制，旧加载器被释放后旧类可被 GC 回收。同时要注意：热部署要打破双亲委派（让新加载器优先加载自身类），否则可能仍用旧类；还要处理静态状态、线程池持有旧类等问题。

加密加载 = 自定义字节流 + defineClass；热部署 = 新类加载器实例替换 + 旧加载器释放。关键点是 findClass 的字节源控制与类加载器生命周期管理。

• 各调用指令的语义
• 静态/动态分派
• invokeinterface 与 invokedynamic

方法调用指令各有语义：invokevirtual 用于调用实例方法（虚方法），执行动态分派（按运行时接收者类型选择实现）；invokespecial 用于调用私有方法、构造器、super 方法（静态绑定，不做动态分派）；invokestatic 用于调用静态方法（静态绑定）；invokeinterface 用于调用接口方法（按接口引用的实例动态分派，与 invokevirtual 类似但接口方法）；invokedynamic 用于动态方法调用（如 Lambda、字符串拼接），由引导方法（Bootstrap Method）在运行时解析方法句柄，支持最灵活的动态分派。invokedynamic 是 JDK 7 引入、Lambda 与动态语言的基石。

关键差异是"静态绑定 vs 动态分派"权限：invokespecial/invokestatic 静态绑定，invokevirtual/invokeinterface 动态分派，invokedynamic 完全交由引导方法动态解析。理解它们有助于分析方法分派与 JIT 内联。

• defineClass 的作用
• findClass 的模板方法
• 自定义加载器的典型写法

defineClass 是 ClassLoader 的核心方法，用于把字节数组转换为 Class 对象（进行类定义、验证），并记录类与其加载器的关联。findClass 是模板方法：默认的 loadClass 遵循双亲委派，先委托父加载器，父加载不到时调用 findClass 由子类去查找并加载类。自定义类加载器的典型写法是重写 findClass：在其中读取字节、调用 defineClass(name, bytes, off, len) 返回 Class 对象。若需完全控制加载顺序，可重写 loadClass 打破委派。defineClass 与 findClass 共同构成"父委托 + 子自定义查找"的扩展模式。

defineClass 是"字节→类"的入口，findClass 是"为什么子类要重写的模板"。遵守模板（重写 findClass 而非 loadClass）可保留双亲委派的安全性，同时扩展加载来源。

• ASM 的底层 API
• Javassist 的源码级操作
• ByteBuddy 的高层 API

三大字节码库定位不同：ASM 是最底层、性能最高的字节码操作库，直接操作字节码指令，适合追求极致性能与精细控制的场景（如框架内部对热点代码做字节码增强），但 API 复杂、学习成本高；Javassist 采用源码级（字符串拼接 Java 代码 + 编译）的方式修改类，简单直观，适合快速实现、性能要求不高的场景，但运行时编译开销较大；ByteBuddy 提供高层、安全的 API，基于 ASM 封装，支持声明式类修改、动态代理、方法拦截等，兼具易用性与性能，是 Spring、Mockito 等框架常用。选型原则：追求性能与底层控制选 ASM，追求简单快速选 Javassist，追求易用与平衡选 ByteBuddy。

选型是"性能 vs 易用性"的权衡：ASM 快但难，Javassist 简单但慢，ByteBuddy 折中且现代。实际框架常基于 ASM/ByteBuddy 构建。

• 加载与存储指令
• 算术指令
• 方法调用与分支指令

字节码是 JVM 的指令集，常用指令包括：加载与存储（aload/iload 从局部变量表加载引用/整型到操作数栈，astore/istore 反向存储）、算术（iadd/ladd/fadd/dadd 等整数/浮点加法，以及减法、乘法等）、方法调用（invokevirtual/invokespecial/invokestatic/invokeinterface/invokedynamic）、对象与数组（new、getfield/putfield、arraylength）、分支控制（goto、if_icmpne、lookupswitch/tableswitch）、类型转换（i2l、checkcast）、返回（ireturn/areturn/return）等。理解指令集有助于阅读字节码、分析 JIT 优化与栈上操作。

字节码是"基于操作数栈"的指令集，aload/iload 等负责数据进出栈，iadd 等执行算术，invokevirtual 等分派方法。掌握指令集是理解字节码增强与 JVM 执行的基础。

• 类文件的开头结构
• 常量池
• 字段表/方法表/属性表

Class 文件是以魔数（0xCAFEBABE）开头的二进制结构，随后是主/次版本号，然后是常量池（constant pool，存放类名、字段名、方法名、字符串、方法句柄等常量）、访问标志（access_flags）、类名/父类/接口索引、字段表（fields）、方法表（methods）和属性表（attributes，如 Code、Exceptions、LineNumberTable 等）。方法表里的 Code 属性包含该方法的字节码指令、异常表、局部变量表等。版本号决定 JVM 能否加载（低版本 JVM 无法加载高版本 class）。理解类文件结构是字节码分析、反编译与类加载的基础。

类文件是"自描述"的二进制结构，魔数标识文件类型，版本号控制兼容性，常量池是符号引用的底座，字段/方法/属性承载具体内容。字节码增强本质就是改写这些结构。

• JEP 484 Class-File API
• 与 ASM 的对比
• 框架二次开发的选型

JEP 484（Class-File API，JDK 22 孵化、后续转正）提供了 JDK 自带的、用于解析和生成 Class 文件的 API，作为 ASM 等第三方库的替代/补充。与 ASM 的对比：JEP 484 是官方标准 API，随 JDK 演进、无需额外依赖、API 更现代（基于 Stream/record 风格），能解析和生成 Class 文件；ASM 是第三方成熟库，性能高、API 底层灵活、生态成熟，但需引入依赖且 API 较旧。框架二次开发时：若希望减少依赖、紧跟 JDK 版本、做较为标准的类文件读写，可选 JEP 484；若需要极致的字节码性能与细粒度控制（如热点增强），ASM 仍占优。两者可共存，JEP 484 正处于向标准演进的阶段。

JEP 484 是"官方标准化的字节码处理 API"，目标是为 JDK 提供内建能力并减少对 ASM 的依赖。选型看"是否接受依赖、性能需求、API 风格偏好"。

• 三者的抽象层次
• 易用性与控制力
• 选型依据

三者的 API 抽象层次从低到高：ASM 是"指令级"抽象，直接操作字节码指令与节点，控制力最强、性能最高，但需要理解字节码细节；Javassist 是"源码级"抽象，用 Java 源码字符串拼接来修改类，抽象层次不高但上手简单，运行时编译开销大；Byte Buddy 是"高层声明式"抽象，用优美的 DSL 描述类修改（如拦截方法、生成子类），底层基于 ASM，抽象层次最高、易用性最好，同时保持性能。对比而言：追求底层控制与性能选 ASM，追求快速上手选 Javassist，追求声明式易用与平衡选 Byte Buddy。

抽象层次决定"控制力与易用性的权衡"：ASM 最底层最灵活，Byte Buddy 最上层最易用，Javassist 居中靠源码拼接。框架开发者常在底层（ASM）与高层（Byte Buddy）间选择。

• 类卸载的条件
• 类加载器生命周期
• Metaspace 回收

Metaspace 中的类（类元数据）在满足以下条件时才会被卸载：类加载器不可达（无任何引用）、该类的所有实例不可达、Class 对象不可达。类卸载以"类加载器 + 其类"为单位，只有整个类加载器及其加载的类都不可达时，Metaspace 才会回收这些类元数据。因此，只要类加载器被长期持有（如静态缓存、容器、ThreadLocal），其类就无法卸载，Metaspace 持续增长。常见于动态生成类（JSP、代理、插件）的场景。主动触发 GC 有助于回收不可达的类元数据。

类卸载的关键是"类加载器不可达"。Metaspace 回收与堆回收类似，但单位为"类加载器 + 类"。控制类加载器生命周期是防止 Metaspace 泄漏的核心。

• Metaspace 与类元数据
• Metaspace 回收机制
• Metaspace OOM 排查

Metaspace（JDK 8 起的元空间）存放类元数据（Klass 结构、常量池、方法元数据等），使用本地内存，受 -XX:MaxMetaspaceSize 限制。Metaspace 回收依赖类加载器不可达：只有类加载器及其类能被卸载时，其元数据才被回收。Metaspace OOM（OutOfMemoryError: Metaspace）常见于动态生成类过多或类加载器泄漏。排查步骤：设置并观察 -XX:MaxMetaspaceSize 与 MaxMetaspaceFreeRatio，用 jstat -gc 的 MC/MU 观察元空间使用，用 jcmd GC.class_histogram 或 -Xlog:class+load 看类加载数量，用 MAT 分析类加载器引用链，定位是哪些加载器持续被持有。

Metaspace 的 OOM 本质是"类元数据无法回收"，根因多为类加载器泄漏或动态类生成失控。排查围绕"谁在持有类加载器"与"类加载频率"展开。

• 栈帧的结构
• 局部变量表与操作数栈
• 方法调用与栈帧管理

JVM 栈帧（Stack Frame）是方法调用时在虚拟机栈上分配的结构，包含局部变量表（Local Variables）、操作数栈（Operand Stack）、动态链接、方法返回地址等。局部变量表存放方法参数与局部变量（含引用类型），操作数栈是字节码运算的临时存储区（算术、方法参数、方法返回值都经操作数栈传递）。每次方法调用都会创建一个新栈帧，方法返回时栈帧弹出并销毁；栈帧的深度与局部变量表/操作数栈大小由类文件在编译期确定（Code 属性中）。理解栈帧即理解方法调用时数据如何传递与存储。

栈帧是"方法执行的上下文"，局部变量表存数据、操作数栈做运算，两者配合执行字节码。方法调用 = 压栈新帧，返回 = 弹栈，栈溢出（StackOverflow）即栈帧过多。