第01章-走近JVM

如果把软件世界比作一座城市，那么Java虚拟机（JVM）就是这座城市底下看不见的基石。它支撑着数十亿行Java代码的运行，默默管理着每一块内存的分配与回收，在后台执行着无数次优化决策。然而，大多数工程师与它的交集，仅限于在 java -version 输出中瞥见一行版本号，这是一种遗憾。JVM并非黑箱，它的设计哲学、架构权衡、性能特性，每一处细节都凝结着编译器作者、系统程序员和架构师们的深思熟虑。理解JVM，不是为了在面试中多背几个概念，而是为了在真实的系统故障中看清因果，在性能瓶颈前做出有根据的判断，在技术选型时拥有真正的洞察力。

本书的一切，都从理解JVM开始。

1.1 虚拟机究竟是什么

1.1.1 从Oak到Java

要理解JVM的诞生，必须回到上世纪九十年代初。1991年，Sun Microsystems内部启动了一个名为 Green 的项目，目标是为消费电子设备开发一种分布式、响应式的编程环境。项目负责人James Gosling带领团队，首先尝试用C++来实现，但很快遇到了一个根本性的困难：消费电子设备的硬件五花八门——有的是Motorola的芯片，有的是Intel的，有的是ARM的变体，每种架构的指令集、寄存器组织、内存模型都不尽相同。如果为每种设备单独编译C++代码，维护成本将是一个无底洞。

这个困境催生了一个革命性的想法：能不能设计一种中间层？即代码先编译成一种与硬件无关的中间表示，再由一个运行在具体设备上的运行时负责将这种中间表示转换为本地机器码执行？这个运行时，就是虚拟机的雏形。Green项目最初为这门语言起的名字不是Java，而是 Oak——橡树，这是Gosling办公室窗外一棵橡树的名称。1995年，由于商标冲突（Oak Technology公司已注册该名称），团队将其改名为Java。

1995年5月23日，Sun在SunWorld大会上首次公开演示了Java技术，并于1996年1月23日发布了JDK1.0正式版（Final）。Java提出的核心价值主张，从一开始就不是一种新语言这么简单，而是一整套运行时承诺：Write Once, Run Anywhere（一次编译，到处运行）。这个口号的背后，是JVM作为抽象硬件的核心定位。

1.1.2 JVM不是模拟计算机

许多初学者对JVM的理解是：它是一台假想的计算机，模拟了CPU、内存、寄存器等全部硬件组件。这个理解不能说错，但容易产生误导。如果你去读JVM规范，会发现其中确实定义了一些虚拟硬件，包括pc寄存器（program counter register）、操作数栈（operand stack）、本地变量区（local variables）等，但这些并不是对真实硬件的完整模拟，一台完整的虚拟计算机模拟器（例如Bochs、QEMU这类全系统模拟器）会模拟整个硬件栈：CPU流水线、分页机制、PCI总线、BIOS中断表……模拟的是一台物理计算机从加电到运行操作系统的全过程。而JVM从不模拟这些，因为它只关心一件事：字节码的执行语义。

JVM规范定义的运行时数据区，有一部分是线程私有的（每个线程独立拥有），有一部分是线程共享的（所有线程共同访问），其中最能体现JVM不是完整计算机模拟器本质的，是 操作数栈 的设计。

在真实的x86架构中，一条典型的加法指令 ADD EAX, EBX 会隐含地将EAX和EBX两个寄存器的值相加，结果放回EAX。这是指令集架构（ISA）的典型模式：操作数来自寄存器，结果写回寄存器。寄存器是CPU内部最快的存储单元，数量有限（x86-64有16个通用寄存器），访问延迟通常在1个CPU周期内。

然而JVM字节码的设计哲学与此截然不同。JVM的字节码指令集大量采用 栈机（Stack Machine） 模式。以两个int相加为例：iload_0、iload_1、iadd、istore_2，其中没有任何指令显式操作寄存器名，所有计算都通过操作数栈（Operand Stack）这一抽象数据结构中转：iload_0把局部变量0压入栈顶，iload_1再压一个，iadd弹出栈顶两个值相加后压回，最后istore_2把结果弹出存入局部变量2。

为什么选择栈机？因为栈机的指令编码更紧凑，不需要编码源寄存器和目标寄存器的编号。一条 iadd 指令只需要1个字节的操作码，没有操作数，而x86的 ADD r/m32, r32 即使在最优编码下也需要2到3个字节（ModRM字节额外编码寻址模式和寄存器）。更重要的是，栈机的指令语义与具体寄存器数量无关。这意味着JVM规范可以完全不关心目标平台有多少个通用寄存器，例如x86有16个，ARM有16个（r0-r15），RISC-V有32个或更多，但字节码的语义保持不变。这正是一次编译，到处运行承诺的技术基础之一。

但这里引出了一个自然的疑问：栈操作在真实CPU上执行效率很低，操作数栈存放在主内存中（尽管JVM规范允许实现将其优化到寄存器），每次 iload、istore、iadd 都可能触发内存访问，性能无法接受。基于这样的考虑，在JVM的实现层面，HotSpot将JVM的操作数栈映射到了真实CPU的寄存器上，将栈机的字节码语义转化为寄存器机的硬件执行，这项工作发生在解释器和JIT（即时编译，Just-In-Time）两个阶段：

解释器阶段：HotSpot解释器用C++编写，原生使用宿主CPU的寄存器。它把操作数栈的逻辑结构映射到几个专用寄存器（如 x86-64上的 rax、rbx、rcx 等），通过寄存器来传递栈顶元素。
JIT阶段：当方法被识别为热点代码后，C1/C2编译器将整个方法编译为本地机器码。JVM的 栈帧结构被展开（unfolded），参数从函数参数寄存器（rdi、rsi等）直接进入计算指令，结果直接放在返回值寄存器（rax），操作数栈的概念在生成的机器码中完全消失。

