类文件、字节码与类加载：代码如何成为运行时类型
凌晨发布后，服务不是启动失败，而是在第一笔特殊订单进入时才抛出 NoSuchMethodError。编译环境、单元测试和普通接口都正常，只有运行时第一次解析某个方法符号时失败。此时只看 Maven 依赖树不够：我们需要知道源码生成了什么描述符，常量池保存了什么符号引用，运行时究竟装入了哪一份 class，以及错误发生在加载、验证、准备、解析还是初始化。
从这个延迟爆炸的发布事故往回追，先编译最小类，用 javap -v -c -p 读 classfile，再观察加载和初始化日志；UnsupportedClassVersionError、VerifyError、NoClassDefFoundError、NoSuchMethodError 随后会回到各自发生的阶段。指令表只是词汇，真正有用的是看到异常后知道证据应落在哪一层。
读 classfile 前先对齐工具和错误阶段
这条排障链经过 class 文件版本与结构、常量池、字段和方法描述符、Code 属性与异常表、加载/验证/准备/解析/初始化，最后看到字节码怎样进入解释器与 JIT。Java 语法词典和逐条指令翻译解决不了开头的链接错误；若证据显示同名类型由不同加载器定义，则应转向运行时类身份与加载器生命周期检查。
动手前要先确定 Java 版本与编译目标，并确认 javac、javap 和 java 来自预期工具链。下面的实验用 JDK 17 或更高版本即可复现；需要判断加载、链接和初始化的精确边界时，直接对照文末 JVMS 章节。
先把 JVM 主链路装进脑子里
线上排障时，你不需要先背完整虚拟机规范，但必须知道“证据落在哪一层”。OutOfMemoryError: Metaspace 不是堆问题，线程数暴涨不一定是业务对象泄漏，CPU 高也不一定是代码死循环。先把主链路打通，后面看命令输出才不会乱。
一条 Java 请求背后的 JVM 主线可以这样理解：
类加载本身不要只记“双亲委派”四个字，要把规范动作和工程动作分清：
直接看这张图时要注意几个边界：
加载阶段解决“字节从哪来”。它可能来自 jar、模块、网络、加密包、动态生成字节码，也可能来自插件框架自己的类加载器。验证阶段解决“字节码能不能进 JVM”。非法字节码、版本不匹配、栈映射帧异常，通常会表现为 VerifyError、ClassFormatError 或 UnsupportedClassVersionError。准备阶段不是执行 Java 赋值语句。static int x = 10 在准备阶段先是 0，到初始化阶段执行 <clinit> 后才是 10。
解析可以早做也可以懒做。线上看到 NoSuchMethodError、NoSuchFieldError、IncompatibleClassChangeError，经常是编译期和运行期依赖不一致。类身份由“类全名 + 定义它的类加载器”共同决定。同名类被两个加载器定义，强转时可能出现看起来很怪的 ClassCastException。
这条链路用一个最小程序就能看清：
javac -g Demo.java
javap -v -p Demo.class | sed -n '1,160p'
java -Xlog:class+load=info,class+init=info -cp . Demo线上进程可以看这些入口：
jcmd "$PID" VM.classloaders
jcmd "$PID" VM.metaspace basic
jcmd "$PID" GC.heap_info
jcmd "$PID" Compiler.codecache几条输出各自回答不同的问题：
javap -v 能看到常量池、字段、方法、字节码指令和 class 文件版本。class+load 能看到类从哪里加载，适合排查重复依赖、插件类加载器和容器类路径问题。VM.classloaders、VM.metaspace 能帮助判断类加载器数量和元空间占用。
Compiler.codecache 能看到 JIT 编译后的代码缓存是否紧张。
读这些输出时，最容易混淆的是加载、链接与初始化的边界：
类加载不是“加载完就能用”。完整过程至少要经过加载、链接、初始化；链接又包含验证、准备和解析。静态变量在准备阶段先获得默认值，执行类初始化方法时才进入业务赋值。类初始化有触发条件，例如 new、访问或设置静态字段、调用静态方法、反射、方法句柄等。只看源码顺序，很容易误判静态初始化副作用。JDK 9 之后常见的类加载器层次是 bootstrap、platform、application；还用 JDK 8 的 Extension ClassLoader 去解释新 JDK，容易把问题说偏。
同一个类名被不同类加载器加载，在 JVM 里不是同一个类型。插件化、脚本引擎、热部署和应用服务器里，类加载器泄漏会直接拖高 Metaspace。
线上遇到 ClassNotFoundException、NoSuchMethodError、ClassCastException、Metaspace 增长或发布后行为不一致时，不要只看 Maven 依赖树。还要把运行时类加载来源、类加载器层级、最终 JVM 参数和发布包内容放在一起比对。
用仓库里的 classfile 探针对照源码与字节码
可运行入口是 examples/backend-development/jvm/classfile-bytecode-loading/LinkageProbe.java。它同时包含编译期常量、需要执行 <clinit> 的静态字段、带参数描述符的方法和显式异常分支，足以把常量池、Code 属性、异常表和初始化日志对到同一份源码。
$sources = Get-ChildItem examples/backend-development/jvm -Recurse -Filter *.java
javac --release 17 -Xlint:all -Werror -d out/jvm $sources.FullName
javap -v -c -p out/jvm/example/jvm/classfile/LinkageProbe.class
java -Xlog:class+init=info -cp out/jvm example.jvm.classfile.LinkageProbe运行输出中的稳定业务部分是：
<clinit>:runtimeValue=11
result=103反编译时不要只搜索某条指令。先在常量池找到 invoice:(JLjava/lang/String;)J，再到方法表核对 descriptor、max_stack/max_locals、分支目标与异常构造，最后把 runtimeValue 的 putstatic 对回 <clinit>。如果把 COMPILE_TIME 的读取写进另一个类，调用方常量池可能直接保存整数 7；这时只替换声明类不会改变已编译调用方，正是“源码看起来改了、运行仍用旧值”的稳定反例。
用 classfile 回答“调用方到底编译了什么”
class 文件以 magic 0xCAFEBABE 开始，随后是 minor/major version、常量池、访问标志、this/super、接口、字段、方法和属性。它不是源码的压缩包，而是另一份二进制契约。方法重载在源码里看参数名和类型，classfile 只用名字加 descriptor 区分；void pay(long, String) 的描述符是 (JLjava/lang/String;)V。改返回类型、静态/实例属性或接口/类关系，可能让旧调用点分别落到 NoSuchMethodError、IncompatibleClassChangeError 或验证失败。
常量池保存字符串、类、字段、方法、方法句柄、动态调用点等符号。javap -v 输出中的 #17 = Methodref ... 与某条 invokevirtual #17 连起来，才能说明调用方期待哪个 owner、name 和 descriptor。排查时应同时反编译“调用方 class”和“运行时目标 class”，不能只看当前源码，因为发布包可能由旧模块或另一条流水线编译。
Code 属性里除了指令还有 max_stack、max_locals、异常处理表、行号表、局部变量表和 StackMapTable。异常处理表解释了 catch/finally 如何映射到指令范围；行号表决定堆栈能否回到源码；没有 -g 不会改变业务语义，却会降低现场可读性。StackMapTable 为验证器提供控制流类型状态，字节码增强工具若修改跳转却没有同步更新栈帧信息，常见结果就是 VerifyError。
把五类链接错误放回发生阶段
ClassFormatError 表示二进制结构本身不成立；UnsupportedClassVersionError 表示 class 版本超出当前 JVM 能力；VerifyError 表示结构能读但类型安全或控制流证明失败；NoClassDefFoundError 表示 JVM 曾尝试定义需要的类却没有成功，cause 可能是第一次初始化异常；NoSuchMethodError 则通常是旧调用方已按某个二进制签名编译，运行时解析到的新目标不再提供它。
特别注意初始化失败会被记住。第一次主动使用类时，<clinit> 抛出的业务异常通常包在 ExceptionInInitializerError 中；同一个加载器下再次使用，可能直接得到 NoClassDefFoundError: Could not initialize class。第二个异常不是“class 文件突然丢了”，必须回看第一次失败日志。
初始化顺序要用可观察实验验证
创建实例、调用静态方法、读写非编译期常量静态字段、反射和特定方法句柄会触发初始化；读取另一个类声明的编译期常量可能已经被内联，不触发声明类初始化。接口初始化也不等于先初始化所有父接口。把父类、子类的静态字段初始化和静态块分别打印，再配合 -Xlog:class+init=debug，可以观察“准备阶段默认值”和“初始化阶段 Java 赋值”的差别。
生产代码应避免在静态初始化中访问网络、数据库或依赖动态配置。<clinit> 由 JVM 串行协调，同一类的初始化若卡住，其他线程会等待；若初始化路径形成环或把锁交给另一个等待该类的线程，启动会表现为无响应。修复方式通常是把外部 I/O 移到显式生命周期，把失败变成可重试、可超时、可观测的启动步骤。
发布前，再把调用点和目标类对一遍
回到开头的 NoSuchMethodError：它不是“JVM 随机找不到方法”，而是调用方 class 中的方法符号已经形成，运行时解析到的目标类型却没有兼容成员。先用 javap 比较调用点描述符，再确认实际加载来源和制品哈希，最后修正依赖收敛并在真实运行镜像回归。只有异常阶段、class 来源和二进制契约三份证据闭合，才有资格重新发布。
继续拆 classfile 时，先盯住这三页
JVMS 4：The class File Format：常量池、字段、方法、属性、描述符和版本结构。JVMS 5：Loading, Linking, and Initializing：加载、验证、准备、解析和初始化分别何时发生。
JVMS 6：The Java Virtual Machine Instruction Set：需要确认某条指令的操作数和异常时再按名称查，不必从头背指令表。
以后再碰到 VerifyError、NoSuchMethodError 或初始化失败，先判断自己正在问的是“class 里写了什么”“运行时装入了什么”，还是“解析到哪一步失败”。三类问题分别对应 javap、加载来源和首次异常日志；把证据拿齐，比重新编译一次碰碰运气更快。