.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 文件“执行”掉，而是分三步加载和准备：
-
装载（Loading）：通过类加载器（如
AppClassLoader）从磁盘、网络或内存中获取字节流，生成java.lang.Class实例，并存入方法区 -
链接（Linking）：包括验证（校验字节码安全性）、准备（为
static字段分配内存并设默认值）、解析（将符号引用转为直接内存地址） -
初始化（Initialization）：真正执行
<clinit></clinit>方法（静态块 + 静态变量赋值），这是类第一次“活起来”的时刻
注意：new 一个对象、调用 static 方法、访问 static 字段——这些行为才会触发初始化；单纯 Class.forName("X") 默认也会初始化，但加 false 参数可跳过。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
字节码指令怎么变成 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，而不是编译失败。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