1.1.3 HotSpot的栈帧展开与寄存器映射

HotSpot VM在执行Java字节码时，经历了从解释执行到JIT编译执行的技术演进。刚启动时，字节码由 解释器（Interpreter） 逐条执行。解释器不是简单地将每条字节码翻译为对应的机器码然后执行，而是维护着一个栈帧数据结构，每个方法调用对应一个栈帧。

栈帧（Stack Frame）是JVM运行时数据区中虚拟机栈的组成单元。当一个线程调用方法A时，JVM在虚拟机栈上为A push一个栈帧。这个栈帧中包含两部分关键数据：本地变量表（Local Variables Table）和操作数栈（Operand Stack）。本地变量表是一个固定长度的数组，索引从0开始，第0位在实例方法中固定存放 this 引用。操作数栈是一个LIFO结构，深度在编译时确定（由javac计算并在class文件的stack_map中记录）。

在解释执行模式下，HotSpot解释器维护着两个指针：locals 指向本地变量表基地址，stack_top 指向操作数栈当前栈顶。每条字节码指令被翻译为一段手写的汇编代码。解释器本身是用C++编写的，它运行在宿主CPU上，原生使用寄存器。但这里的操作数栈是JVM规范意义上的抽象概念，HotSpot的实现会在寄存器中为其分配真实的存储空间。

当JIT编译器介入后，情况发生了质变。HotSpot的 C1编译器（客户端编译器，提供快速启动）和 C2编译器（服务端编译器，激进优化）会将热点字节码方法整体编译为本地机器码。在这个过程中，JVM的 栈帧结构被展开（unfolded），JVM操作数栈和本地变量表中的数据被直接映射到x86/ARM的真实寄存器中。而当C2 JIT编译器接手时，它分析字节码的数据流，将方法整体翻译为x86-64机器码，参数根本没有经过任何栈的中间形态，它们从函数参数寄存器直接被加法指令使用，结果直接放在返回值寄存器中。

HotSpot完成了从栈机模型到寄存器模型的优雅降级，即字节码的栈语义被保留为规范层面的抽象，而物理执行层面始终是寄存器高效的原生代码。这种设计的精妙之处在于分层抽象：JVM规范定义了操作数栈的语义、局部变量表的布局、方法调用的字节码序列；HotSpot的实现解释了如何将这些规范转换为特定硬件上的最优机器码。这种分离使得JVM可以跨越从ARM嵌入式设备到IBM大型机的所有平台，而HotSpot的内部实现始终是针对每个平台深度调优的。

1.2 为什么理解JVM如此重要

1.2.1 从会用到精通之间横亘的鸿沟

Java工程师的成长路径通常有两条截然不同的轨迹。第一条轨迹上的工程师能够熟练使用各种Java API，编写业务逻辑，调用框架的注解和配置，但对JVM的了解仅限于IDE里偶尔瞥见的OOM，他们能够完成业务需求，但当系统出现微妙的性能退化、无法解释的GC停顿时，往往会束手无策。第二条轨迹上的工程师则具备JVM的深层知识，他们看到的是一个运行时世界：字节码的握手协议、堆的分区策略、GC的并发阶段、类加载的可见性规则……这个世界中蕴含着几乎所有疑难杂症的真正答案。这两条轨迹之间的鸿沟，在实际工作中会造成惊人的认知差异。让我们用一个真实的场景来说明。

某团队的Java服务在凌晨0点至2点的业务低峰期出现了一个令人困惑的现象：接口的平均响应时间（RT）从正常的50ms飙升到2000ms以上，但业务监控显示这个时段的请求量反而更低。开发团队首先怀疑是网络抖动或下游依赖服务的降级，但排查后发现下游服务一切正常。团队进而怀疑是数据库连接池泄漏，但连接池指标正常。焦头烂额之际，一位工程师注意到一个细节：故障时间段恰好与每日凌晨1点的 定时全量GC 时间重合。

深入分析后发现：系统使用的是CMS垃圾收集器，配置了 -XX:CMSInitiatingOccupancyFraction=70（老年代占用70%时触发CMS并发垃圾回收周期）。定时任务的逻辑是每天凌晨1点跑一次全量数据重新加载，加载过程中产生大量短期对象，导致老年代迅速增长。当CMS被触发时，需要经历初始标记（Initial Mark）、并发标记（Concurrent Mark）、重新标记（Remark）、并发清除（Concurrent Sweep）等多个阶段。其中初始标记和重新标记阶段需要 Stop-The-World（STW），此时所有Java应用线程会暂停。在高负载时，CMS的重新标记阶段可能需要扫描大量脏卡片（card marking），导致STW时间从预期的几十毫秒暴增到数秒。这位工程师最终通过调整 -XX:CMSScheduleRemarkSamplingInterval=5（增加采样频率）和 -XX:ParallelGCThreads（增加GC线程数）解决了问题，同时优化了定时任务的内存分配模式。

这个案例的意义不在于具体的技术方案，而在于揭示了一个规律：没有JVM知识，工程师看到的只是RT飙升的现象；有了JVM知识，才能看到GC停顿这个原因。从现象到原因的跨越，需要对运行时数据区、垃圾收集器的阶段模型和STW机制有系统性的理解。

1.2.2 OOM的六种面孔

java.lang.OutOfMemoryError 是Java工程师最常遇到的运行时异常之一。然而，这个错误远非单一含义。JVM规范和HotSpot实现定义了至少六种不同类型的OOM，每一种都对应不同内存区域耗尽、不同的成因机制，需要不同的解决方案。能够准确区分这六种OOM，是JVM精通之路上的基础能力。

