.class文件不能直接运行，因为它是JVM专用字节码格式，含常量池、方法表等结构，操作系统只识别CPU机器码；必须经JVM加载、验证、解析并解释或JIT编译为本地指令后才能执行。
Java 字节码文件（.class）不是可执行文件，它必须由 JVM 加载、验证、解析并最终解释或编译为本地机器指令后才能运行。
为什么 .class 文件不能直接在操作系统上运行
操作系统只认识特定 CPU 架构的机器码（如 x86-64 或 ARM64 指令），而 .class 文件是 JVM 自己定义的二进制格式：它包含常量池、字段表、方法表、字节码指令等结构，全部以 8 字节为单位紧凑排列。JVM 是唯一能按规范读取并理解这些内容的“翻译器”。没有 JVM，.class 就是一堆无法被 OS 调度的原始字节流。
常见错误现象：java.lang.ClassFormatError 通常说明字节码结构非法（比如魔数不对、主次版本号不匹配），这一步发生在 JVM 的“验证”阶段，早于任何代码执行。
class 文件如何被 JVM 分阶段处理
JVM 不是一次性把整个 .class 文件“执行”掉，而是分三步加载和准备：
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
装载（Loading）：通过类加载器（如
AppClassLoader）从磁盘、网络或内存中获取字节流，生成java.lang.Class实例，并存入方法区 -
链接（Linking）：包括验证（校验字节码安全性）、准备（为
static字段分配内存并设默认值）、解析（将符号引用转为直接内存地址） -
初始化（Initialization）：真正执行
<clinit>方法（静态块 + 静态变量赋值），这是类第一次“活起来”的时刻
注意：new 一个对象、调用 static 方法、访问 static 字段——这些行为才会触发初始化；单纯 Class.forName("X") 默认也会初始化，但加 false 参数可跳过。
字节码指令怎么变成 CPU 能跑的代码
JVM 执行字节码有两种主要路径：
-
解释执行：逐条读取
iconst_1、istore_0这类指令，查表翻译成对应操作，慢但启动快 - 即时编译（JIT）：HotSpot VM 会监控热点方法（如循环体、频繁调用的方法），用 C1/C2 编译器将其编译为本地机器码，缓存到代码缓存区（CodeCache）里复用
关键点：同一个 .class 文件，在不同 JVM 实现（如 OpenJ9、GraalVM）或不同运行时配置（-XX:+TieredStopAtLevel=1）下，实际执行路径可能完全不同；你看到的 javap -c 输出只是字节码视图，不是最终 CPU 执行流。
容易被忽略的兼容性细节
class 文件头前 4 字节是魔数 0xCAFEBABE，接下来 2 字节是次版本号、2 字节是主版本号（如 Java 17 对应 61.0）。JVM 只接受主版本号 ≤ 自身支持上限的 class 文件。OpenJDK 21 能加载 65.0（Java 21）及更低版本，但无法加载 66.0（Java 22）——报错是 UnsupportedClassVersionError，不是语法错误。
另一个隐性坑：某些字节码指令（如 invokedynamic）依赖 JVM 内部的 java.lang.invoke 支持，如果用旧版 JVM（如 Java 7 以前）运行含该指令的 class，会直接抛 UnsupportedOperationException，而不是编译失败。
