夜雨聆风🍲 点题
一段 Java 源码从编译，到类加载，再到字节码被解释运行，到最后对象被回收，中间会经过一条完整的运行链路。本文基于 Java SE 21 与 HotSpot ，把这幅 JVM 全景图完整串起来。
🔍 原理拆解
1. JDK,JRE 与 JVM
JDK 提供 javac、java、诊断工具和运行时镜像；
JRE 表示运行 Java 程序所需的环境；
JVM 负责执行 class 文件。
2. 源码先变成平台无关的类文件
本文使用以下这段代码 demo 贯穿整条链路：
publicclassOrderApp { // 定义启动器需要寻找的入口类
privatestaticintfee = loadFee(); // 初始化阶段才会把默认值改成业务值
publicstaticvoidmain(String[] args) { // 入口类初始化完成后，JVM 调用 main
Orderorder = newOrder(40, 2); // 创建对象，并确保 Order 类处于可用状态
inttotal = order.total(fee); // 调用实例方法，为它建立栈帧
System.out.println(total); // 输出 85，底层最终借助操作系统写出
} // main 返回后，非守护线程仍可能让进程继续运行
privatestaticintloadFee() { // 该方法由类初始化逻辑调用
return5; // 返回写入静态字段 fee 的值
} // 方法结束，对应栈帧退出
privaterecordOrder(int price, int count) { // record 同样会编译成独立类型
inttotal(int extraFee) { // 参数与局部状态进入新栈帧
return price * count + extraFee; // 字节码完成取值、运算和返回
} // 结果交回 main，当前栈帧退出
} // 嵌套类型也有自己的类文件和生命周期
} // OrderApp 定义结束，编译后会形成入口类文件
javac 完成语法分析、类型检查和必要转换，再生成包含版本号、常量池、字段、方法、字节码与属性表的类文件。OrderApp 与 Order 会形成各自的类文件。
javac 生成稳定的中间表示，JIT 再结合当前机器和运行数据优化，这正是跨平台与本地性能能够兼顾的原因。
3. JVM 启动后，类依次经历加载、链接与初始化
执行 java OrderApp 时，启动器会初始化 JVM。虚拟机会创建初始类，完成必要的链接与初始化，再调用 main；后续执行字节码时，再按需处理相关类。
加载解决“类型从哪里来”。类加载器取得二进制数据，JVM 建立内部类型表示。HotSpot 的引导、平台和应用类加载器分工查找不同类型；父级优先委派是常见策略，自定义加载器也可调整行为。运行时类型身份由二进制名称与定义类加载器共同决定。
链接包含验证、准备和解析。验证检查类文件结构与字节码安全；准备把静态字段设为默认值，示例中的 fee 此时先是 0；解析把常量池中的符号引用关联到运行时实体。解析可以提前，也可以等指令真正使用符号时再发生，因此它未必集中在初始化之前。
初始化才执行静态字段初始化表达式与静态代码块，编译器通常把它们组织进 <clinit>。此时 loadFee() 才让 fee 变成 5。创建实例、调用某类声明的静态方法、写入其静态字段，或读取其声明的非编译期常量静态字段，都会触发相应初始化；初始化类之前，其父类会先初始化。完整边界见 Java SE 21 执行规范。
【 J VM程序运行全景流程】
4. 运行起来以后，数据分别住在哪里
JVM 规范把运行时数据区分为线程共享部分和线程私有部分。
线程私有部分包括程序计数器、Java 虚拟机栈和实现可能提供的本地方法栈。每次 Java 方法调用都会建立栈帧，保存局部变量表、操作数栈、动态链接信息和返回状态。执行 Order.total 方法时，该方法的栈帧成为当前栈帧；方法结束后，结果返回到 main 的调用点。程序计数器记录当前 JVM 指令位置；执行 native 方法时，其值按规范未定义。
线程共享部分包括堆和方法区。对象实例与数组按规范从堆中分配，GC 主要管理这里；方法区保存运行时常量池、字段与方法信息等类级结构。每个类或接口都有自己的运行时常量池，该常量池从方法区分配。
在 JDK 21 HotSpot 中，类元数据主要位于本地内存中的元空间，JIT 机器码进入代码缓存，对象和数组主要位于堆。方法区是规范概念；元空间承载方法区所描述的部分数据，代码缓存则是额外实现区域。
栈帧的局部变量表可以保存对象引用，引用指向的对象仍具有堆分配语义。Order order 中的局部变量与 Order 对象不是同一块数据。若 JIT 证明对象不会逃逸，还可能通过标量替换消除真实分配，同时保持 Java 语义不变。
【JVM运行时数据区剖面】
5. 字节码如何真正跑到 CPU 上
JVM 规范规定指令结果，并未要求采用解释器或 JIT。JDK 21 HotSpot 采用混合执行：解释器让方法快速启动并收集运行信息；热点方法或循环进入分层编译，先较快生成一版机器码，再产生优化更充分的版本。
编译结果进入代码缓存。长循环还可通过栈上替换切入编译版本，无须等待方法再次调用。方法内联、去虚拟化和逃逸分析都是常见优化。
JIT 会依据运行期间收集到的信息进行推测性优化；后来加载的新类若使假设失效，HotSpot 可以反优化，让执行回到解释器或较低层级。分层编译在启动速度、编译成本与峰值性能之间动态权衡。JDK 21 HotSpot 性能文档 说明服务端虚拟机默认启用该机制。
6. 对象从分配走向回收，程序再走向退出
执行 new Order(40, 2) 时，JVM 先确保目标类可用，再为对象分配存储空间并调用构造方法。HotSpot 常在当前执行线程所用的 TLAB 中快速分配，空间不足时进入慢路径；JIT 也可能消除这次分配。TLAB 与标量替换都属于 HotSpot 实现。
GC 从根引用出发判断对象是否可达，线程栈引用、类级引用、JNI 句柄和虚拟机内部引用都可能成为根。不可达仅表示对象具备回收条件。不同收集器采用不同的并发、暂停与整理策略；JDK 21 HotSpot 在多数常规配置下选择 G1，也提供 Parallel、ZGC 等方案。JDK 21 GC 调优指南 描述的是 HotSpot 行为。
Java 代码还可能通过 JNI 或 JDK 底层实现调用本地代码。-Xmx 只约束 Java 堆上限，进程还会占用元空间、代码缓存、直接内存和线程栈等本地内存，因此不能把 -Xmx 当作进程内存上限。main 返回后，存活的非守护线程仍可让进程继续运行；退出条件满足时，最终由操作系统回收进程资源。至此，整条运行链路闭合。
⚠️ 容易踩的坑
坑一：拿到 Class 对象，就以为静态代码已经执行
加载让 JVM 认识一个类型，初始化才执行静态字段初始化表达式和静态代码块。框架做类路径扫描时，经常希望读取类型信息，同时暂缓初始化，以免扫描动作意外启动线程、注册驱动或建立连接。
// ❌ 错误写法：把“返回 Class 对象”理解成静态初始化一定完成
Class<?> type = Class.forName("demo.LazyTarget", false, loader); // false 明确表示暂不要求初始化
// ✅ 正确写法：业务确实需要初始化时，明确使用 true
Class.forName("demo.LazyTarget", true, loader); // JVM 会在返回前确保目标类完成初始化
进一步看，链接中的解析也允许按需发生。更准确的判断方式是分别问：类型是否已经加载、是否已经验证和准备、当前符号是否已经解析、类是否已经初始化。
坑二：把方法区、永久代、元空间当成同一概念的三个名字
方法区属于 JVM 规范层；永久代和元空间属于 HotSpot 实现层。从 JDK 8 起，HotSpot 使用本地内存中的元空间承载主要类元数据。运行时常量池属于方法区的规范范围，Class 镜像与普通字符串对象仍是堆对象，静态字段的具体物理布局也属于实现细节。
这个区别会直接影响排障：-Xmx 只限制 Java 堆上限，进程还会使用元空间、代码缓存、直接内存、线程栈以及 GC 和编译器所需的本地内存。容器内存上限为两 GB、堆上限也设成两 GB，看起来把空间“用满了”，实际上几乎没给 JVM 其他部分留下余量。
坑三：代码里写了 new，运行时就一定存在一个独立堆对象
从 JVM 规范的抽象语义看，类实例和数组从堆分配；从 HotSpot 优化结果看，JIT 可以证明对象没有逃逸，并通过标量替换把对象拆成若干值，最终消除分配。Oracle 的 HotSpot 文档还特别说明，这并不等于把对象机械地搬到栈上。
因此，分析对象时可以分两步：先依据 Java 语义判断对象身份、引用关系和可见结果，再结合 JIT 日志或性能工具确认真实分配。仅凭源码里的 new 统计堆分配次数，结论往往不够可靠。
坑四：对象不可达以后，GC 会马上释放所有相关资源
不可达只表示对象具备回收条件，收集器何时执行由内存压力和算法策略决定。文件句柄、套接字等操作系统资源还需要确定的关闭时机，业务代码应主动管理其生命周期。
// ❌ 错误写法：把文件句柄的释放交给不确定的 GC 时机
InputStreaminput = Files.newInputStream(path); // 打开流时，底层文件句柄已经被占用
consume(input); // 方法结束也不代表底层资源马上关闭
// ✅ 正确写法：使用 try-with-resources 确定关闭边界
try (InputStreamsafeInput = Files.newInputStream(path)) { // 代码块结束时会自动调用 close
consume(safeInput); // 业务只在资源有效期内读取内容
} // 即使中途抛出异常，关闭动作也会执行
GC 负责回收堆内存；外部资源需要通过 close 等 API 在明确时机释放。
🎤 面试怎么答
面试题一：一个 Java 程序从源码到真正运行，中间经历了什么？
我在面试中会按时间顺序组织。第一步，javac 完成前端编译，把源码转换为包含常量池、方法信息和字节码的类文件；它生成的是 JVM 中间表示，和运行期间的 JIT 编译不是一回事。第二步，java 启动器创建 JVM，找到入口类，依次处理加载、链接和初始化：链接包含验证、准备与解析，其中解析可以延迟，初始化才执行静态初始化逻辑。第三步，JVM 调用 main，每次方法调用建立栈帧，解释器先执行字节码并收集运行信息。第四步，HotSpot 把热点方法或循环分层编译成本地指令，必要时还会反优化。第五步，对象按堆语义分配，GC 依据可达性回收空间；main 返回后，非守护线程还会影响进程退出。
面试官表面在问一条流程，真正考察的是能否串起编译、类生命周期、运行时数据区、执行引擎和 GC，并说明各环节之间的因果关系。加分点：主动区分 JVM 规范与 HotSpot 实现，并说明解析允许延迟、JIT 优化允许失效。
面试题二：JVM 运行时数据区怎么划分，哪些区域由线程共享？
我会先按所有权回答：堆和方法区由线程共享；程序计数器、Java 虚拟机栈以及实现提供的本地方法栈与线程绑定。接着展开栈帧，它包含局部变量表、操作数栈、动态链接信息和方法返回所需状态；每个类或接口都有自己的运行时常量池，该常量池从共享的方法区分配。然后补充 JDK 21 HotSpot：主要类元数据位于本地内存中的元空间，JIT 机器码位于代码缓存，这些实现区域与规范中的方法区不能简单画等号。
面试官真正想确认的是候选人能否把抽象结构用于故障定位。加分点：说明 -Xmx 只约束 Java 堆，进程总内存还包括线程栈、元空间、代码缓存和直接内存；再结合 StackOverflowError、Java heap space、Metaspace 等错误信息定位不同压力来源。
💬 一句话总结
JVM 全景，就是 Java 程序从类加载、字节码执行到内存回收与进程退出的完整生命周期。