第一种：Java堆空间溢出（Java heap space）。这是最常见的OOM，发生在对象分配请求无法得到满足时。默认情况下，HotSpot的堆起始大小为物理内存的1/64（通过 -Xms 可设置初始值，-Xmx 可设置最大值）。常见原因包括内存泄漏（对象被错误地持有引用导致无法回收）和内存溢出（业务规模本身超过了堆容量）。分析工具推荐使用 jmap -heap 查看堆的使用详情，配合MAT（Memory Analyzer Tool）进行堆转储分析。典型症状是：大量 HashMap/ArrayList 的持有链，或者静态集合中无限增长的数据。

第二种：GC overhead limit exceeded。这是HotSpot特有的错误，当GC花费的时间超过了配置阈值（默认是98%的时间花在GC上且回收了不到2%的堆内存）时抛出。本质上，这是JVM在检测到投入大量时间进行GC但收效甚微后主动抛出的保护性异常。出现这个错误，往往意味着堆太小或者存在内存碎片化问题——CMS在并发模式失败后可能触发频繁的串行Full GC。配置参数 -XX:-UseGCOverheadLimit 可以禁用这个限制（不推荐），正确做法是增大堆或优化对象分配率。

第三种：Metaspace（元空间）溢出。这是Java 8引入的变革之一：永久代（PermGen）被元数据区域（Metaspace）取代。元空间使用的是本地内存（native memory），而非堆内存。当加载的类数量过多（例如动态代理生成大量类、CGLIB大量增强、热加载框架频繁加载卸载）时，Metaspace 的容量被耗尽。配置参数 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 控制其大小。诊断手段：jcmd pid VM.native_memory summary 可以看到元空间的实际使用量。值得注意的是，元空间默认可以增长到受限于本地进程地址空间的大小，在64位系统上理论上是无限的——但如果遇到本地内存碎片化或地址空间耗尽，仍然会OOM。

第四种：直接缓冲区内存溢出（Direct buffer memory）。当使用 ByteBuffer.allocateDirect() 分配堆外内存（off-heap direct buffer）时，分配的内存属于本地内存而非JVM堆。如果忘记释放（实际上是通过 Cleaner 在GC时异步释放），或者分配速度超过回收速度，就会触发 OutOfMemoryError: Direct buffer memory。这个问题在高并发网络通信场景（Netty、NIO）中极为常见。诊断参数：-XX:MaxDirectMemorySize，默认为堆最大容量。

第五种：线程栈空间溢出（Unable to create new native thread）。严格来说，这不是传统意义上的 OutOfMemoryError，而是 OutOfMemoryError: unable to create new native thread。当JVM向操作系统请求创建新线程但操作系统无法分配足够的栈空间时触发。每个线程的栈大小由 -Xss 参数控制（默认1MB）。常见于：服务器端应用使用线程池时请求了过多线程，或者在循环中无节制地创建线程。关键洞察：这个错误的本质是进程级别的资源耗尽，而非堆内存耗尽。解决思路包括减小 -Xss（但可能引发栈溢出异常）、限制线程池大小、降低线程总数。

第六种：请求数组长度超过JVM限制。当尝试分配一个长度超过 Integer.MAX_VALUE - 2（约21亿）的数组时抛出。这是一种极为罕见的OOM，通常是程序逻辑错误导致的。

这六种OOM的共同点是都抛出 OutOfMemoryError，但成因、诊断思路和解决方案完全不同。能够快速定位到是哪一种OOM，是JVM实战能力的第一道门槛。

1.2.3 JIT优化引入的诡异Bug

即时编译（JIT）是JVM性能的核心引擎。HotSpot的JIT编译器在运行时分析字节码的热点代码，将其编译为高度优化的本地机器码。然而， JIT的激进优化有时会引入在解释执行模式下完全不存在的Bug。这类Bug通常极难复现——它们取决于运行时的工作负载、CPU架构、JIT编译器的优化决策，因而具有高度的非确定性。

一个经典的案例涉及 JIT对边界检查的消除（Bounds Check Elimination）。Java数组访问会自动进行边界检查，超出范围时抛出 ArrayIndexOutOfBoundsException。这是语言层面的安全保证，但边界检查在热点循环中会带来不可忽视的性能开销。JIT编译器在确定索引不会越界时，会消除这些冗余的边界检查，直接生成无检查的机器码。

考虑这样的代码：一个包含数组字段的类，其 sum() 方法循环访问数组元素。JIT编译器在循环内可以推导出 data.length 恒定不变，因此 i < data.length 的边界检查是多余的。这个推导在单线程语义下是正确的。然而，边界检查消除的正确性依赖于编译器能看到的所有代码路径。如果 sum() 方法被JIT内联到另一个类中的调用方，而调用方同时修改了对象的数组引用，那么消除边界检查就可能产生越界访问。这正是逃逸分析与内联决策之间复杂交互的冰山一角。

另一个广为人知的案例涉及 JIT对锁的粗化（Lock Coarsening）和逃逸分析（Escape Analysis）的交互。HotSpot的JIT编译器会分析对象的逃逸范围：如果一个对象仅在单个线程内访问且不会逃逸到方法返回值或跨线程同步中，那么它根本不需要加锁——甚至可以将其分配在栈上而非堆上。但逃逸分析的精度依赖于编译时能看到的代码范围。如果编译器将不同方法分别编译，可能出现：一个编译时认为对象没有逃逸，进行了激进优化；但另一个编译版本中实际上触发了对象的逸出（例如抛出了未捕获的异常，将对象引用泄露到了异常堆栈中）。这类Bug会导致数据不一致或对象状态损坏。

这类Bug的特殊性在于：它们只在JIT编译生效后出现（即需要预热数秒后才可能触发），在JIT关闭（-Xint 模式）下完全消失。这使得复现和诊断变得极为困难——因为在本地开发环境中可能永远无法复现，只有在高并发生产环境中才会触发。

应对这类问题的策略有几个。首先，-XX:+PrintCompilation 可以输出JIT编译日志。其次，-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly 可以输出JIT生成的汇编代码（需要安装hsdis插件）。第三，当怀疑JIT引入Bug时，-Xint（纯解释执行）、-XX:+TieredCompilation 的分层降级（先C1再C2）、或者 -XX:MaxInlineLevel 等参数可以帮助隔离问题。最后，始终记得升级JDK——JIT编译器是JDK中变化最频繁的部分，许多JIT Bug在新版本中已被修复。

1.2.4 性能优化的最后一公里

在分布式系统架构中，工程师们习惯于在API网关层做限流、在服务间加缓存、用异步消息队列削峰填谷。这些手段解决的是系统架构层面的性能问题。但当这些问题都被排除之后，系统仍然可能会慢，此时瓶颈往往下移到单个JVM进程内部。

这就是我所说的性能优化的最后一公里：在所有宏观架构优化都完成后，JVM内部的运行效率决定了系统性能的上限。这个层级的优化包括：

GC优化。选择合适的垃圾收集器（G1、ZGC、Shenandoah），调优代际大小（-Xmn、-XX:NewRatio），调整GC线程数（-XX:ParallelGCThreads），设置合理的停顿时间目标（-XX:MaxGCPauseMillis）。在低延迟交易系统中，GC停顿是SLA违约的首要原因。

JIT编译优化。通过设置合适的JIT编译阈值（-XX:CompileThreshold），利用分层编译（Tiered Compilation）实现启动速度与峰值性能的平衡，在某些场景下甚至可以通过 @Contended 注解减少伪共享（False Sharing）。

内存布局优化。理解对象头大小（在64位JVM中，一个普通对象的头部占用12字节，加上对齐填充后是16字节的倍数）、数组的内存开销，选择合适的数据结构，减少对象数量。

锁优化。利用JVM内置的偏向锁（Biased Locking）、轻量级锁（Thin Lock）和自适应自旋（Adaptive Spinning）机制，或者使用 java.util.concurrent 包中的无锁数据结构，将热点的有争议锁转化为无锁操作。

没有JVM知识，这些性能优化都无从谈起；有了JVM知识，才能在Profiler的火焰图（Flame Graph）上准确找到热点，在GC日志中解读吞吐量和停顿时间的权衡，在字节码层面理解为什么某些写法的Java代码反而产生了更多的对象分配。

1.3 硬件视角下的JVM设计哲学

1.3.1 CPU三级缓存架构

JVM的运行时数据区划分（线程私有区域 vs 线程共享区域），乍看之下是软件设计的抽象，但深挖下去，会发现它的每一个决策都精准地契合了现代CPU的硬件特性。理解硬件，是理解JVM设计哲学的钥匙。

现代多核CPU的缓存架构通常分为三级：L1 Cache（最接近CPU核心，访问延迟最低）、L2 Cache（中等距离，中等延迟）、L3 Cache（所有核心共享，最后一级的统一内存视图）。

以Intel Haswell架构作为具体参照（数据来源于Agner Fog的《Instruction Tables》以及Intel官方优化手册），各层级缓存和内存的访问延迟如下（不同型号可能差异较大）：

L1 Data Cache：32KB每核心，访问延迟约4周期，约1.3纳秒。

L2 Cache：256KB每核心，访问延迟约12周期，约4纳秒。

L3 Cache：共享约20MB（取决于型号），访问延迟约34-50周期，约11-16纳秒。
内存（DRAM）：视配置，通常8-64GB，访问延迟约200-300周期，约70-100纳秒。

这些数字背后的含义至关重要。从L1到内存，延迟相差约50到100倍。这意味着，如果程序的数据访问具有良好的局部性（一次访问后，后续访问同一数据或相邻数据），数据很可能停留在L1中，性能优异；但如果数据访问分散、跳跃，大量数据将穿透到主内存，程序性能将退化一到两个数量级。

1.3.2 线程私有区域

JVM中，线程私有区域包括：虚拟机栈（VM Stack）、本地方法栈（Native Method Stack）、程序计数器（PC Register）。这些区域每个线程独立拥有，不与其他线程共享，因而永远不存在并发修改的问题。

程序计数器是一个较小的内存区域（通常一个字宽，64位系统上8字节），记录着当前线程正在执行的字节码指令地址。如果当前执行的是Native方法（通过JNI调用C/C++代码），则程序计数器的值为undefined——这是JVM规范中少数几处undefined之一，原因是Native方法不在JVM的掌控之下，执行流完全由本地代码支配。

虚拟机栈保存着方法的栈帧。当方法A调用方法B时，A的栈帧在栈上，B的栈帧被push到A的栈帧之上。每个栈帧包含局部变量表和操作数栈。局部变量表的大小在编译时确定（记录在class文件的code属性中），因此栈帧的内存大小是固定的。这意味着栈内存的分配和回收不需要复杂的垃圾收集——只需要移动栈指针即可，分配效率接近O(1)，且无需任何锁，因为每个线程只访问自己的栈。

从缓存的角度看，线程私有区域的访问模式具有极强的空间局部性（Spatial Locality）：一个方法执行时，它的数据（局部变量、操作数栈）高度集中在栈顶附近的几百字节内。这正是CPU缓存最喜欢的访问模式。栈上数据一旦加载到L1/L2缓存，就能在整个方法执行期间被高效地复用。在x86-64上，栈顶指针（RSP/RBP寄存器）附近的128字节（即两个cache line）通常会被预取到L1缓存中。

-Xss 参数控制每个线程的栈大小，默认值为1MB（Oracle JDK），OpenJDK可能不同。这意味着：如果创建1000个线程（并非罕见——每个HTTP请求一个线程的旧式服务器），仅栈内存就要消耗约1GB的虚拟地址空间。物理内存的实际消耗取决于这些栈是否被完全使用（Linux的栈是lazy commit的，只有实际使用的页才消耗物理内存）。

1.3.3 线程共享区域

线程共享区域包括堆（Heap）和方法区（Method Area）。这些区域被所有Java线程共享，因此需要面对并发访问的挑战——尤其是并发写入时的缓存一致性（Cache Coherence）问题。

当多个CPU核心同时运行Java线程时，每个核心都有自己的L1和L2缓存。堆中的对象可能被线程A和线程B同时持有引用。如果两个线程都在自己的缓存中修改了同一个HashMap的内部状态，缓存一致性协议必须确保两个核心最终看到一致的数据。

x86/x64架构使用 MESI协议（Modified, Exclusive, Shared, Invalid）及其变体（MOESI、MESIF）来维护缓存一致性。这个协议的工作原理如下：当核心1想修改一个缓存行（Cache Line，CPU缓存的最小分配单元，通常为64字节）中的数据时，如果该缓存行在其他核心的缓存中处于共享状态，核心1必须先发送一个 RFO（Request For Ownership）广播消息，将其他核心缓存中的对应行置为Invalid，然后才能修改。这个广播和等待的过程涉及CPU之间的互连网络，延迟可能在数十到数百个CPU周期之间。

这直接解释了为什么在多线程程序中，错误的同步策略会导致性能急剧下降。一个频繁访问的共享对象会导致所有访问它的CPU核心不断在缓存行上产生竞争——每次写操作都可能触发RFO，造成伪共享（False Sharing）：两个线程实际上访问的是完全不同的数据，但它们碰巧落在同一个64字节缓存行内，导致每次写操作都触发跨核心缓存同步。

JVM为此提供了几个工具。@Contended 注解（JDK 8引入）在对象字段之间插入填充（padding），确保被注解字段独占一个缓存行，从而避免与其他字段的伪共享。需要注意的是，@Contended 默认只在JVM内部类上生效，用户类需要通过 -XX:-RestrictContended 参数解锁。此外，JVM本身的许多关键数据结构（如 ObjectMonitor——synchronized锁的底层实现）大量使用手动填充来避免伪共享。

1.3.4 NUMA架构与ZGC的NUMA感知

现代大规模服务器通常采用 NUMA（Non-Uniform Memory Access，非均匀内存访问）架构。在一个典型的双路服务器上，每个CPU插槽（socket）有自己的本地DRAM内存，访问本地内存的延迟远低于访问另一个插槽的远程内存。举例来说：访问本地内存延迟约为70-100纳秒，访问远程内存延迟可能达到150-200纳秒——延迟翻倍，但带宽未必降低（远程访问走QPI/UPI总线，带宽可能与本地内存相当）。

传统的JVM GC设计（如Parallel GC、CMS）默认假设内存访问是均匀的（Uniform Memory Access，UMA），将整个堆视为一个统一的地址空间。但在NUMA环境下，这导致了次优的内存分配策略：如果一个线程在Socket 0上运行，但JVM分配的堆内存页面实际映射到Socket 1的DRAM上，那么每次堆访问都是在跨插槽访问，延迟显著增加。

ZGC（Z Garbage Collector）在JDK 11中作为实验特性引入，JDK 15成为生产就绪，其设计哲学从一开始就将NUMA感知作为核心特性。ZGC使用着色指针（Colored Pointers）和读屏障（Load Barrier）实现了并发压缩，GC过程中几乎不需要STW停顿。更为关键的是，ZGC的堆分配器会优先在当前线程所在的NUMA节点上分配内存。

ZGC的NUMA支持通过参数 -XX:+UseNUMA 开启（需要与 -XX:+UseZGC 配合）。当启用后，ZGC在分配页面时调用操作系统的NUMA API（如Linux的 mbind() 和 set_mempolicy()），将内存页面绑定到请求线程所在的节点上。对于生命较短的对象（通常在年轻代），这确保了它们被分配在快速访问的本地内存上。

从硬件到软件这条线上，NUMA感知是一个极好的案例，它展示了JVM如何利用硬件拓扑信息来优化内存布局决策。理解NUMA的存在，就能理解为什么在大型JVM进程（堆内存几十GB以上）中，不感知NUMA的GC可能导致莫名其妙的内存够但GC特别慢的现象。

1.3.5 内存访问的局部性原理

贯穿JVM设计哲学的一条暗线是局部性原理（Principle of Locality），包括时间局部性（Temporal Locality）和空间局部性（Spatial Locality）。时间局部性指的是：一个数据被访问后，近期内很可能再次被访问（例如循环计数器、热点方法中的局部变量）。空间局部性指的是：一个数据被访问后，其附近的数据很可能即将被访问（例如数组元素、对象相邻字段）。

JVM的许多设计决策都在主动创造和利用局部性。

对象在堆中的排列是一个关键因素。HotSpot的GC在分配对象时，优先在TLAB（Thread Local Allocation Buffer）中分配。TLAB是每个线程预先从堆中申请的一小块专属区域，之后线程在自己的TLAB中分配对象就不需要与其他线程进行同步（避免了分配时的锁竞争）。更重要的是，TLAB中的对象在物理上彼此相邻，访问它们具有良好的空间局部性。

G1 的Region设计也体现了局部性思想。G1将堆划分为大量的小区域（Region），每个Region可以独立作为Eden、Survivor或Old区。G1的GC收集算法会优先收集那些垃圾密度高的Region，即单位空间内回收内存最多的Region。这种策略天然倾向于选择存活数据少、局部性好的Region，减少了GC期间需要复制和移动的数据量。

JIT编译器的循环展开（Loop Unrolling）和向量化（Vectorization）是另一个利用局部性的场景。当JIT编译器发现一个循环访问数组的相邻元素时，它可能将多个循环迭代合并为一条SIMD指令，在单个CPU指令中处理多个数据元素。这不仅减少了循环开销，更重要的是：它将原本分散的内存访问合并为一次连续内存访问，完美契合了空间局部性的硬件优势。

1.4 JVM的整体架构图景

1.4.1 字节码

理解JVM架构，最直观的入口是从字节码开始。Java字节码（Bytecode）是JVM的机器语言，它是一种介于源代码和本地机器码之间的中间表示，由Java编译器（javac）根据.java源文件生成，存储在.class文件中。

一个.class文件是一个严格的二进制格式，包含：魔数（0xCAFEBABE，自1995年Java诞生以来从未改变）、版本号、常量池、访问标志、类/父类/接口信息、字段表、方法表、属性表。其中常量池是最复杂的部分——它包含了所有字面量（字符串常量、整数、浮点数）和符号引用（类名、方法名、字段名、类型描述符），相当于一个巨大的符号表。属性表在Java 5引入泛型后变得尤为重要，Signature 属性记录了泛型的擦除后签名，Code 属性包含了方法体的字节码，StackMapTable 属性记录了字节码中各位置的类型信息，用于字节码验证器的快速校验。

理解字节码的格式，对于阅读JVM规范和理解反编译工具（如javap）的输出至关重要。 javap -c -p 是一个经常使用的命令，它可以输出每个方法的字节码指令序列及其助记符。

1.4.2 类加载器子系统

字节码文件只有被类加载器子系统加载到JVM中，才能成为运行时的一部分。类加载器子系统是JVM架构中最复杂的组件之一，它不仅负责定位和加载二进制字节码，还涉及验证、准备、解析等环节。

类加载的全过程分为五步：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）。这五步按顺序发生，其中验证、准备、解析合称为链接（Linking）阶段。

加载阶段的核心任务是：通过一个类的全限定名（Fully Qualified Name）找到定义此类的字节码文件，并将其转换为运行时方法区中的数据结构。JVM中内置了三层类加载器：BootstrapClassLoader（启动类加载器，用C++实现，负责加载JAVA_HOME/lib目录下的核心类库如rt.jar）、ExtClassLoader（扩展类加载器，负责加载JAVA_HOME/lib/ext目录下的扩展包，在 JDK9之后已经改名为 PlatformClassLoader（伴随 JPMS引入））、AppClassLoader（应用程序类加载器，负责加载classpath上的类）。三层加载器之间存在父子关系（不是继承关系，而是组合关系），形成了双亲委派模型（Parent Delegation Model）：当一个类加载器收到加载请求时，它首先将请求委派给父类加载器处理，只有父类加载器无法完成时，才自己尝试加载。双亲委派模型的核心价值在于安全，例如，用户编写了一个 java.lang.String 类，试图替换核心类库中的String类，但因为类加载器的查找顺序，永远只会加载到BootstrapClassLoader加载的核心String类，从而避免了安全隐患。
验证阶段确保字节码文件的格式正确且不危害JVM安全。验证过程包含四个子阶段：文件格式验证（魔数、版本号等）、元数据验证（是否有父类、是否继承了不允许继承的类等）、字节码验证（控制流、数据流分析，确保字节码指令不会导致虚拟机崩溃或越权操作）、符号引用验证（被引用的类、方法、字段是否存在且有访问权限）。
准备阶段为类的静态变量分配内存并设置默认值。注意这里是设置默认值，而不是初始值。例如，public static int value = 123 在准备阶段会被初始化为0（int的默认值），而不是123。123的赋值发生在初始化阶段（clinit方法中）。
解析阶段将符号引用替换为直接引用。符号引用是常量池中的CONSTANT_Class_info、CONSTANT_Methodref_info等，它们只是字符串形式的符号名称；直接引用则是指向方法区中目标数据的指针或句柄。如果符号引用指向一个类，而这个类还没有被加载，则先触发该类的加载（这就是为什么JVM在运行时会按需动态加载类）。
初始化阶段执行类的初始化方法 clinit。这是JVM第一次主动使用一个类时发生的最后一步。clinit 由javac自动生成，包含了所有静态变量赋值语句和静态代码块的代码。类的初始化是线程安全的，JVM内部实现了类初始化的锁机制，确保只有一个线程执行类的初始化代码。

1.4.3 运行时数据区

运行时数据区是JVM中内存管理的核心区域，其设计体现了对不同数据类型访问模式的深刻理解。

堆（Heap）是JVM管理的最大一块内存区域，被所有线程共享。几乎所有的对象实例和数组都在堆上分配（逃逸分析技术可以在满足特定条件下将对象分配在栈上，但这是JIT的优化手段而非语言规范）。堆又分为年轻代（Young Generation）和老年代（Old Generation），年轻代进一步细分为Eden区和两个Survivor区（通常称为S0和S1或From和To）。这种分代设计的依据是：大多数对象的生命周期非常短，大量研究表明，超过90%的对象在创建后很快变得不可达，只有少数对象存活较长时间。分代垃圾收集策略使得GC可以针对不同代际采用不同的收集算法：年轻代使用复制算法（Minor GC，开销小但频率高），老年代使用标记-清除或标记-整理算法（Full GC，开销大但频率低）。

方法区（Method Area）也是线程共享区域，用于存储类的元数据信息：类的结构信息（字段、方法、继承关系）、运行时常量池（字面量和符号引用的存储地）、JIT代码缓存（热点代码的编译结果存储在这里）、字符串常量池（interned strings）。在Java 8之前，方法区的实现是永久代（PermGen），一个使用堆内存的固定大小区域。这带来了一个问题：永久代大小难以调优，太小容易抛出PermGen OOM，太大则浪费堆空间。Java 8用元空间（Metaspace）彻底替代了永久代：元空间使用本地内存，不再占用堆内存，默认大小只受进程地址空间限制（理论上可达64位系统的整个虚拟内存空间）。

虚拟机栈（VM Stack）和本地方法栈（Native Method Stack）都是线程私有的，每个线程创建时都会同步分配。虚拟机栈服务于Java方法调用，每个方法调用对应一个栈帧；本地方法栈服务于Native方法（JNI调用），其行为与虚拟机栈类似。在HotSpot中，本地方法栈和虚拟机栈是合并实现的。

程序计数器（PC Register）上文已述，此处不再重复。

1.4.4 执行引擎

执行引擎负责执行字节码指令，它的工作方式经历了从纯解释执行到JIT编译执行的演进过程。

解释器（Interpreter）是JVM启动后最早的执行引擎。它逐条读取字节码指令，将其翻译为对应平台的本地机器码并执行。解释器的启动速度极快，不需要等待JIT编译，但执行效率相对较低，因为每条字节码都需要重复翻译。HotSpot的解释器是用C++手写的，每条字节码对应一段C++代码（称为TemplateTable），这段C++代码再被编译为本地机器码。

当解释器发现某个方法被频繁调用（热点代码）时，会触发JIT编译。JIT编译器（即时编译器）将整个方法的字节码一次性编译为本地机器码，之后对该方法的调用将直接执行编译后的本地代码，而不需要重复解释。

HotSpot内置了两个JIT编译器：C1和C2。

C1（Client Compiler）专注于快速编译和较低的计算资源消耗，适用于对启动时间敏感的应用。C1的编译策略相对保守，优化级别较低，但编译速度快（通常在毫秒级完成），因此第一次编译的等待时间较短。

C2（Server Compiler）采用激进优化策略，包括内联（Inlining）、逃逸分析（Escape Analysis）、循环展开（Loop Unrolling）、向量化（Vectorization）、常量折叠（Constant Folding）等数十种高级优化。代价是编译时间较长（可能达到秒级），但编译产出的代码性能极高。C2的优化基于sea-of-nodes IR（中间表示），这是一种将程序表示为节点图的高级编译器内部形式，能够进行更全局、更激进的优化分析。

分层编译（Tiered Compilation）在JDK 7中引入，JDK 8默认开启。它将解释执行和JIT编译结合起来：方法首先被C1快速编译，以减少解释执行的性能开销；在方法热度进一步上升后，再由C2进行更彻底的优化编译。这种策略实现了启动速度与峰值性能的双赢。

1.4.5 垃圾收集器与执行引擎的协作

垃圾收集器（GC）并不属于执行引擎的一部分，但它与执行引擎紧密协作，共同保障JVM的内存管理和运行效率。

执行引擎负责创建对象，每当我们用new关键字创建一个Java对象时，执行引擎向堆发出分配请求，GC负责回收不再使用的对象所占用的内存。两者之间的协作点是：对象的分配发生在TLAB（线程本地分配缓冲）中，分配本身是执行引擎向堆索取内存的动作；而当GC触发时，执行引擎的所有线程都需要暂停（STW），等待GC完成。

现代GC的设计越来越注重与执行引擎的协同效率。以ZGC为例，它使用了读屏障（Load Barrier），一种在执行引擎读取对象引用时插入的轻量级检查机制。当Java代码读取一个对象的引用时，读屏障会检查该引用是否指向正在被迁移的对象，如果引用指向的对象正在迁移，读屏障会协助更新引用为目标对象的新地址。这个过程对Java代码完全透明，同时对执行引擎的内存访问增加了一个极小的额外开销（通常在1纳秒级别）。这就是ZGC能够在几乎零停顿的情况下完成并发压缩的关键：它将复杂的工作分散到了每一次普通的内存访问中，而不是要求执行引擎完全暂停。

1.5 全书知识地图

1.5.1 JVM知识体系的倒置大树

如果将JVM的知识体系比喻为一棵树，那么执行引擎是这棵树的根，所有代码最终都在执行引擎中运行。执行引擎从字节码开始，通过解释器和JIT编译器将字节码转化为机器码并执行。执行引擎的运行依赖于运行时数据区提供的内存结构，而运行时数据区中的对象生命周期的管理则由垃圾收集器负责。类加载子系统则源源不断地将新的字节码类加载到运行时数据区中，为执行引擎提供新的执行任务。

这棵树的枝叶则延伸向各个具体的技术细节：执行引擎层面包括解释器、JIT编译器（C1/C2）、方法内联、逃逸分析、锁优化等；运行时数据区层面包括堆的分区（Eden/Survivor/Old）、TLAB、Metaspace、线程栈等；垃圾收集器层面包括Serial GC、Parallel GC、CMS、G1、ZGC、Shenandoah等，以及各种GC算法（复制、标记-清除、标记-整理）；类加载子系统层面包括双亲委派模型、自定义类加载器、OSGI、热部署等；字节码层面包括字节码指令集、javap工具、ASM库、Byte Buddy等。

这种树状结构意味着：学习JVM不应该从树叶开始，而应该从树根开始。当你对执行引擎如何执行字节码有了清晰的理解，再去看运行时数据区的分区设计，就能理解为什么需要分代；理解了分代，就能理解为什么需要不同的GC算法；理解了GC算法，就能理解为什么会有那么多种GC收集器。每一步都是有因果的，而不是孤立的知识点。

1.5.2 为什么这些部分必须放在一起理解

JVM各个子系统之间不是孤立的，它们深度交织、相互影响。

类加载与运行时数据区：类加载的输出直接影响运行时数据区的内容。每加载一个类，它的元数据信息就进入方法区；每创建一个对象，它就在堆中占用空间。如果类加载器不断加载新类（例如热部署场景），Metaspace会持续增长；如果不断创建对象，堆会持续增长。两者的边界虽然不同，但都会受到整体进程内存的限制。

GC与执行引擎：GC算法直接影响执行引擎的停顿行为。如果选择G1，STW停顿通常在可配置的毫秒级别；如果选择ZGC，STW几乎为零但读屏障会增加每个引用读取的开销；如果选择Serial GC，停顿可能长达数百毫秒但完全没有读屏障开销。这些权衡没有绝对的好坏，只有场景的匹配。

JIT与内存布局：JIT编译器的逃逸分析可以直接影响对象的分配位置，未逃逸的对象可能被栈上分配（完全消除GC压力）或者标量替换（对象的字段被拆解为分散的局部变量，不再占用连续的堆空间）。理解这一点，就能理解为什么某些microbenchmark中看起来创建了很多对象的代码，实际运行时可能根本没有触碰到堆。

字节码与类加载：字节码是类加载的输入格式。理解字节码才能理解类加载器实际上在做什么，它不仅是在加载一个类，而是一个包含丰富元数据的类结构。那些被混淆或动态生成的字节码，只有理解其原始结构才能进行有效的安全审计和性能分析。

1.6 如何阅读本书

1.6.1 本书的假设读者

本书假设你已经是一名能够熟练使用Java的工程师，你知道如何使用集合类、如何处理异常、如何使用多线程并发编程。你不一定了解这些工具的底层实现，但你对它们的使用场景有足够的直觉。本书的目标是将这种直觉升级为深度理解：让你不仅知道怎么用，还能理解为什么这样设计，以及在遇到问题时如何系统性地分析。

本书不要求你有任何JVM或操作系统的基础知识，本书会在必要的地方提供背景介绍。但如果你有C/C++或系统编程的背景，理解JVM的内部机制会更为顺畅，因为JVM本质上是用C/C++编写的系统软件，许多概念（指针、内存布局、调用约定、CPU缓存）对于有系统编程经验的读者来说是直观的。

1.6.2 本书的结构逻辑

本书按照从顶层到底层的顺序组织内容，大致对应JVM从输入到执行的完整链路：

第一章提供全局视角，建立JVM的整体架构图景。
第二章深入字节码，理解JVM的机器语言，为你提供分析JVM行为的基础工具。
第三章讲解类加载子系统，从源码到运行时的转换过程。
第四章分析运行时数据区，理解JVM如何管理不同类型的内存。
第五章探讨垃圾收集器，理解对象生命周期管理的各种策略权衡。
第六章讲解执行引擎，理解从字节码到机器码的翻译与优化过程。
第七章是综合实战，分析真实的JVM性能问题和故障案例。

这种顺序不是绝对的。实际上，当你在阅读后面的章节后，再回过头来看第一章，会有恍然大悟的感受，所以，本书推荐按图索骥而非线性阅读。

1.6.3 推荐阅读方式

方式一：按图索骥式。先通读一遍本书，了解全貌；然后在遇到具体问题时，带着问题回到相关章节深入阅读。这种方式适合时间有限但需要建立系统性框架的读者。

方式二：线性深耕式。从头到尾逐章阅读，每章都做笔记和实践。这种方式适合时间充裕、想要系统学习的读者，但需要注意的是：JVM是一个需要动手实践才能真正理解的领域，每学到一个概念，最好用jinfo、jstat、jstack、jmap、jhat、jcmd等工具在本地JVM上进行验证。

方式三：问题驱动式。不从头读，而是先翻到感兴趣的章节；当你遇到某个具体的JVM问题时（例如OOM、GC停顿、JIT编译问题），直接查阅相关的章节。这种方式适合有经验的工程师作为参考手册使用。

无论你选择哪种方式，请记住一点：理解JVM没有捷径，需要大量的实践和思考。阅读本书只是起点，真正的理解来自于你在真实系统上观察JVM的行为、分析GC日志、反汇编JIT输出、测量不同配置的performance差异。本书的每一个知识点，都值得你在本地环境中亲手验证。

延伸思考

思考一：JVM的寄存器抽象模型与物理寄存器之间的映射，涉及到HotSpot的C1和C2编译器的优化决策。在实际运行中，哪些因素会影响JIT编译器将操作数栈映射到真实寄存器的效率？例如，一个方法中的局部变量数量超过了可用物理寄存器数量时，会发生什么？

思考二：双亲委派模型是JVM安全体系的重要基石，但某些场景下（如OSGI、热部署、自定义类加载器）需要打破双亲委派。如果让你设计一个能够动态替换JDK核心类的机制，你会如何设计？这个设计会面临哪些安全性风险？

思考三：在NUMA架构下，ZGC的NUMA感知通过优先在本地节点分配内存来降低延迟。但随着时间推移，不同节点的内存使用可能变得不均衡。ZGC是如何处理这个问题的？这种NUMA感知的分配策略对GC的并发压缩算法有什么额外的要求？

openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

Docker 从零到精通：知识与跨平台使用指南

openEuler 社区

关于cpu在进程切换时的操作

保存正在运行的进程的cpu主模块中各个寄存器。操作系统内核中，进程切换通过cpu辅助模块。就是栈的地址，数组第一个元素就是栈底，后面。cpu主模块的寄存器值就保存在进程结构体的。操作系统内核中，每个进程结构体。储存了进程的所有信息，其中就有栈的地址，进程结构体中栈可以通过大数组实现，数组名。也就是进程结构体中的数组中。可以往数组里不断的加数值，也就是入栈。通常也被称为内核栈。关于cpu在进程切换时