【JVM 深度笔记】《深入理解 Java 虚拟机》第 3 版

#

说明：这是一份「【JVM 深度笔记】」，基于周志明老师《深入理解 Java 虚拟机》第 3 版 + 自身实战经验 + 部分网络资料整理而成。
目标是做一份高密度、可落地、能反复查阅的 JVM 笔记，而不是逐章翻译原书。强烈建议配合原书阅读。

（一）前言与整体认知

#

1.1 为什么要写这份 JVM 深度笔记？

#

很多 Java 开发都有类似感受：

• 面试时：
  • “JVM 内存结构？”
  • “GC 原理？”
  • “说一下 JMM 和 volatile？”
    似懂非懂，背得出来，解释不顺畅。
• 工作中：
  • 线上一 OOM，只会 -Xmx 调大一点再重启；
  • GC 日志满屏英文，看到 Full GC 只会慌，不知道该看哪行；
  • 线程池、缓存一多，堆、元空间、直接内存谁在涨说不清；

而《深入理解 Java 虚拟机》是 JVM 方向的“黄埔军校”，但完整从头看到尾，对很多人来说又比较“重”：

• 信息密度大，一遍读完很难形成体系化认知；
• 很多细节在当前工作阶段暂时用不到；
• 看完一遍，不做总结，三个月后几乎全忘。

所以这份笔记想解决三件事：

1. 建立一张 JVM 的“大地图”

   • 读完系列后，你脑中应能画出 JVM 的主要组成与核心流程：
     • 类加载 → 字节码执行（解释 + JIT）→ 内存与对象 → GC → 监控与调优
   • 碰到问题能快速定位是类加载问题 / 内存问题 / 并发问题 / GC 问题。

2. 把“能背”变成“能用”

   • 不只是记住“JVM 有堆、栈、方法区……”，而是搞清：
     • OOM 到底是哪个区？
     • 为什么有的 OOM 调大堆没用？
     • 看到一段 GC 日志，能大致判断“正常/异常”。

3. 帮你从“框架驱动开发”走向“虚拟机驱动优化”

   • 不再只是“Spring / MyBatis 会用就行”，而是知道：
     • 框架大量使用反射 / 动态代理 / CGLIB 对类加载和元空间有什么影响？
     • 高并发下，对象分配方式、逃逸分析、GC 类型对延迟有何影响？
     • 容器化部署时，JVM 和 Docker 的内存限制是怎么“互相伤害”的？

简单说：
这份笔记不是“看过这篇就不用看原书”，而是：

• 帮你在读书前先有一张地图；
• 读书中随时有一份“精华索引”；
• 读书后做查阅和实战的“备忘录”。

1.2 如何高效使用这份笔记？（学习路线 & 实战建议）

#

不同阶段的读者，使用方式会不一样。

1）根据自己阶段选择阅读深度

#

可以粗分三类读者：

a. 0～1 年：刚入职 / 校招生

#

• 建议重点：
  • 第 2 章：JVM 整体架构
  • 第 3 章：运行时数据区（堆、栈、方法区）
  • 第 8 章：GC 基础概念
• 目标：
  • 面试时能成体系地讲 JVM 基础；
  • 大致听懂项目里别人聊的“堆内存”、“GC”、“OOM”是什么意思。

b. 1～3 年：日常写业务，开始接触性能、问题排查

#

• 建议重点：
  • 第 3、5、6、7、8、9、10、12 章
  • 尤其是：内存结构、对象创建 & 布局、JMM、GC、调优、诊断工具
• 目标：
  • 遇到 GC 日志、堆转储、线程栈，不再完全陌生；
  • 能配合 SRE / 运维一起解决一些常见内存与性能问题。

c. 3 年以上：希望在性能、架构方向更进一步

#

• 建议重点：
  • 全部章节，尤其：
    • JIT、锁优化、G1/ZGC、容器化下的 JVM、JDK 版本演进
• 目标：
  • 设计系统时，天然会考虑：
    • 对象生命周期
    • 内存占用和 GC 模式
    • 高并发下的锁竞争和内存可见性
  • 面对线上疑难问题时，有自己的分析路径，而不是瞎试参数。

2）推荐的使用方式：三遍法

#

第一遍：快速通读 + 只记“大图”

• 用 1～2 天把整个系列快速刷一遍；
• 不纠结每一条参数、每一种收集器细节；
• 重点在于搞清楚：“有哪些东西？”、“大概长什么样？”。

第二遍：带着问题 + 结合原书和实战

• 选自己当前最相关的几个主题做“重点突破”，例如：
  • 最近碰到了内存问题 → 集中看：第 3 / 8 / 9 / 10 / 12 章；
  • 最近在做高并发接口优化 → 集中看：第 3 / 6 / 7 / 9 / 11 章；
• 每看完一小节，做几件事：
  • 打开原书对应章节快速对照；
  • 在本地写几段小代码 + 命令行工具验证：
    • 用 javap -v 看编译结果；
    • 用 jmap / jstack / jstat 监控一次小 demo。

第三遍：查阅式 + 做自己的“项目备忘录”

• 以后再遇到问题时，回到这份笔记直接查对应部分；
• 根据自己公司的业务特点，逐渐把：
  • 常用 JVM 参数
  • 常见 GC 日志模式
  • 自己遇到过的几个经典问题
    记在笔记的边上或尾部，形成你的“组织知识”。

3）关于 JDK 版本与环境的建议

#

阅读和实践时，尽量做到：

• 明确自己当前主要用的 JDK 版本
  • JDK 8 仍然是很多公司的主力；
  • 新项目尽量向 JDK 11+ 甚至 17 LTS 看齐；
• 本系列会区分：
  • JDK8 时代：PermGen、CMS、默认 GC 是 Parallel
  • JDK11+：无 PermGen，默认是 G1，ZGC / Shenandoah 逐渐成熟
• 建议本地至少准备两个 JDK：
  • 一个 JDK8（看大量旧资料、旧项目兼容性）
  • 一个 JDK11 / 17（理解新 JVM 的默认行为）

1.3 JVM 在 Java 生态中的定位：一次编写，到处运行的“根基”

#

我们每天写的 .java 文件，到线上机器上到底经历了什么？

从 1 万米高度看，一条最简版的路径是：

flowchart LR
    A[.java 源码] --> B[javac 编译]
    B --> C[.class 字节码]
    C --> D[JVM<br/>（类加载器 + 执行引擎 + GC）]
    D --> E[操作系统]
    E --> F[硬件 CPU / 内存]

1）“一次编写，到处运行”是怎么做到的？

#

核心思路其实就一句话：

把平台相关性压到 JVM 实现里，把 Java 程序本身和平台解耦。

• Java 源码经过 javac 编译成 .class（字节码）；
• 字节码本身是平台无关的，只依赖于JVM 规范；
• 具体跑在哪个平台（Linux / Windows / ARM / x86），取决于对应平台上的 JVM 实现是否遵守同一套规范。

所以：

• 只要有一套遵守 JVM 规范的实现（HotSpot / OpenJ9 / Azul Zing…），
• 不同操作系统、不同 CPU 架构上写的 Java 程序就可以不改动源码就运行。

JVM 在这里扮演的角色更像：

• 操作系统之上的“虚拟操作系统”：
  • 提供自己的内存模型、指令集（字节码）、对象模型、异常机制；
• 同时又充当：
  • 语言运行时（Runtime）：负责类加载、解释/编译执行、自动内存管理（GC）。

2）JVM 在 Java 技术栈中的位置

#

再往下细化一点，会是这样的一个生态图：

flowchart TB
    subgraph Lang[语言层]
        A1[Java]
        A2[Kotlin]
        A3[Scala]
        A4[Groovy]
    end

    subgraph JVM[JVM（虚拟机规范 + 实现）]
        B1[类加载子系统]
        B2[执行引擎<br/>（解释器 + JIT）]
        B3[运行时数据区<br/>（堆、栈、方法区...）]
        B4[GC 子系统]
        B5[JNI / FFI]
    end

    subgraph Lib[类库 & 框架]
        C1[JDK 标准库]
        C2[Spring 全家桶]
        C3[Netty]
        C4[各类中间件客户端]
    end

    subgraph OS[操作系统 & 硬件]
        D1[Linux / Windows / macOS]
        D2[CPU / 内存 / IO]
    end

    A1 --> JVM
    A2 --> JVM
    A3 --> JVM
    A4 --> JVM

    JVM --> Lib
    Lib --> OS
    JVM --> OS

从这张图你可以得到几个直觉：

1. 不止 Java 在用 JVM
   • Kotlin / Scala / Groovy 等大量 JVM 语言，都是编译成字节码再给 JVM 执行。
   • 所以搞清 JVM，不只是为了 Java，也是在理解整个JVM 语言家族。
2. 框架跑得快不快，底层都要算到 JVM 头上
   • Netty 调优、Redis 客户端性能、Spring Boot 启动速度……
   • 真正的底层瓶颈往往是：GC 频率过高、对象分配过多、锁竞争激烈、JIT 未生效等。
3. JVM 是“性能和稳定性”的最后一道大门
   • 当你在业务层、SQL、缓存都优化得差不多后：
     • 想再压榨性能，就绕不过 JVM；
     • 想排查疑难线上问题，也绕不过 JVM。

1.4 从“会写 Java”到“会用 JVM”要补的三门课

#

很多人都有这种感受：

“我业务写得还行，Spring 也很熟，但总觉得对 JVM 很虚。”

其实从“会写 Java”到“会用 JVM”，可以拆成三条相对清晰的主线：内存 & 对象、执行 & 优化、诊断 & 调优。

1）第一门课：内存与对象 —— 你写的代码在内存里长成了什么样？

#

关键问题有几个：

• 你的对象到底在什么地方分配？
  • 堆？栈上分配？TLAB？逃逸到老年代？
• JVM 的运行时数据区长什么样？
  • 堆（新生代 / 老年代）、虚拟机栈、本地方法栈、方法区 / 元空间、直接内存…
• 一个对象从 “new” 出来到 “被 GC 回收” 的完整生命周期是怎样的？
• 为什么会出现各种 OOM？
  • java.lang.OutOfMemoryError: Java heap space
  • java.lang.OutOfMemoryError: Metaspace
  • java.lang.OutOfMemoryError: Direct buffer memory …

掌握这一块，你能做到：

• 看到 OOM，能较快定位是哪个区域的资源耗尽；
• 回答诸如：
  • “为什么这个内存泄漏调大堆也没用？”
  • “为什么在容器里跑 JVM，明明 -Xmx 设置不大还是被 OOM Kill？”

本系列对应章节：

• 第 3 章：运行时数据区
• 第 6 章：对象的创建、布局与访问
• 第 8 章：垃圾收集基础

2）第二门课：执行与优化 —— JVM 如何让 Java 跑得既快又稳？

#

你写的代码从“字节码”变成“CPU 能执行的机器码”，大致经历了：

1. 解释执行（Interpreter）
2. 热点探测（HotSpot）
3. JIT 编译（C1 / C2），并配合各种优化手段：
   • 方法内联（Inlining）
   • 逃逸分析（Escape Analysis）
   • 标量替换 / 栈上分配
   • 锁优化（偏向锁、轻量级锁、自旋）

同时，还要考虑并发与内存可见性：

• 为什么在多线程下会出现“看不见别的线程写的值”？
• JMM（Java 内存模型）是如何抽象 CPU 缓存和指令重排序的？
• volatile 实际做了哪些事？synchronized 在 JVM 层面是如何实现的？
• 锁优化（偏向锁等）对应用性能的影响有多大？

掌握这一块，你能做到：

• 写出更“JVM 友好”的代码：
  • 减少不必要的对象创建、锁竞争；
  • 了解哪些写法会抑制 JIT 优化。
• 回答诸如：
  • “为什么这段理论上 O(1) 的代码在高并发下性能这么差？”
  • “为什么换了 JDK 版本性能就变了？”

本系列对应章节：

• 第 4 章：类文件结构与字节码基础
• 第 7 章：JMM 与并发语义
• 第 11 章：JIT 编译与执行引擎

3）第三门课：诊断与调优 —— 从“感觉慢”到“知道慢在哪”

#

真正能拉开差距的，往往不是背了多少 JVM 知识点，而是：

遇到线上问题时，你有没有一套可执行的排查路径。

这一块包括三部分内容：

a. 指标和日志：先“看清楚”再下手

#

• GC 日志：
  • 不同 GC 对应的日志格式和关键信息（停顿时间、回收前后内存、原因等）；
• JVM 运行时指标：
  • 堆使用率、年轻代/老年代占用、GC 次数和时间；
  • 线程数、类加载数、JIT 编译情况等。

b. 工具：把 JVM 当成“黑盒”来剖

#

JDK 自带工具已经是一整套 APM：

• jps：查看当前 Java 进程
• jstack：线程栈、死锁排查
• jmap：堆转储，配合 MAT / VisualVM 做对象分析
• jstat：GC 统计和趋势观察
• jcmd：统一诊断入口（JDK8+）

掌握这些工具，意味着：

• 你可以在不重启服务的情况下，在线观察 JVM 的状态；
• 可以给“CPU 飙高、接口超时、偶发 OOM”这些模糊描述一个更明确的“罪名”。

c. 调优：有“原则”和“基线”，而不是拍脑袋

#

• 堆设多大？
• 新生代和老年代该怎么划分？
• CMS / G1 / ZGC 什么时候用？
• 容器内跑 JVM 时，内存参数怎么配才不会被系统 OOM Kill？

掌握这一块，你能做到：

• 面对性能问题，不再是“乱试参数 + 祈祷”，而是：
  • 先通过日志和工具确认问题在哪一层（GC / 锁 / IO / SQL）；
  • 再针对性调整参数或代码；
  • 用压测验证优化效果。

本系列对应章节：

• 第 8～10 章：GC 及调优
• 第 12 章：性能监控与诊断工具
• 第 15 章：JVM 最佳实践清单

到这里，第一章的目标是：

• 给你一个全局视角：JVM 在 Java 生态中的位置；
• 帮你明确：
  • 自己现在大概在哪个阶段；
  • 接下来学 JVM，应该先啃哪几块；
• 让后面的章节都能在这三条主线下理解：
  • 内存 & 对象
  • 执行 & 优化
  • 诊断 & 调优

下一章开始，我们会从这张“大地图”的第一块拼图——JVM 整体架构和 Java 程序的生命周期——正式深入

（二）JVM 整体架构速写：脑中要有一张“总图”

#

这一章的目标：
看完之后，你脑子里应该能画出一张 JVM 的「总图」，知道：

• JVM 大概有哪些模块？
• Java 代码从 .java 到在 CPU 上跑，中间经历了什么？
• 后面深入时，每一章大致会落在这张图的哪个区域。

2.1 JVM 高层架构总览

#

先上一个高层视图，别急着抠细节：

flowchart LR
    subgraph Load[类加载子系统]
        A1[字节码文件\n.class]
        A2[自定义 ClassLoader\n网络/内存/生成]
    end

    subgraph Runtime[运行时数据区]
        B1[堆 Heap\n对象实例]
        B2[方法区/元空间\n类元信息、常量]
        B3[虚拟机栈\n栈帧、局部变量]
        B4[本地方法栈]
        B5[程序计数器 PC]
    end

    subgraph Engine[执行引擎]
        C1[解释器 Interpreter]
        C2[JIT 编译器\nC1/C2/Graal]
        C3[字节码缓存\n& 机器码缓存]
    end

    subgraph GC[垃圾收集系统]
        D1[GC 算法\n标记-清除/复制/整理]
        D2[各代收集器\nSerial/Parallel/CMS/G1/ZGC...]
    end

    subgraph Native[本地接口层]
        E1[JNI]
        E2[本地库\nC/C++/系统调用]
    end

    A1-->Load
    A2-->Load

    Load-->Runtime
    Runtime-->Engine
    Engine-->Runtime
    Runtime-->GC
    Engine-->Native
    Native-->Runtime

再用一句话概括：

JVM = 「类加载子系统」 + 「运行时数据区」 + 「执行引擎（解释器 + JIT）」 + 「GC 系统」 + 「本地接口层（JNI）」。

接下来我们把这张图按“从左到右”的顺序过一遍，再按“Java 程序生命周期”的角度重新整理一遍。

2.2 从源码到执行：Java 程序生命周期

#

我们写一个极简的 Java 程序：

// HelloJVM.java
public class HelloJVM {
    public static void main(String[] args) {
        System.out.println("Hello JVM");
    }
}

它从 .java 到真正跑起来，大致经历了这么几步：

sequenceDiagram
    participant Dev as 开发者
    participant Javac as javac 编译器
    participant ClassFile as .class 字节码
    participant Loader as 类加载子系统
    participant VM as JVM（执行引擎+运行时数据区）
    participant OS as 操作系统/CPU

    Dev->>Javac: 编写 HelloJVM.java并执行 javac HelloJVM.java
    Javac->>ClassFile: 生成 HelloJVM.class
    Dev->>VM: 执行 java HelloJVM
    VM->>Loader: 触发加载 HelloJVM.class
    Loader->>VM: 加载 + 链接 + 初始化 类
    VM->>VM: 执行 main 方法字节码（解释执行 + JIT 编译）
    VM->>OS: 系统调用、IO 操作等
    VM->>VM: 在运行时分配对象、回收垃圾（GC）

我们可以把整个过程拆成三个阶段来看：

1）编译阶段：源码 → 字节码（javac）

#

• 工具：javac（Java 编译器）
• 输入：.java 源码
• 输出：.class 字节码文件
• 字节码文件是平台无关的，只依赖于 JVM 规范。

这一块对应本系列的第 4 章（类文件 & 字节码），后面会展开。

2）类加载 & 链接阶段：字节码 → 运行时元数据

#

当你执行

java HelloJVM

会发生几件事情：

1. JVM 启动，构建类加载器体系；
2. 使用类加载器读取 HelloJVM.class；
3. 对类做加载 → 验证 → 准备 → 解析 → 初始化等步骤；
4. 将类的信息放入方法区 / 元空间中（类元数据、常量池、方法表等）。

这一块对应本系列的第 5 章（类加载子系统）。

3）执行阶段：字节码 → 机器码（解释 + JIT）

#

类加载完成后：

1. JVM 调用 HelloJVM.main()；
2. main 方法的字节码会先被解释器逐条解释执行；
3. 如果某段代码成为“热点代码”（调用频率高）：
   • JVM 会触发 JIT（Just-In-Time）编译，
   • 把频繁执行的字节码编译成本地机器码，存到代码缓存里；
4. 之后再执行该热点代码时，就走机器码路径，性能大幅提升。

同时，在执行过程中：

• 对象在堆上分配（也可能被优化：栈上分配、标量替换）；
• 线程使用各自的虚拟机栈、本地方法栈、程序计数器；
• GC 系统在合适的时机对堆进行垃圾回收。

这一块对应本系列的：

• 第 3 章：运行时数据区
• 第 6 章：对象的创建与布局
• 第 8～10 章：GC 原理与调优
• 第 11 章：执行引擎 & JIT

2.3 关键组件一览：JVM 的「五脏六腑」

#

再回到第一张总图，我们按功能模块快速扫一遍——每个模块都有对应的后续章节深入，这里先建立“浅印象”。

2.3.1 类加载子系统：负责把「类」请进来

#

职责：把类从各种来源（磁盘、网络、内存）加载进 JVM，并完成链接和初始化。

主要动作：

1. 加载（Loading）
   • 通过类加载器（ClassLoader）读取 .class（或其他字节码来源），转成 Class 对象；
2. 验证（Verification）
   • 校验字节码合法性，避免恶意或错误字节码破坏 JVM；
3. 准备（Preparation）
   • 为类变量（静态变量）分配内存并设默认值；
4. 解析（Resolution）
   • 将常量池中的符号引用替换为直接引用（内存地址、偏移）；
5. 初始化（Initialization）
   • 执行 <clinit>，即静态变量赋值、静态代码块。

典型特点：

• 双亲委派模型：

  • 先把“能给父加载器干的活”都交上去，避免重复加载和安全问题；

• 支持

  自定义类加载器：

  • 动态加载插件、热部署、隔离不同模块的类空间等。

你需要知道的：

• 类加载问题经常体现在：
  • ClassNotFoundException / NoClassDefFoundError
  • 多版本冲突（不同 ClassLoader 加载了同名类）
• Web 容器（Tomcat）、Spring Boot 的 fat jar、OSGi 等都会大量利用类加载机制。

详细内容后面在第 5 章专门展开。

2.3.2 运行时数据区：JVM 的内存“地形图”

#

这一部分是 JVM 里最容易被问、也是最常见实际问题所在的地方。

按照是否线程共享划分：

graph LR
    subgraph Shared[线程共享]
        A[堆 Heap]
        B[方法区/元空间]
        C[运行时常量池]
    end
    subgraph Private[线程私有]
        D[程序计数器 PC]
        E[虚拟机栈]
        F[本地方法栈]
    end

简单说：

• 堆（Heap）：
  • “绝大多数对象实例”的老家；
  • 按代划分：新生代（Eden + Survivor）/ 老年代；
  • GC 主要围绕堆展开。
• 方法区 / 元空间（Method Area / Metaspace）：
  • 存放：类元数据、运行时常量池、静态变量、JIT 编译后的代码等；
  • JDK8 之后从堆中的 PermGen（永久代）迁移为本地内存中的 Metaspace。
• 虚拟机栈（JVM Stack）：
  • 每个线程一个栈；
  • 每次调用方法，就会创建一个“栈帧”，内部包含：
    • 局部变量表、操作数栈、动态链接、返回地址等；
  • 递归过深/无限递归会导致 StackOverflowError。
• 本地方法栈（Native Method Stack）：
  • 与虚拟机栈对应，但服务于 native 方法（JNI 调用）。
• 程序计数器（PC 寄存器）：
  • 每个线程一个，记录“当前执行到哪一行字节码”；
  • 执行本地方法时，其值是未指定（undefined）的。

这块你需要重点记住两件事：

1. 不同内存区域 OOM 的含义不同：

   • Heap OOM、Metaspace OOM、Direct Memory OOM、本地线程栈溢出……
   • 对应的现象和排查思路也不同。

2. 后面所有的 GC、对象分配优化、本地内存泄漏等问题，都可以在这张“地形图”上定位。

本系列第 3 章会把这块展开讲清楚； 第 6 章会具体讲对象在堆中的布局，以及“堆以外的分配”。

2.3.3 执行引擎：解释器 + JIT，混合模式跑代码

#

执行引擎负责做一件事：

把字节码指令变成CPU 能跑的机器码，并尽量跑得快。

JVM 的执行模式通常是**“解释 + 即时编译（JIT）”的混合模式**：

flowchart LR
    A[字节码] --> B[解释器\n逐条解释执行]
    B -->|统计热点| C[热点探测 HotSpot]
    C --> D[JIT 编译器\nC1/C2/Graal]
    D --> E[本地机器码缓存]
    E --> F[直接执行机器码]

几个核心概念：

• 解释器（Interpreter）
  • 启动快：类刚加载时，字节码可以立刻解释执行；
  • 但执行效率相对机器码要低。
• JIT 编译器（Just-In-Time Compiler）
  • 针对热点代码（调用频繁/循环次数多），编译为机器码；
  • 分层编译策略（HotSpot）：
    • C1：客户端编译器，编译速度快，优化少；
    • C2：服务端编译器，编译慢，优化强；
  • 现代 JVM 可能引入 Graal 作为新的 JIT 编译器。
• 热点探测（HotSpot）
  • 统计方法调用计数、回边（loop）执行次数；
  • 到达阈值后，就会触发 JIT 编译。

你需要知道的：

• Java 不是简单的“解释型语言”，真正高性能的是靠 JIT 支撑；
• 很多性能差异（不同写法 / 不同 JDK 版本）其实是 JIT 优化行为的结果；
• JIT 在做优化时，会用到：
  • 内联、逃逸分析、锁优化等（后面第 11 章详细说）。

2.3.4 本地接口层（JNI）：JVM 与外部世界的“桥”

#

虽然 Java 强调“一次编写，到处运行”，但总有一些无法直接用 Java 实现的功能：

• 与特定操作系统/硬件强相关的能力（系统调用、设备访问）；
• 希望复用已有的 C/C++ 库，比如高性能加解密库、压缩库等。

这时就需要：JNI（Java Native Interface）。

JNI 提供了一套规范，让：

• Java 代码可以调用本地方法 native；
• 本地代码可以反过来回调 JVM，访问 Java 对象。

典型场景：

• Netty 使用本地代码优化网络 IO 和内存分配（DirectBuffer）；
• 一些压缩/加解密类库（如 Zstd、OpenSSL 包装）通过 JNI 封装；
• JDK 本身的部分底层实现也依赖本地代码。

需要注意的是：

• JNI 层出了问题，往往不是 Java 异常，而是：
  • 进程 Crash（hs_err_pid*.log）、段错误、Deadlock；
• JNI 也可以分配内存（本地堆、直接内存），会带来Java Heap 之外的 OOM。

2.3.5 垃圾收集系统（GC）：自动内存管理的“大管家”

#

GC 解决的是两个问题：

1. 哪些对象可以回收？（“谁已经没用了？”）
2. 何时、用什么方式回收？（“什么时候动手，怎么扫？”）

在高层架构里你先记住几件事：

• GC **主要围绕堆（Heap）**进行工作；
• 使用**可达性分析（Reachability Analysis）**来判断对象是否“活着”；
• 为了兼顾吞吐量与停顿时间，引入了：
  • 分代收集（新生代 / 老年代）
  • 不同的收集器组合（Serial / Parallel / CMS / G1 / ZGC / Shenandoah 等）；

在后面章节我们会详细讲：

• 新生代 / 老年代为什么要分开？
• CMS / G1 / ZGC 之间的主要区别是什么？
• 业务上该如何根据延迟 / 吞吐需求选择 GC 策略？

2.4 不同 JDK / JVM 实现差异：HotSpot 只是“主角之一”

#

很多人平时只接触 “JDK8/11/17”，往往容易混淆三个概念：

1. Java 语言规范；
2. JVM 规范；
3. 具体的 JVM 实现（实现 JVM 规范的软件）。

JVM 规范只规定“应该长什么样，至少要支持哪些行为”，但不规定具体怎么实现。 在这个规范之下，存在多个 JVM 实现，最常用的是：

• HotSpot VM（Oracle/OpenJDK 自带，实现最普及）
• OpenJ9（Eclipse 基金会主导，前身 IBM J9）
• 以及其他（Azul Zing/Zulu、GraalVM 等）

本系列默认以 HotSpot 为主来讲解，但了解其他实现的差异也能帮助你「不被细节误导」。

2.4.1 HotSpot：默认世界观

#

特点：

• OpenJDK/Oracle JDK 默认采用的虚拟机实现；
• 绝大多数线上 Java 应用跑在 HotSpot 之上；
• 提供多种 GC 实现：
  • Serial / Parallel / CMS（JDK9 之后被标记为 deprecated）
  • G1（JDK9 之后默认 GC）
  • ZGC、Shenandoah（JDK11+ / 之后版本逐渐成熟）；
• 使用 C1 / C2 分层 JIT 编译器（部分新版本可以使用 Graal JIT）。

你在 java -version 里看到的大概率就是它。

2.4.2 OpenJ9：更加节省内存的另一套实现

#

OpenJ9 是 Eclipse 基金会维护的一个开源 JVM，实现同样的 JVM 规范。

特点（简单感知即可）：

• 目标是更小的内存占用、更快的启动；
• 类数据共享（CDS）、AOT（Ahead-of-Time）等方面有不少优化；
• GC、JIT、内存布局等与 HotSpot 有较大不同。

对我们这套笔记的影响是：

• 绝大多数「JVM 规范层面」的内容是通用的；
• 但「实现细节层面」（如对象头布局、具体 GC 参数名）会有实现差异；
• 绝大多数互联网公司、面试题、调优文章都默认以 HotSpot 为前提。

2.4.3 JDK 版本演进对 JVM 的影响（简单预告）

#

除了不同 JVM 实现，同一个 HotSpot 在不同 JDK 版本之间也差异很大，例如：

• JDK 6 / 7：
  • 有永久代（PermGen）；
  • CMS 仍被大量使用；
• JDK 8：
  • 去掉 PermGen，引入 Metaspace（本地内存）；
  • 默认 GC 仍是 Parallel（吞吐量优先）；
• JDK 9+：
  • G1 成为默认 GC；
  • 引入模块化（Jigsaw），影响类加载与部署方式；
• JDK 11 / 17 / 21：
  • ZGC / Shenandoah 逐步成熟，针对低延迟场景更友好；
  • 对容器/云原生环境有更好的支持（自动感知 cgroup 内存等）。

这也意味着：

• 你在看 JVM 相关资料时，一定要注意JDK 版本前提；
• 本系列会在相关章节专门标注 JDK8 / JDK11+ 的关键差异。

小结：这张“总图”要记住什么？

#

到这里，「第二章：JVM 整体架构速写」的核心任务就完成了，你应该能：

1. 在脑中画出一张 JVM 的高层结构图：
   • 类加载子系统 → 运行时数据区 → 执行引擎 → GC → JNI；
2. 知道 Java 程序大致的生命周期：
   • javac 编译 → 类加载/链接/初始化 → 解释执行 + JIT → GC 与本地交互；
3. 对后面各章节有一个“位置感”：
   • 内存问题 → 看运行时数据区 + GC；
   • 类找不到 / 版本冲突 → 优先想类加载；
   • 性能抖动 / 延迟高 → 执行引擎 + GC + 并发；
   • 本地 Crash / DirectBuffer OOM → 想到 JNI & 本地内存。

下一章（第三章），我们会正式落到这张图里最常见的一块——运行时数据区：JVM 内存模型速记图，把“堆、栈、方法区、常量池、直接内存”这些经常被问的概念一次捋清。

（三）运行时数据区：JVM 内存模型速记图

#

本章目标：

• 把“堆、栈、方法区、常量池、直接内存”等常见名词一次讲清；
• 建立一张 JVM 运行时内存“地形图”，后面所有 GC、OOM、对象优化都在这张图上定位；
• 知道不同区域的典型异常（StackOverflowError / 各种 OOM）代表什么。

3.1 运行时数据区总览：线程共享 vs 线程私有

#

从 JVM 规范角度，运行时数据区可以画成下面这样：

graph TB
    subgraph Shared[线程共享（所有线程可见）]
        H[堆 Heap\n对象实例、数组]
        M[方法区 / 元空间\n类元数据、运行时常量池、静态变量等]
    end

    subgraph Private[线程私有（每个线程一份）]
        PC[程序计数器 PC]
        VS[虚拟机栈 JVM Stack\nJava 方法栈帧]
        NS[本地方法栈 Native Stack\nnative 方法栈帧]
    end

HotSpot 具体实现上还会有：

• 代码缓存（Code Cache）：存 JIT 编译后的机器码；
• 直接内存（Direct Memory）：JVM 进程向 OS 申请的堆外内存，不在上述规范区域内，但异常经常“混在一起”。

先做一个“一句话速记”：

• 堆（Heap）：绝大多数对象的家，GC 的主战场；
• 方法区 / 元空间：类长什么样的信息，以及部分常量、静态变量；
• 虚拟机栈：** Java 方法调用现场**，一个方法一个栈帧；
• 本地方法栈：native 方法用的栈；
• 程序计数器：当前线程执行到哪条字节码；
• 直接内存：堆外大块内存，NIO / Netty / 某些中间件常用。

后面所有和 “OOM”、“GC”、“栈溢出”、“类加载太多” 相关的问题，都可回到这张图上定位。

3.2 堆（Heap）：对象的主要居所

#

3.2.1 堆是什么？

#

• 所有线程共享的一块内存区域；
• Java 中「几乎所有对象实例和数组」都在堆上分配；
• 是 GC 的主要管理范围；
• 可以通过 -Xms -Xmx 指定堆大小限制。

示意图：

graph TB
    subgraph Heap[Java 堆]
        subgraph Young[新生代 Young Gen]
            Eden[Eden 区]
            S0[Survivor 0]
            S1[Survivor 1]
        end
        subgraph Old[老年代 Old Gen]
            O1[长期存活对象]
        end
    end

3.2.2 新生代 / 老年代：为什么要“分代”？

#

GC 的一个基本经验（“弱分代假说”）：

大多数对象“朝生夕死”，只有少数对象会存活较长时间。

基于这个经验，HotSpot 在堆上做了“分代”设计：

• 新生代（Young Generation）
  • 新对象大多先在这里分配；
  • 又分为：
    • Eden 区：绝大多数新对象第一次分配的位置；
    • Survivor0 / Survivor1：幸存者区，复制算法使用；
  • 垃圾回收多采用复制算法（效率高，适合“死得多”的场景）；
  • 回收动作叫 Minor GC / Young GC。
• 老年代（Old Generation）
  • 经过多次 Minor GC 仍然存活、或大对象（根据策略）会晋升到老年代；
  • 对象死亡比例相对低，回收采用 标记-整理 或 标记-清除 算法；
  • 回收动作通常涉及整堆，停顿时间相对长，称为 Major GC / Full GC（实现中含义略有差异）。

分代的好处：

• 把大部分回收压力集中在新生代，用高效的复制算法；
• 尝试减少老年代回收的频率和停顿时间。

3.2.3 对象分配与 TLAB（Thread Local Allocation Buffer）

#

HotSpot 上的对象分配大致过程：

1. 在线程本地分配缓冲区（TLAB）上“指针碰撞”：

   • 每个线程在新生代 Eden 划出一小块区域作为自己的 TLAB；
   • 分配对象只需要移动指针，无需多线程竞争锁；

2. TLAB 用完：

   • 向 Eden 再申请一块新的 TLAB；

3. Eden 空间不足：

   • 触发一次 Minor GC。

示意图：

graph LR
    subgraph Eden[Eden]
        T1[TLAB - 线程1]
        T2[TLAB - 线程2]
        T3[TLAB - 线程3]
    end

你只需要记住：

• 对象分配非常快：多数场景就是在一块连续内存上挪指针；
• 多线程分配也很快：TLAB 避免了大部分锁竞争；
• 当你看到 GC 日志里频繁的 Minor GC，很可能就是：
  • Eden 太小；
  • 对象创建“风暴”（临时对象特别多）。

3.2.4 堆相关的常见错误与参数

#

典型错误信息：

• java.lang.OutOfMemoryError: Java heap space
  

  • 通常说明堆空间不够；
  • 也可能是有内存泄漏（对象被引用住，GC 无法回收）。

关键参数（HotSpot）：

# 设置堆初始大小 & 最大大小
-Xms2g
-Xmx2g

# 新生代大小（JDK8）
-Xmn512m

# JDK8 中，也可以通过比例控制
-XX:NewRatio=3    # 老年代:新生代=3:1

# JDK8 之后，用 G1 时更多通过其他参数控制，不一定直接设 -Xmn

调优思路（简化版）：

• 堆太小：
  • 频繁 Full GC / OOM；
  • 解决：合理加大堆、直至达到机器/容器上限；
• 堆过大：
  • Full GC 一次就要停很久（传统收集器下明显）；
  • 容器环境可能被 OS OOM Kill。

后续 GC 章节会基于这块继续展开。

3.3 虚拟机栈（JVM Stack）：每个线程自己的“调用现场”

#

3.3.1 什么是虚拟机栈？

#

• 每个 Java 线程启动时，都会创建一个与之对应的 虚拟机栈；
• 每执行一个 Java 方法，就会创建一个 栈帧（Stack Frame） 入栈；
• 方法执行完毕，栈帧弹出，局部变量等随之销毁。

示意图：

graph TB
    subgraph Thread1[线程1的虚拟机栈]
        direction TB
        F3[栈帧：methodC]
        F2[栈帧：methodB]
        F1[栈帧：main]
    end

当你在代码里这样调用：

public void a() {
    b();
}

public void b() {
    c();
}

public void c() {
    // ...
}

在某一时刻，线程的虚拟机栈上，栈帧顺序近似为：

• main → a → b → c（顶部是当前执行的 c）。

3.3.2 栈帧结构：局部变量表、操作数栈等

#

一个栈帧主要包含：

• 局部变量表（Local Variables）

  • 存储方法参数、局部变量；
  • 用“槽（slot）”来表示，每个 slot 对应 32 位；
  • long / double 类型会占用 2 个 slot。

• 操作数栈（Operand Stack）

• 大部分字节码指令是“操作栈风格”的：

  • 指令从局部变量表或常量池中取值，压入栈顶；
  • 运算后结果再压栈或写回局部变量表。

• 动态链接（Dynamic Linking）

  • 指向当前方法所在类的运行时常量池的引用；
  • 用于支持方法调用、字段访问令牌在运行时的解析。

• 返回地址（Return Address）

  • 方法结束时，需要返回到上一个栈帧哪里继续执行。

这块内容在后续讲字节码（第 4 章）和 JIT 优化时会更直观，现在只需要有个印象： 栈帧就是一次方法调用的“运行现场快照”。

3.3.3 StackOverflowError vs OutOfMemoryError（栈相关）

#

与虚拟机栈 & 本地栈相关的常见异常有两种：

1. java.lang.StackOverflowError
2. java.lang.OutOfMemoryError: unable to create new native thread（或类似）

a. StackOverflowError：单个线程栈太深

#

场景典型如：递归过深 / 无限递归，例如：

public class StackOverflowDemo {
    private static int depth = 0;

    public static void recursive() {
        depth++;
        recursive();
    }

    public static void main(String[] args) {
        try {
            recursive();
        } catch (Throwable e) {
            System.out.println("Depth: " + depth);
            e.printStackTrace();
        }
    }
}

特点：

• 当前线程的虚拟机栈空间被用完了；
• 报错：java.lang.StackOverflowError；
• 调整方式：
  • 优化递归逻辑；
  • 或适当调大栈容量：-Xss1m（每个线程栈大小）。

b. unable to create new native thread：线程太多，栈整体撑爆

#

底层上，每个线程（Java 线程 ↔ OS 线程）都会分配一块栈空间；

• 当你创建太多线程时，系统总栈空间 / 进程可用地址空间被用尽；
• JVM 无法再为新线程分配栈，就会抛出：
  • java.lang.OutOfMemoryError: unable to create new native thread 或类似信息。

常见于：

• 线程池参数配置不当；
• 误用 new Thread() 频繁创建大量线程。

3.4 本地方法栈（Native Method Stack）

#

本地方法栈的功能和虚拟机栈类似，只不过：

• 服务于 native 方法（JNI 调用）；
• 线程私有，每个线程一个；
• HotSpot 实现中经常将“虚拟机栈 + 本地方法栈”视为统一的结构来实现，规范上是分开的。

典型异常与虚拟机栈类似：

• 栈深度过深 → StackOverflowError；
• 无法为新线程分配栈空间 → OutOfMemoryError。

对日常开发的影响：

• 当你大量使用 JNI（如高性能 IO、图像处理、本地库）， 如果出现 native 层崩溃、栈溢出，很可能和本地栈实现有关（一般需要看 hs_err_pid*.log）。

3.5 方法区 / 元空间（Metaspace）：类长什么样，放哪儿？

#

3.5.1 方法区是什么？

#

JVM 规范中的**方法区（Method Area）**是一个逻辑概念：

用于存储已被虚拟机加载的类型信息、常量、静态变量、JIT 编译后的代码等数据。

HotSpot 的实现经历了一个演进过程：

• JDK 6 / 7：
  • 使用 永久代（PermGen） 作为方法区实现的一部分（在堆里）；
• JDK 8+：
  • 去掉永久代，引入 元空间（Metaspace）（使用本地内存）；
  • 类元数据放在 Metaspace，字符串常量池等搬回堆或其他区域。

你可以简单理解为：

• 以前：类信息在堆里（PermGen），轻易就 PermGen space OOM；
• 现在：类信息在堆外（Metaspace），配置得不好就 Metaspace OOM。

3.5.2 从 PermGen 到 Metaspace：为什么要改？

#

永久代（PermGen）的几个问题：

1. 大小难以设置：
   • 设小了，类多一点或有动态代理，就容易 OutOfMemoryError: PermGen space；
   • 设大了，又会挤占堆的空间；
2. 和 HotSpot 实现强绑定：
   • 其他 JVM 实现（如 JRockit）并没有永久代概念；
   • 它更像是 HotSpot 特有的“历史包袱”。

Metaspace 的改动：

• 使用本地内存（Native Memory）来存储类元数据；
• 通过 -XX:MaxMetaspaceSize 控制上限；
• 默认情况下会按需增长，直到耗尽系统内存或达到上限。

配置示例（JDK8+）：

# 元空间初始大小 & 最大值
-XX:MetaspaceSize=128m
-XX:MaxMetaspaceSize=512m

JDK7 及之前（已过时，但老项目/老面试题仍会出现）：

# 永久代大小
-XX:PermSize=128m
-XX:MaxPermSize=256m

3.5.3 方法区里放了什么？对业务有什么影响？

#

典型内容：

• 类的结构信息：
  • 类名、父类、接口；
  • 字段、方法信息；
  • 方法字节码等；
• 运行时常量池；
• 静态变量（实现中有一定细微差别，这里不深究）；
• JIT 编译后的代码（HotSpot 用单独的 Code Cache 管理，但也可以视作“方法区扩展”）。

实际影响最大的场景：

1. 动态生成大量类 / 频繁加载卸载类
   • 如：框架的动态代理（CGLIB）、字节码增强、模板引擎等；
   • 热部署、插件系统（每次重新加载都会加载新类）；
   • 容器中多应用部署（每个应用自己的 ClassLoader）。

如果类加载了但对应的 ClassLoader 始终被引用着，就可能产生：

• Metaspace 无法回收 → 内存持续增长 → OutOfMemoryError: Metaspace。

3.6 运行时常量池：类和字符串的“常量仓库”

#

3.6.1 常量池 & 运行时常量池

#

在 Class 文件结构里，有一个重要区域叫 常量池（Constant Pool）：

• 存储各种字面量：
  • 字符串常量、整数、浮点数等；
• 以及符号引用：
  • 类和接口的完全限定名；
  • 字段名与描述符；
  • 方法名与描述符。

当类被加载后：

• 这些常量会被放入 运行时常量池（Runtime Constant Pool）；
• 运行时常量池是方法区的一部分（JVM 规范层面）。

3.6.2 字符串常量池的演化（JDK6 / 7 / 8）

#

Java 对字符串做了大量特殊优化，其中最重要的一点：

维护一个字符串常量池，相同字面量的 String 对象可以被复用。

在不同版本里的差异：

• JDK6 及之前
  • 字符串常量池位于 永久代（PermGen） 中；
  • 动态调用 String.intern()，新字符串会加入 PermGen 中的常量池；
  • 如果大量使用 intern()，很容易 OutOfMemoryError: PermGen space。
• JDK7 之后
  • 字符串常量池从方法区搬到了 堆 上；
  • intern() 会把引用指向堆中已有的字符串对象；
  • 大量 intern() 引起的 OOM 表现为：Java heap space，而不是 PermGen。

简单验证示例（行为在 JDK6/7 有差异）：

public class StringInternDemo {
    public static void main(String[] args) {
        String s1 = new StringBuilder("he").append("llo").toString();
        System.out.println(s1.intern() == s1); // JDK7+ 通常是 true

        String s2 = new StringBuilder("ja").append("va").toString();
        System.out.println(s2.intern() == s2); // 可能是 false，因为 "java" 早已存在
    }
}

记住两点即可：

1. JDK7+：字符串常量池在 堆 上，不在元空间；
2. 如果你用 intern() 做“字符串去重”，要小心堆 OOM。

3.7 直接内存（Direct Memory）与 NIO：堆外的那块“看不见的”内存

#

3.7.1 直接内存是什么？

#

直接内存（Direct Memory）并不在 JVM 规范的运行时数据区内，它属于：

• JVM 进程向操作系统申请的一块 堆外内存（off-heap）；
• 普通 Java 对象访问不到，只能通过特定 API（如 NIO 的 ByteBuffer.allocateDirect）来操作。

优点：

• 避免在 Java 堆 ↔ Native 堆之间来回复制数据；
• 适合大量 IO / 网络通信场景（如 NIO、Netty）。

3.7.2 NIO 与 DirectByteBuffer

#

典型用法：

import java.nio.ByteBuffer;

public class DirectBufferDemo {
    public static void main(String[] args) {
        // 堆内缓冲区
        ByteBuffer heapBuffer = ByteBuffer.allocate(1024);

        // 直接缓冲区（堆外）
        ByteBuffer directBuffer = ByteBuffer.allocateDirect(1024);
    }
}

• allocate()：在 堆内 分配，受堆大小限制；
• allocateDirect()：在 直接内存 分配，受 MaxDirectMemorySize 和系统内存限制。

在 HotSpot 中，直接内存的上限可通过参数指定：

-XX:MaxDirectMemorySize=1g

如果不指定，通常默认值约等于堆最大值（不同版本略有差异）。

3.7.3 Direct Memory OOM：堆还很空，为什么也 OOM？

#

典型异常信息：

• java.lang.OutOfMemoryError: Direct buffer memory

这是一个非常常见但又容易被误解的错误：

• 你可能用 jmap / jstat 看堆，发现还很空；
• 甚至还有很多老年代空间未用；
• 但应用就是 OOM 了 —— 因为挂的是堆外的 Direct Memory。

常见原因：

1. 频繁创建 DirectByteBuffer，但没及时释放引用
   • DirectBuffer 的释放依赖于 GC 到达其 Java 包装对象（PhantomReference + Cleaner）；
   • 如果应用持有大量 DirectBuffer 引用，或 GC 回收不及时，就会堆积；
2. 容器内内存限制被忽视
   • 容器（Docker/K8s）限制了进程总内存；
   • 你只给 JVM 配了 -Xmx，忘了 Direct Memory 还会占系统内存；
   • 合起来超过限制，就会被系统 OOM Kill。

排查建议：

• 注意 GC 日志 & 系统 dmesg/监控；
• 使用 -XX:MaxDirectMemorySize 主动限制直接内存大小；
• 使用 Netty 等框架时，了解其内存池策略，避免无节制创建直接缓冲区。

小结：把这张“地形图”刻在脑子里

#

本章把 JVM 的运行时数据区做了一次系统梳理，你可以用下面这张综合图做一个“压缩版记忆”：

graph TB
    subgraph Shared[线程共享]
        H[堆 Heap\n新生代/老年代\n- Java heap space OOM]
        M[方法区/元空间\n类元数据、常量池、静态变量\n- Metaspace OOM/旧版本 PermGen OOM]
        CP[运行时常量池\n字符串常量、符号引用]
        DM[直接内存 Direct Memory\n- Direct buffer memory OOM]
    end

    subgraph Private[线程私有]
        PC[程序计数器\n记录当前字节码位置]
        S[JVM 栈\n栈帧：局部变量表+操作数栈\n- StackOverflowError]
        NS[本地方法栈\nnative 方法调用现场]
    end

建议至少能做到：

1. 碰到各种 OOM / 栈溢出时，能够在图上立刻指出大概是哪一块出了问题；
2. 知道堆、新生代/老年代、Metaspace、直接内存的基本用途和典型异常；
3. 后面在学 GC、对象分配、类加载、NIO 时，都能把知识挂到这张图上。

下一章（第 4 章），我们会从“磁盘上的 .class 文件”开始，讲清楚 Class 文件结构和字节码指令，也就是“JVM 到底在执行什么东西”。

（四）类文件结构与字节码基础：从 .class 开始剖 JVM

#

本章目标：

• 知道 .class 里面到底存了什么（Class 文件结构）
• 大致看懂一段 javap 输出（常量池 & 字节码）
• 理解 JVM 是一台基于栈的虚拟机，字节码如何操作操作数栈
• 对 invokedynamic 有一个“知道它干嘛”的初步认识

4.1 Class 文件整体结构鸟瞰

#

当你写完 Java 代码，执行：

javac Hello.java

会生成一个 .class 文件。 从 JVM 的角度，这个文件就是一段按规范组织的二进制结构，结构大致如下：

ClassFile {
    u4             magic;                 // 魔数，固定是 0xCAFEBABE
    u2             minor_version;         // 次版本号
    u2             major_version;         // 主版本号
    u2             constant_pool_count;   // 常量池大小
    cp_info        constant_pool[...];    // 常量池表
    u2             access_flags;          // 访问标志（public、final 等）
    u2             this_class;            // 当前类
    u2             super_class;           // 父类
    u2             interfaces_count;      // 实现的接口数量
    u2             interfaces[...];       // 接口表
    u2             fields_count;          // 成员变量数量
    field_info     fields[...];           // 字段表
    u2             methods_count;         // 方法数量
    method_info    methods[...];          // 方法表
    u2             attributes_count;      // 属性数量（类级别）
    attribute_info attributes[...];       // 属性表
}

可以把它类比为一个「自描述二进制文件」：

• 开头的魔数 & 版本号告诉 JVM： “我是一个合法的 Class 文件，版本是 52.0（即 JDK8）”；
• 常量池区像一个“字面量 & 符号引用的大字典”；
• 字段表 / 方法表描述类有哪些变量、方法；
• 属性表是一个扩展机制，很多调试信息、注解、泛型签名、字节码本身都以 attribute 的形式出现。

4.1.1 快速看一眼十六进制长什么样

#

写一个极简类：

// Hello.java
public class Hello {
    private int x = 1;

    public int add(int a, int b) {
        return a + b;
    }
}

编译后用十六进制打开 Hello.class（这里只截一小部分做感受）：

CA FE BA BE 00 00 00 34 00 0D 0A 00 03 00 0A 07
00 0B 07 00 0C 01 00 01 78 01 00 01 49 01 00 06
<...省略...>

• CA FE BA BE 就是魔数；
• 00 00 00 34 表示版本（这里是 52，即 JDK8：0x0034）；
• 后面紧跟着的是常量池等内容。

实际开发中不需要手撸十六进制，我们更常用的是 javap。

4.1.2 用 javap 看 Class 结构

#

javap 是 JDK 自带的反汇编工具，常用参数：

# 反编译，展示字节码指令
javap -c Hello

# 展示详细信息（版本、常量池、字段、方法、属性）
javap -v Hello

示例（节选输出）：

$ javap -v Hello
Classfile /.../Hello.class
  Last modified 2025-1-1; size 404 bytes
  MD5 checksum ...
  Compiled from "Hello.java"
public class Hello
  minor version: 0
  major version: 52
  flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
   #1 = Methodref          #4.#16         // java/lang/Object."<init>":()V
   #2 = Fieldref           #3.#17         // Hello.x:I
   #3 = Class              #18            // Hello
   #4 = Class              #19            // java/lang/Object
   ...
{
  public Hello();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: aload_0
         5: iconst_1
         6: putfield      #2                  // Field x:I
         9: return
  ...

  public int add(int, int);
    descriptor: (II)I
    flags: ACC_PUBLIC
    Code:
      stack=2, locals=3, args_size=3
         0: iload_1
         1: iload_2
         2: iadd
         3: ireturn
}

这一段里，已经能看到：

• Class 文件版本、访问标志；
• 常量池的若干条目（#1 Methodref、#2 Fieldref 等）；
• 构造方法和 add 方法对应的字节码指令。

接下来我们分别把「常量池」和「字节码指令」拆开讲清楚。

4.2 常量池：Class 文件的“大字典”

#

常量池（Constant Pool）是 Class 文件中最核心的结构之一，它存了：

• 字面量（String、int、float、double 等常量）
• 各种“符号引用”（类名、方法名和描述符、字段名等）

可以理解为：字节码里不会直接 hardcode 各种字符串/签名，而是用对常量池的索引来间接引用。

4.2.1 常见常量池项类型

#

常量池是一个数组，数组元素类型是 cp_info，不同类型用 tag 区分。 常见的几种（只列开发中常遇到的）：

你可以先记住三大类：

1. 原始字面量：Integer/Float/Long/Double/String

2. 符号引用：

   • 类：Class
   • 方法：Methodref / InterfaceMethodref
   • 字段：Fieldref

3. 名称 & 描述符相关：

   • Utf8：实际上是各种“字符串”基础

• NameAndType：把名字和类型配对

4.2.2 一个常量池小例子

#

继续用上面的 Hello 类，javap -v 中的常量池节选：

Constant pool:
   #1 = Methodref          #4.#16         // java/lang/Object."<init>":()V
   #2 = Fieldref           #3.#17         // Hello.x:I
   #3 = Class              #18            // Hello
   #4 = Class              #19            // java/lang/Object
   #5 = Utf8               x
   #6 = Utf8               I
   #7 = Utf8               <init>
   #8 = Utf8               ()V
   #9 = Utf8               Code
  #10 = Utf8               LineNumberTable
  #11 = Utf8               LocalVariableTable
  #12 = Utf8               this
  #13 = Utf8               LHello;
  #14 = Utf8               add
  #15 = Utf8               (II)I
  #16 = NameAndType        #7:#8          // "<init>":()V
  #17 = NameAndType        #5:#6          // x:I
  #18 = Utf8               Hello
  #19 = Utf8               java/lang/Object

你可以看到几类关系：

• #3 = Class #18 和 #18 = Utf8 Hello → 说明“有一个名为 Hello 的类”。
• #1 = Methodref #4.#16，再看：
  • #4 = Class #19，#19 = Utf8 java/lang/Object
  • #16 = NameAndType #7:#8，#7 = Utf8 <init>，#8 = Utf8 ()V → 合起来就是：引用了 java/lang/Object 的 <init>()V 方法（构造器）。
• #2 = Fieldref #3.#17，再看：
  • #3 = Class #18 → Hello
  • #17 = NameAndType #5:#6 → x:I → 表示类 Hello 的 int x 字段。

你可以把常量池理解为一张“多跳索引表”，id 对 id，最后落到 Utf8 上。

用一张简化的关系图表示：

graph LR
    M1[Methodref #1\nObject.<init>] --> C4[Class #4\n#19]
    M1 --> NT16[NameAndType #16\n#7:#8]
    C4 --> U19[Utf8 #19\njava/lang/Object]
    NT16 --> U7[Utf8 #7\n<init>]
    NT16 --> U8[Utf8 #8\n【】V]

    F2[Fieldref #2\nHello.x] --> C3[Class #3\n#18]
    F2 --> NT17[NameAndType #17\n#5:#6]
    C3 --> U18[Utf8 #18\nHello]
    NT17 --> U5[Utf8 #5\nx]
    NT17 --> U6[Utf8 #6\nI]

理解常量池的意义在于：

• 看字节码时各种 #1、#2 都是指向常量池的索引；
• GC 和类加载、动态链接时都会频繁用到常量池里的符号引用。

4.3 字节码指令集概览：基于栈的虚拟机

#

JVM 是一台基于栈的虚拟机（stack-based VM），这句话的意思是：

字节码指令大多数操作的是“操作数栈”，而不是像 CPU 指令那样操作寄存器。

特征主要有两点：

1. 指令集紧凑：
   • 大多数指令是 1 字节 opcode + 若干操作数；
2. 操作风格统一：
   • iload 把局部变量表中的 int 值压栈；
   • iadd 从栈顶弹出两个 int，相加，再把结果压回栈顶；
   • ireturn 从栈顶弹出返回值。

4.3.1 指令的一般形式

#

<opcode> [operand1] [operand2] ...

例如：

• bipush 10：
  • bipush 是一个 opcode，表示“把一个字节常量压入栈”；
  • 10 是操作数。
• iload_1：
  • 不带额外操作数，含义是“从局部变量表槽位 1 取一个 int 压栈”。

4.3.2 常见的指令分类

#

不用全部记住，只要对主要类别有感知：

1. 加载 / 存储
   • iload, iload_0, aload_0 …
   • istore, astore …
2. 栈操作
   • pop, dup, dup2, swap …
3. 算术运算
   • iadd, isub, imul, idiv …
   • ladd, fadd, dadd 分别对应 long/float/double。
4. 类型转换
   • i2l, i2f, i2d, l2i …
5. 对象相关
   • new, getfield, putfield, getstatic, putstatic
   • checkcast, instanceof …
6. 控制转移
   • 条件跳转：ifeq, ifne, if_icmpeq, ifnonnull …
   • 无条件跳转：goto
   • 多分支：tableswitch, lookupswitch
7. 方法调用 & 返回
   • invokestatic：调用静态方法
   • invokevirtual：调用实例方法，基于虚方法分派
   • invokespecial：调用构造器、私有方法、父类方法
   • invokeinterface：调用接口方法
   • invokedynamic：延迟到运行时的动态调用（后面 4.5 部分专讲）
8. 异常处理相关
   • athrow：抛出异常
   • 异常表由 attribute 表描述，字节码中出现了异常抛出并不意味着你能看见 try/catch 的所有逻辑（异常处理结构在方法属性中）。

掌握这些门类后，再配合 javap -c，你就能比较轻松地“读懂”JVM 在执行什么。

4.4 常见字节码示例解析：用 javap 走读

#

我们通过几段简短代码，看一下字节码编译后的样子，以及如何解读。

4.4.1 一个最简单的加法方法

#

代码：

public class BytecodeDemo {
    public int add(int a, int b) {
        return a + b;
    }
}

编译 & 反汇编：

javac BytecodeDemo.java
javap -c BytecodeDemo

输出节选：

public int add(int, int);
  Code:
     0: iload_1
     1: iload_2
     2: iadd
     3: ireturn

逐行解释：

• iload_1：把局部变量表中索引 1 的 int 压入操作数栈（参数 a）。
• iload_2：把索引 2 的 int 压栈（参数 b）。
• iadd：从栈顶弹出两个值，相加，把结果压回栈顶。
• ireturn：从栈顶弹出一个 int，作为返回值。

局部变量表布局（非 static 实例方法）大致是：

4.4.2 if 条件与分支：控制流是怎么编译的？

#

代码：

public int max(int a, int b) {
    if (a >= b) {
        return a;
    } else {
        return b;
    }
}

javap -c：

public int max(int, int);
  Code:
     0: iload_1
     1: iload_2
     2: if_icmplt     9
     5: iload_1
     6: ireturn
     7: iload_2
     8: ireturn
     9: iload_2
    10: ireturn

不同编译器/优化选项可能生成略有不同的字节码，这里以一种常见情况说明思路。

这里比较典型的形式是：

• if_icmplt 9
  

  • 含义：如果 栈顶第二个 < 栈顶第一个，则跳转到 offset=9；
  • 也就是如果 a < b，走 else 分支。

一个更直观的写法（实际字节码可能更精简，这里只是近似理解）：

0: iload_1        // 压入 a
1: iload_2        // 压入 b
2: if_icmplt 9    // if (a < b) goto 9
5: iload_1        // a >= b，返回 a
6: ireturn
9: iload_2        // a < b，返回 b
10: ireturn

你可以观察到：

• if_xxx 系列都是条件跳转指令；
• goto 用于无条件跳转（循环、后续逻辑跳过等）。

4.4.3 循环：for/while 是如何展开的？

#

代码：

public int sumToN(int n) {
    int sum = 0;
    for (int i = 1; i <= n; i++) {
        sum += i;
    }
    return sum;
}

javap -c：

public int sumToN(int);
  Code:
     0: iconst_0
     1: istore_2        // sum = 0
     2: iconst_1
     3: istore_3        // i = 1
     4: iload_3
     5: iload_1
     6: if_icmpgt     19   // if (i > n) goto 19
     9: iload_2
    10: iload_3
    11: iadd
    12: istore_2        // sum += i
    13: iinc          3, 1  // i++
    16: goto          4
    19: iload_2
    20: ireturn

可以看到 for 循环概念上被翻译为：

1. 初始化 sum、i；
2. 先判断条件（i > n 结束）；
3. 循环体执行；
4. i++；
5. goto 4 回到条件判断。

你如果写 while，大致也是同样的结构，只是初始化 & 条件判断位置略有不同。

4.4.4 方法调用：invokevirtual / invokestatic / invokespecial

#

示例代码：

public class InvokeDemo {
    public static int staticAdd(int a, int b) {
        return a + b;
    }

    public int instanceAdd(int a, int b) {
        return a + b;
    }

    public void call() {
        int r1 = staticAdd(1, 2);
        int r2 = instanceAdd(3, 4);
    }
}

javap -c 中 call() 的字节码（节选）：

public void call();
  Code:
     0: iconst_1
     1: iconst_2
     2: invokestatic  #2  // Method staticAdd:(II)I
     5: istore_1
     6: aload_0
     7: iconst_3
     8: iconst_4
     9: invokevirtual #3  // Method instanceAdd:(II)I
    12: istore_2
    13: return

解释：invokestatic调用静态方法：

• 不需要 this，直接用类 + 方法描述符找到目标实现；

• invokevirtual调用实例方法：

  • 需要先把 this（aload_0）压栈；
  • 然后根据“虚方法分派规则”在实际对象的类型上找方法实现。

其他还有：

• invokespecial：调用构造器、super.xxx()、private 方法等；
• invokeinterface：调用接口方法，涉及接口方法表查找；
• invokedynamic：动态语言 & Lambda 的关键，下一节专门说。

4.5 invokedynamic 简述：为 Lambda 与动态语言铺路

#

invokedynamic 是在 Java 7 引入的一条新字节码指令，目的不是为了 Java 自己，而是：

为 JVM 上跑的动态类型语言（如 JRuby、Groovy 等）提供一个更灵活、高效的调用机制。

后来，JDK 8 的 Lambda 表达式 也大量使用了 invokedynamic。

4.5.1 传统的 4 种调用指令的局限

#

• invokestatic：静态绑定（编译期就知道目标方法）
• invokevirtual / invokeinterface：基于对象类型的虚方法分派
• invokespecial：构造器、私有方法、super 调用

这些调用方式的特点：

• 调用目标在编译期基本确定（最多是虚方法表查找）；
• 不太适合动态语言那种：
  • 运行时改变方法绑定；
  • 根据调用上下文决定调用逻辑的场景。

4.5.2 invokedynamic 的思路：延迟绑定

#

invokedynamic 把「调用目标的确定」推迟到第一次执行时，并通过一个“引导方法（Bootstrap Method）”来完成绑定。

简单理解：

1. 字节码里有一条 invokedynamic，指向常量池里的某个 InvokeDynamic 项；

2. InvokeDynamic 项包含一个“引导方法句柄 + 调用点描述信息”；

3. 第一次执行到这条invokedynamic时：

   • JVM 调用引导方法（bootstrap method），交给它来决定：
     • 实际要调用哪个方法实现、用什么调用句柄（MethodHandle）；

4. 之后再次执行这个调用点时，可以直接使用缓存好的调用句柄，性能接近其他几种调用指令。

示意（非常简化）：

sequenceDiagram
    participant VM as JVM
    participant BSM as Bootstrap Method
    participant Target as 目标方法

    VM->>VM: 执行到 invokedynamic #X
    VM->>BSM: 调用引导方法，传入调用点信息
    BSM->>Target: 决定绑定到某个实际方法
    BSM-->>VM: 返回 MethodHandle（调用句柄）
    VM->>Target: 通过 MethodHandle 调用（并缓存）

4.5.3 Lambda 与 invokedynamic（只做直观感知）

#

写一段 Lambda 代码：

public class LambdaDemo {
    public static void main(String[] args) {
        Runnable r = () -> System.out.println("Hello Lambda");
        r.run();
    }
}

JDK8 之后，用 javap -c -v LambdaDemo，会在常量池中看到类似：

#... = InvokeDynamic #0:run()Ljava/lang/Runnable;

以及类中生成了一个静态引导方法：

private static java.lang.Runnable lambda$main$0();

整体流程（简化）大概是：

1. 编译器把 Lambda 表达式编译成 invokedynamic 调用；
2. JVM 在第一次执行该调用点时，调用 JDK 提供的引导方法（LambdaMetafactory.metafactory）；
3. 根据 Lambda 的目标类型（Runnable）、函数式接口方法签名等信息，构造一个合适的对象（可能是合成类实例、MethodHandle 等）；
4. 返回给 JVM，绑定到调用点上；
5. 下次执行时直接复用。

你暂时只需要知道两点：

1. Lambda 并不是简单的“匿名内部类语法糖”，而是借助了 invokedynamic 开放的动态调用机制；
2. invokedynamic 为各种动态语言 & 框架（动态代理、字节码增强等）提供了很强的扩展空间。

小结：理解字节码，对你有什么用？

#

本章我们从 .class 文件结构出发，理解了：

1. Class 文件的基本布局

   • 魔数、版本号、常量池、字段表、方法表、属性表；

2. 常量池是所有符号引用的“大字典”

   • 类、方法、字段、字符串等都在这里索引；

3. JVM 是一个基于栈的虚拟机

   • 字节码主要围绕“局部变量表 + 操作数栈”来运算；
   • 不同的调用指令对应不同的分派语义；

4. invokedynamic 是为动态语言 & Lambda 提供的延迟绑定调用机制。

这对日常开发有什么帮助？

• 看 javap 输出，能更准确地理解编译器把你的代码翻译成了什么执行路径；
• 做性能分析、调优时，知道某些写法为何容易或难以被 JIT 优化（比如内联失败的原因）；
• 看框架源码（尤其是涉及动态代理、字节码增强、Lambda等场景）时，不再停留在“语法糖表面”。

在接下来的第 5 章，我们会把视角从文件系统 & 字节码，转向 类加载子系统： 类是如何被加载（加载 → 验证 → 准备 → 解析 → 初始化），双亲委派为什么存在，框架如何自定义 ClassLoader，实现插件化、隔离等高级玩法。

（五）类加载子系统：类是怎么被“请进来”的？

#

本章目标：

• 搞清楚一个类从 .class 到“可以被 new / 调用”的完整生命周期
• 明白 双亲委派模型 是什么、为什么要这么设计
• 认识系统内置的几个重要 ClassLoader 以及如何自定义
• 知道哪些典型场景会“打破”双亲委派（SPI、容器、插件系统等）
• 能从日志和异常中判断常见类加载问题的成因与排查思路

5.1 类的生命周期：从“字节码”到“可用类型”

#

JVM 规范中，一个类从字节码到可以正常使用，大致要经历：

加载（Loading） → 验证（Verification） → 准备（Preparation） → 解析（Resolution） → 初始化（Initialization） → 使用（Using） → 卸载（Unloading）

前 5 个阶段就是通常所说的「类加载过程」，我们用一个图先串起来：

flowchart LR
    A[字节码来源\n.class/网络/内存] --> B[加载 Loading\n读取字节码，生成 Class 对象]
    B --> C[验证 Verification\n文件格式/语义/字节码验证]
    C --> D[准备 Preparation\n为静态变量分配内存并置默认值]
    D --> E[解析 Resolution\n符号引用 -> 直接引用]
    E --> F[初始化 Initialization\n执行 <clinit> 静态初始化]
    F --> G[使用 Using\nnew/调用/反射]
    G --> H[卸载 Unloading\nClassLoader 可回收时一并卸载]

下面逐个拆解（重点是：哪些阶段和我们日常开发强相关）。

5.1.1 加载（Loading）：找到类，读进来

#

加载阶段做三件事：

1. 通过类的全限定名找到并获取字节流
   • 可能是磁盘上的 .class 文件
   • 也可能是 jar 包、网络、内存中生成的字节数组，等等；
2. 将字节流转为 JVM 所需的内部数据结构
   • 在 HotSpot 中，会构造一个 InstanceKlass 等结构；
3. 在方法区中生成代表该类的 Class 对象，并把它与类的内部结构关联。

这部分最直接的体现就是：ClassLoader 的 findClass() / defineClass() 等方法。

5.1.2 验证（Verification）：别让“坏字节码”搞崩 JVM

#

JVM 必须保证执行的字节码是“安全”的，否则：

• 一个恶意 / 损坏的 .class 完全可以破坏虚拟机的安全性；
• Class 文件可能来自网络、动态生成，很容易出问题。

验证阶段大致会做：

1. 文件格式验证
   • 魔数是否 0xCAFEBABE
   • 版本号是否在 JVM 支持范围
   • 各个结构偏移、长度是否正确等；
2. 元数据验证
   • 是否有非法父类关系（比如继承 final 类）
   • 是否有不存在的字段/方法引用等；
3. 字节码验证（最复杂）
   • 操作数栈不会下溢/上溢
   • 类型匹配合法（比如不能把 int 当引用用）
   • 确保不会非法访问私有字段/方法等。

一般只有在：

• 加载「非 javac 编译」的字节码（比如手写/ASM 生成）
• 或者来自不可靠渠道的 .class

时，这部分才会真正“踩雷”。

5.1.3 准备（Preparation）：静态变量分配内存，先给“零值”

#

准备阶段做两件事：

1. 为类变量（static 字段）分配内存（方法区 / 元空间 + 堆的配合）；
2. 将这些变量初始化为“零值”（注意，不是你写的初始值）。

零值示例：

• int / short / byte / long → 0 / 0L
• float / double → 0.0f / 0.0d
• boolean → false
• 引用类型 → null

示例：

public class Demo {
    public static int a = 1;
    public static final int B = 2;
}

在 准备阶段：

• a 会被分配内存，值为 0（零值）；
• B 一般会被直接“放入常量池”（编译期常量折叠），不会在这里分配一般静态变量那样的内存。

真正把 a 设为 1，是在初始化阶段。

5.1.4 解析（Resolution）：符号引用 → 直接引用

#

前面在第 4 章讲常量池时提到：

字节码中引用类、字段、方法，都是通过符号引用（如：java/lang/Object、max:(II)I）来表示的。

解析阶段就是把这些“字符串形式的引用”变成“可以直接找到内存地址的引用”，比如：

• CONSTANT_Class → 类的元数据结构指针；
• CONSTANT_Methodref → 具体的方法元数据、入口地址；
• CONSTANT_Fieldref → 字段在对象内存布局中的偏移等。

注意：解析可以在初始化前做完，也可以在使用时懒加载（延迟解析），具体行为由 JVM 实现 & 参数决定。

5.1.5 初始化（Initialization）：执行 <clinit>，真正的“静态初始化”

#

初始化阶段干的主要事情：

执行类构造器 <clinit> 方法（如果有）

这个 <clinit> 方法由编译器自动收集 class 中：

• 所有 静态变量的显式赋值；
• 所有 static 代码块；

按源码出现顺序合并而成。

示例：

public class InitDemo {
    public static int a = 1;
    static {
        a = 2;
        b = 3;
    }
    public static int b = 4;
}

生成的大致 <clinit> 逻辑顺序是：

1. a = 1;
2. a = 2;
3. b = 3;
4. b = 4;

最终：a = 2, b = 4。

5.1.6 什么时候会触发“初始化”？（主动使用 vs 被动使用）

#

并不是“加载了类就立刻初始化”，规范中定义了主动使用（会触发初始化）和“被动使用”（不会）。

典型会触发类初始化的情况：

1. new 一个类的实例

new A();

2. **读取或设置类的静态变量**（非 `final` 编译期常量）

```java
System.out.println(A.value);
A.value = 10;

3. 调用类的静态方法

A.staticMethod();

4. **通过反射调用类（`Class.forName` 默认会初始化）**

```java
Class.forName("com.example.A");

5. 当类是程序入口（main 所在类）

不会触发初始化（被动使用）的几个常见例子：

1. 通过子类引用父类的静态字段，只触发父类初始化，不初始化子类：

System.out.println(SubClass.parentValue);

2. 使用 `A.class` 获取 `Class` 对象：

```java
Class<?> clazz = A.class; // 不会初始化

3. 访问 static final 编译期常量：

   // B.CONST 在编译期会被“内联”，访问的是使用处的常量，而非类的静态变量
   int x = B.CONST;
   

理解这一点，在“静态初始化顺序”、“懒加载单例”等问题中非常重要。

5.1.7 卸载（Unloading）：Class 何时能被回收？

#

类的卸载条件比较苛刻：

某个类要被卸载，前提是 加载它的 ClassLoader 本身可被回收，并且 这个类的 Class 对象没有任何强引用存在。

也就是说：

• 对于应用主类加载器（AppClassLoader）加载的类：
  • 通常随 JVM 生命周期存在，几乎不会被卸载；
• 通常只有在：
  • 使用自定义 ClassLoader 做模块热替换、插件系统、应用服务器中 war/ear 卸载时， 才会看到类真正被卸载。

反过来：

• 如果你自己写的框架或容器，在卸载模块时：
  • 没有正确断开 ClassLoader 的引用链（比如线程还持有它，或者静态单例引用到类实例）， 就会引起：
  • ClassLoader 无法回收 → 其加载的所有 Class 和相关元数据也无法回收 → Metaspace / 内存泄漏。

5.2 类加载的三种主要来源：文件、网络、运行时生成

#

只要你理解：“类加载器负责根据类名 → 字节流的映射”，那就很容易想到，字节流可以来自很多地方：

1. 本地磁盘上的 .class 或 jar 文件
2. 网络（如 Applet 时代，从 URL 加载）
3. 运行时生成的字节码（代理类、字节码增强）

示意图：

graph LR
    A[文件系统\n.class/jar] --> L[ClassLoader]
    B[网络\nHTTP/自定义协议] --> L
    C[运行时生成\nASM/CGLIB/Javassist] --> L
    L --> D[JVM 方法区/元空间]

常见例子：

• Spring CGLIB 代理类（*$EnhancerBySpringCGLIB$*）；
• MyBatis、Hibernate 等基于字节码增强的 ORM；
• 各种 RPC 框架基于接口动态生成代理 Stub。

对我们来说，核心是：

• 这些运行时生成的类 同样占用 Metaspace；
• 若创建过多、又不卸载，容易导致 Metaspace OOM。

5.3 双亲委派模型：为什么要“先问爸妈”？

#

所谓双亲委派模型（Parent Delegation Model）就是：

每个 ClassLoader 在加载类时，先把请求交给自己的父 ClassLoader， 只有当父亲说“我也不会”时，自己才尝试加载。

示意图（HotSpot 默认类加载器体系，JDK8 为例）：

graph TB
    BOOT[Bootstrap ClassLoader\nC++ 实现，加载核心类库 rt.jar等] 
    EXT[Ext ClassLoader\n扩展类加载器\nJDK8 之前]
    APP[AppClassLoader\n应用类加载器\n加载classpath]

    APP --> EXT
    EXT --> BOOT

类加载时的决策流程（伪代码）：

protected Class<?> loadClass(String name, boolean resolve) {
    // 1. 先检查这个类是否已经被加载过
    Class<?> c = findLoadedClass(name);
    if (c == null) {
        try {
            // 2. 把加载请求委托给父加载器
            if (parent != null) {
                c = parent.loadClass(name, false);
            } else {
                c = findBootstrapClassOrNull(name);
            }
        } catch (ClassNotFoundException e) {
            // 父加载器也加载不了，才轮到自己
        }

        if (c == null) {
            // 3. 自己尝试加载（如从自定义位置找字节码）
            c = findClass(name);
        }
    }
    if (resolve) {
        resolveClass(c);
    }
    return c;
}

5.3.1 为什么要双亲委派？

#

最重要的目的：安全 + 一致性。

1. 避免核心类被“篡改”或“伪装”

   • 假设没有双亲委派，你可以写一个名为java.lang.String 的类，

     如果被你自己的 ClassLoader 先加载，JVM 内部就会出现两个“String”：

     • 一个是 JDK 的，
     • 一个是你的；

   • 这会带来巨大混乱和安全隐患。

2. 保证基础类库的唯一性

   • 所有类都会优先使用 Bootstrap ClassLoader 加载的 JDK 类；
   • 避免“同一个全限定类名在同一个 ClassLoader 链中出现多份实现”。

3. 类版本兼容与依赖管理

   • 上层应用类依赖底层核心库（rt.jar 等）， 通过双亲委派可以确保优先加载底层统一版本。

5.3.2 “命名空间”的概念：ClassLoader + 类名 才唯一

#

一个重要结论：

在 JVM 里，“是否是同一个类”由 “ClassLoader 对象 + 全限定类名” 共同决定。

例如：Hello由 AppClassLoader 加载：

• 记为 (AppClassLoader, com.example.Hello)；

• 同一个.class又由你自定义的 Loader 加载：(MyClassLoader, com.example.Hello)。

JVM 认为：

• 这两个是“完全不同的类型”，不能互相赋值/强转，否则会 ClassCastException。

这在插件系统、容器多应用隔离时非常重要，也是后面讲“打破双亲委派”和“版本冲突”时的理论基础。

5.4 重要的类加载器：Bootstrap / Ext / App / 自定义

#

HotSpot（JDK8 以前）的三大“官方”类加载器：

1. Bootstrap ClassLoader（启动类加载器）
   • 使用 C/C++ 实现的一部分 JVM 代码；
   • 负责加载 JDK 核心类库：
     • JAVA_HOME/jre/lib/* 中的核心 jar（rt.jar 等）；
   • 在 Java 中 拿不到它的引用，getClassLoader() 返回 null 表示 Bootstrap。
2. Extension ClassLoader（扩展类加载器）（JDK8 前）
   • 加载 JAVA_HOME/jre/lib/ext 或 java.ext.dirs 指定目录中的 jar；
   • 在 JDK9 之后被模块系统替代，逐渐淡出。
3. Application ClassLoader（系统/应用类加载器）
   • 又叫 System ClassLoader；
   • 负责加载 -classpath / -cp 或 CLASSPATH 环境变量指定的路径；
   • 大多数我们写的业务代码、第三方依赖 jar，都是它加载的。

示意图（JDK8）：

graph TB
    BOOT[BootstrapClassLoader\n加载<JAVA_HOME>/jre/lib/*.jar] 
    EXT[ExtClassLoader\n加载<JAVA_HOME>/jre/lib/ext/*.jar]
    APP[AppClassLoader\n加载 -classpath 中的类]

    APP --> EXT
    EXT --> BOOT

5.4.1 JDK9+：模块化后的类加载器变化（简单了解）

#

JDK9 引入模块系统（Jigsaw）后，类加载器体系有部分调整：

• ExtClassLoader 被移除，改为 PlatformClassLoader 等；
• 模块路径（--module-path）分担了部分类查找责任。

常见 API：

ClassLoader boot = Object.class.getClassLoader();          // null，表示 Bootstrap
ClassLoader app  = ClassLoader.getSystemClassLoader();     // AppClassLoader
ClassLoader platform = app.getParent();                    // JDK9+ 是 PlatformClassLoader

日常开发中：主要关注 AppClassLoader（系统类加载器）和自定义类加载器即可。 模块化本身（module-info.java）在兼容旧项目时要注意，但超出本篇重点。

5.4.2 自定义 ClassLoader 常见用途

#

重写 ClassLoader 的典型场景：

1. 应用服务器 / 容器
   • 如 Tomcat、Jetty、JBoss、OSGi 容器等；
   • 不同 web 应用使用不同的 ClassLoader 加载，彼此隔离。
2. 插件系统 / 业务多租户
   • 比如“一个平台，多个独立插件包动态加载 & 卸载”；
   • 每个插件使用单独 ClassLoader，可以实现版本隔离和热插拔。
3. 加密 / 混淆 / 自定义资源来源
   • .class 文件不放在常规文件系统，而是放在数据库、网络、压缩包等；
   • 或者先做解密再 defineClass。

简单示例（极简自定义 ClassLoader）：

public class MyClassLoader extends ClassLoader {
    public MyClassLoader(ClassLoader parent) {
        super(parent);
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        // 1. 根据类名找到字节码（从文件、网络、加密存储等）
        byte[] bytes = loadClassBytes(name);
        // 2. 调用 defineClass 转为 Class 对象
        return defineClass(name, bytes, 0, bytes.length);
    }

    private byte[] loadClassBytes(String name) {
        // TODO: 实现你自己的查找逻辑
        return new byte[0];
    }
}

注意：一般不要直接重写 loadClass，而是重写 findClass，以免破坏双亲委派的基本流程，除非你非常清楚要做什么。

5.5 打破双亲委派的典型案例

#

虽然双亲委派是**“默认/推荐”模型**，但现实需求中有不少场景必须绕开它或在某些路径上“打破”：

• 否则无法实现插件隔离、热部署、SPI 等高级特性。

5.5.1 SPI（Service Provider Interface）与线程 ContextClassLoader

#

Java 提供了 SPI 机制（java.util.ServiceLoader）来做“接口 + 实现解耦”，典型使用方式：

ServiceLoader<JdbcDriver> loader = ServiceLoader.load(JdbcDriver.class);
for (JdbcDriver driver : loader) {
    // 使用 driver
}

问题是：

• ServiceLoader 自身是由 Bootstrap / Platform ClassLoader 加载的；
• 但驱动实现（如 MySQL JDBC）通常由 AppClassLoader 或自定义 Loader 加载；
• 如果 SPI 只通过自己的 ClassLoader 去加载实现类，容易“看不见”下游类。

解决思路：

引入 线程上下文类加载器（Thread ContextClassLoader） 概念

• 由上层应用代码设置一个 ContextClassLoader 到当前线程；
• 底层框架（SPI 实现）在加载类时，不再只用自己的 ClassLoader，而是优先使用线程上下文加载器。

示例：

ClassLoader appLoader = ...;
Thread.currentThread().setContextClassLoader(appLoader);

底层框架的典型代码：

ClassLoader cl = Thread.currentThread().getContextClassLoader();
if (cl == null) {
    cl = ClassLoader.getSystemClassLoader();
}

这相当于：

• 一条“向上反向委派”的通路；
• 线程上下文 ClassLoader 反向打破了严格的父子链条，使得“上层可以为下层决定怎么加载类”。

5.5.2 Tomcat / Spring Boot / OSGi：多应用、多版本并存

#

应用服务器/容器需要达到的目标：

• 每个 web app 之间类相互隔离：
  • A 应用不能访问 B 应用的内部实现类；
  • 不同应用可以使用不同版本的第三方库；
• 服务器容器本身的类与应用类也要隔离：
  • 避免应用把容器的类“污染”或覆盖。

实现方式通常是：

• 容器启动时先构建自己的 ClassLoader；
• 每个应用（war 包）再构建一个或一组单独的 ClassLoader；
• 加载类时，优先在“当前应用空间”查找，再必要时委派给上层 ClassLoader。

这在实践中对双亲委派做了精细改动：

• 有些路径是 先自己找，再委派（打破“完全向上委派”）；
• 有些路径还是遵守原始的父子委派模型。

OSGi 甚至在此基础上引入了“模块（Bundle）”和包级别导入/导出概念：

• 不同 Bundle 有独立的类空间；
• 通过 import/export 包名来建立联系；
• 本质上是一套更精细化的“类加载 + 版本管理”机制。

5.5.3 其他“打破”场景一览

#

1. 热部署 / 热替换
   • 使用自定义 ClassLoader 承载一个模块的所有类；
   • 卸载时，丢弃整个 ClassLoader，即可达到“卸载所有类”的效果；
   • 再创建一个新的 ClassLoader 加载新版模块，实现热替换。
2. 字节码增强 & 代理框架
   • 运行时生成的新类（如 UserService$$EnhancerByCGLIB$$xxx）常常由一个专门的 ClassLoader 加载；
   • 这样可以避免和原始类的命名空间混淆。
3. 安全沙箱
   • 某些场景下，为了限制脚本或插件能访问的类范围，会构建带有权限控制的 ClassLoader。

结论：

双亲委派是“主干道”，但在工程实践中，我们常常通过“定制支路”来满足复杂的隔离/动态需求。 这些支路如果设计不好，就很容易引发：类冲突、版本不一致、ClassLoader 泄漏等问题。

5.6 类加载相关的常见问题 & 排查思路

#

类加载问题往往表现为几类典型异常：

1. ClassNotFoundException
2. NoClassDefFoundError
3. 各种 LinkageError（ClassFormatError、UnsupportedClassVersionError、NoSuchMethodError 等）
4. ClassCastException（往往是不同 ClassLoader 加载的同名类）
5. Metaspace / PermGen OOM（类加载器泄漏）

下面按症状简单给出“定位思路”。

5.6.1 ClassNotFoundException vs NoClassDefFoundError

#

• ClassNotFoundException：受检异常（checked）
  • 多由 Class.forName("xxx")、ClassLoader.loadClass("xxx") 抛出；
  • 表示在当前类加载器可见范围内找不到这个类；
  • 常见原因：
    • 缺 jar；
    • 类路径错误；
    • 使用了错误的 ClassLoader；
• NoClassDefFoundError：Error
  • 通常是在类被成功编译 & 验证过一次，之后某次再用时找不到；
  • 例如：
    • A 类引用了 B 类中的某个方法，但 B 类被替换/删掉了；
    • 运行时类路径和编译时期不一致。

排查时：

• 关注异常堆栈中到底是哪个类没找到；
• 看抛出异常的地方是：
  • 手动反射调用？
  • 还是在某个方法执行过程中（JVM 自动解析时）？

5.6.2 各类 LinkageError：版本冲突 / 定义不一致

#

LinkageError 家族主要出现在类的“链接”阶段：

常见类型：

1. ClassFormatError：Class 文件格式有问题（非正常 javac 编译产物）；

2. UnsupportedClassVersionError：JDK 版本不兼容,用 JDK17 编译、在 JDK8 运行；

3. NoSuchFieldError/NoSuchMethodError：

   • 编译期基于某个版本的 jar；
   • 运行期换了另一个版本，字段/方法签名变化了；

4. IncompatibleClassChangeError：类的继承关系或接口实现发生了不兼容变化。

一般是典型的“编译期依赖和运行期依赖版本不一致”导致的。 排查方法：

• 确认打包时引用的 jar 版本；
• 确认运行时（启动脚本 / 容器 classpath）实际加载的 jar 版本；
• 使用 -verbose:class 或 -XX:+TraceClassLoading 观察相关类是被谁，从哪里加载的。

5.6.3 ClassCastException：往往是“同名不同类加载器”的锅

#

除了真正类型不兼容外，还有一种非常隐蔽的情况：

同一个类名，由两个不同的 ClassLoader 各加载了一份， JVM 认为这是“两个完全不同的类型”，互相转换就会 ClassCastException。

典型场景：

• 容器中一个类被宿主层和应用层各加载一次；
• 插件系统中不同插件 ClassLoader 之间直接传递对象；
• 某些框架内部使用独立 ClassLoader 加载其依赖类。

排查方法：

1. 打印出参与强转的两个对象的 Class 信息：

System.out.println(obj.getClass() + "@" + obj.getClass().getClassLoader());

2. 使用 -verbose:class 查看该类到底是由哪个 ClassLoader 从哪儿加载的；

3. 梳理类加载器关系，避免“相同依赖被加载两份又互相传递”。

5.6.4 Metaspace / PermGen OOM：类加载器泄漏

#

JDK8+ 常见错误信息：

• java.lang.OutOfMemoryError: Metaspace

常见于：

• 热部署 / 热加载环境（Tomcat、Spring Boot DevTools、自己写的插件系统）；
• 动态生成大量类（CGLIB、Javassist 等）但从不卸载（ClassLoader 一直被引用）。

典型原因：

1. 一个模块或应用用单独的 ClassLoader 加载；
2. 卸载时，模块中的：
   • 静态变量、单例对象仍然被外部引用；
   • 线程池中的线程还持有 ContextClassLoader；
   • Timer / ScheduledExecutorService / 缓存等仍引用模块类；
3. 导致 ClassLoader 有引用链，GC 无法回收；
4. 导致其加载的所有 Class + 字节码 + 常量池 + 相关数据无法回收；
5. 随着重载次数增加，Metaspace 持续上涨，最终 OOM。

排查建议：

• 用 jmap -clstats（某些版本支持）或 jcmd VM.classloaders 看类加载器分布；
• Heap dump 中重点查看：
  • 自定义 ClassLoader 实例数量；
  • 以及是谁在引用它们；
• 优化：
  • 卸载前主动关闭线程池、释放静态资源；
  • 避免使用“长生命周期的线程”持有短生命周期模块的 ClassLoader。

小结：类加载知识在实战中如何落地？

#

本章从“类生命周期”和“类加载器体系”出发，讲清了：

1. 类加载的 5 个关键阶段：

   加载 → 验证 → 准备 → 解析 → 初始化

   • 明白了静态变量赋值的时机、类何时会被初始化；

2. 双亲委派模型 的设计初衷：安全与一致性；

3. HotSpot 中几种重要 ClassLoader 的职责与层级；

4. 在容器 / 插件 / SPI 场景里，为什么需要在局部“打破”双亲委派；

5. 类加载相关的典型异常 & 排查路径。

这些知识会直接影响你在下面场景中的表现：

• 从 GC 日志和 OOM 分析中，判断是不是 Metaspace/类加载器泄漏；
• 在多模块、多应用环境中，设计合理的 ClassLoader 隔离策略；
• 使用 ServiceLoader / SPI / 插件系统时，正确处理 ContextClassLoader；
• 阅读 Tomcat / Spring Boot / OSGi 等框架源码时，不再对“层层 ClassLoader”完全迷茫。

下一章（第 6 章），我们会把视角移到“堆上的对象”，深入理解： 对象是如何被创建、在内存中长成什么样、JIT 如何让一些对象“消失不见”——这将直接关系到 GC 行为和性能优化。

（六）对象的创建、布局与访问：搞懂“对象是怎么长出来的”

#

本章目标：

• 搞清楚 new 背后到底发生了什么
• 理解 HotSpot 中 对象在内存里的真实样子（对象头、对齐、数组）
• 知道 JVM 如何通过“句柄/直接指针”访问对象
• 明白逃逸分析、标量替换、栈上分配这些 JIT 优化大致在干什么
• 能从“对象太多/没回收”联想到几类典型 OOM & 泄漏模式

6.1 对象创建流程概览：一次 new 的旅程

#

以最常见的创建方式为例：

User user = new User();

在 JVM 内部，大概会经历下面几步：

flowchart LR
    A[检查类是否已加载\n& 通过验证] --> B[分配内存\n在堆中找一块区域]
    B --> C[设置对象头\nMarkWord + Klass 指针]
    C --> D[零值初始化\n字段全部置 0/null]
    D --> E[执行显式初始化\n& 构造方法 <init>]
    E --> F[返回引用给 Java 栈\nuser 指向新对象]

按顺序稍微展开。

6.1.1 类加载检查：new 之前，必须“认识这个类”

#

字节码层面，对应指令是 new：

0: new           #2  // class User
3: dup
4: invokespecial #3  // Method User."<init>":()V
7: astore_1

执行 new 时，JVM 会先检查：

• 这个类对应的元数据是否已经在方法区 / Metaspace 中存在；
• 如果没有，就触发类加载过程（上一章讲的加载 → 验证 → 准备 → 解析 → 初始化）。

所以：

• 第一次使用某个类时，常会在 new 时顺带完成其 <clinit> 静态初始化逻辑；
• 之后再 new 该类的实例，就不会再重复这些加载/初始化操作了。

6.1.2 分配内存：堆上找一块“连续区域”

#

类已经准备好了，现在要在堆上给这个对象划一块地。

HotSpot 里对象分配主要有两种策略：

1. 指针碰撞（Bump-the-pointer）
2. 空闲列表（Free List）

是否使用哪种，取决于：

• 该内存区域是否是“一块规整的连续空间”；
  • 新生代 Eden 通常是连续的 → 用指针碰撞；
  • 老年代可能存在碎片 → 较多采用空闲列表。

a. 指针碰撞

#

示意：

graph LR
    subgraph Eden[新生代 Eden 区]
        A[已使用] ---|分界指针| B[未使用]
    end

• JVM 维护一个“分界指针”指向当前已用区域的末尾；
• 分配新对象时，只需：
  • 检查剩余空间是否够；
  • 然后把分界指针往后挪对象大小那么多；
• 优点：非常快，基本就是一个“指针自增”。

b. 空闲列表

#

当内存不再是整块时（有碎片），就会维护一个“空闲块链表/树”：

• 分配时，在空闲列表中找到一块足够大的区域；
• 分配后更新该空闲块信息；
• 类似于传统堆分配算法（first fit, best fit 等）。

6.1.3 TLAB：多线程分配如何避免锁竞争？

#

在高并发场景下，如果所有线程都抢同一个“分界指针”，势必会有大量 CAS/锁竞争。

所以 HotSpot 引入了 TLAB（Thread Local Allocation Buffer）：

graph LR
    subgraph Eden[Eden]
        T1[TLAB - 线程1]
        T2[TLAB - 线程2]
        T3[TLAB - 线程3]
    end

• 每个线程在 Eden 里预留一小块区域作为 TLAB；
• 线程内部分配对象时，只在自己的 TLAB 里移动指针，不与其它线程竞争；
• TLAB 用尽，再向 Eden 申请新的 TLAB 块；
• TLAB 外的大对象或特殊对象，才需要走“慢路径”分配。

总结一下：

• 日常大多数对象创建非常便宜 —— 就是在线程本地 TLAB 上挪一下指针；
• 这也是 Java 经常被说“创建对象并不贵”的底层原因之一。

6.1.4 内存布局初始化 + 构造器调用

#

分配完空间后，JVM 会做三类初始化工作：

1. 零值初始化（Zeroing）
   • 把对象实例数据部分的每个字段置为零值：
     • 数值型 → 0 / 0L / 0.0f / 0.0d
     • boolean → false
     • 引用 → null
   • 这一步保证了Java 层面“默认值”语义。
2. 设置对象头（Header）
   • 填写 Mark Word（hash、GC 年龄、锁标志等默认值）；
   • 填写 Klass 指针（指向类元数据，以便找到方法表、字段布局等）。
3. 执行构造方法 <init>
   • 字节码指令 invokespecial 调用构造器；
   • 执行你在构造器和字段显式初始化中写的代码。

小结：

• 零值初始化 + 设置对象头 是“JVM 层面”的事情；
• 字段显式初始化 + 构造器 是“Java 语言层面”的事情。

6.2 Java 对象内存布局：对象头 + 实例数据 + 对齐填充

#

在 HotSpot 上，一个典型 Java 对象（非数组）的内存布局可以抽象为：

+----------------------+  <-- 对象起始地址
| 对象头 (Header)      |
|  - Mark Word         |
|  - Klass Pointer     |
+----------------------+
| 实例数据 (Fields)    |
|  - 各种字段          |
+----------------------+
| 对齐填充 (Padding)   |
+----------------------+

数组对象则在对象头和实例数据间多一个“数组长度”字段。

6.2.1 对象头（Header）：Mark Word + Klass 指针

#

a. Mark Word：对象运行时元信息

#

在 64 位 HotSpot 上通常占 8 字节（32 位上占 4 字节），内部结构会随状态变化。典型包含：

• 对象的 哈希码（hashCode）（可能被延迟计算）；
• GC 年龄（在新生代中经历过多少次回收）；
• 锁状态标志（无锁、偏向锁、轻量级锁、重量级锁）；
• 对应的锁记录或监视器指针等。

你可以把 Mark Word 看成：

一块会随着对象状态不断变化的小“tag 区域”。

b. Klass Pointer：指向类元数据

#

• 指向方法区 / Metaspace 中表示该类的 Klass 元数据结构；
• JVM 通过它可以：
  • 知道对象属于哪个类；
  • 找到虚方法表（vtable）；
  • 解析字段在对象内存中的偏移、方法的入口地址等。

64 位环境下，如果开启了 压缩类指针（UseCompressedClassPointers），这个指针占用 4 字节，否则是 8 字节。

6.2.2 实例数据（Fields）：字段是怎样排布的？

#

对象的字段在实例数据区域里按一定规则排布：

1. 先排父类的实例字段；
2. 再排子类自己的字段；
3. 同一层次中：
   • HotSpot 会按字段类型大小进行重排序（并不完全严格按源码顺序），以减少对齐填充和内存碎片；
   • 一般会让大字段（long/double）对齐到 8 字节边界。

这意味着：不要依赖“字段在内存里的顺序”等未保证行为做任何逻辑，Java 规范并不承诺这一点。

6.2.3 对齐填充（Padding）：按 8 字节对齐

#

HotSpot（64 位）通常要求对象大小为 8 字节的整数倍。 因此，如果“对象头 + 实例数据”的总大小不是 8 的倍数，就会在尾部 填充一些对齐字节。

示例（大致估算，具体依赖压缩指针等配置）：

class Simple {
    int  a;   // 4 bytes
    long b;   // 8 bytes
    Object ref; // 4 or 8 bytes (压缩指针下为 4)
}

假设：

• Mark Word: 8 bytes
• Klass Pointer: 4 bytes（压缩类指针）
• 对象头：12 字节，为对齐一般视作 16

字段大致布局（非严格）：

• a：4 字节
• b：8 字节（需 8 字节对齐，可能在前面插入 4 字节 padding）
• ref：4 字节（压缩 OOP）

最终对象大小可能被对齐到 24 / 32 字节（具体可用 JOL 实测）。

6.2.4 用 JOL 查看对象布局

#

JOL（Java Object Layout） 是一个专门用来分析对象布局的工具。

示例：

public class JolDemo {
    int a;
    long b;
    Object ref;

    public static void main(String[] args) {
        System.out.println(org.openjdk.jol.info.ClassLayout.parseClass(JolDemo.class).toPrintable());
    }
}

输出中会详细列出：

• 对象头各部分大小；
• 字段的偏移位置；
• 总体对象大小 & 对齐情况。

建议：实际玩一下 JOL，会对“对象内存开销”有非常直观的感受，对后面谈“对象瘦身/内存优化”很有帮助。

6.2.5 数组对象：比普通对象多一个“长度”

#

数组对象在布局上和普通对象相似，只是多一个 length 字段：

+----------------------+
| 对象头 (Mark, Klass) |
+----------------------+
| 数组长度 (int)       |
+----------------------+
| 数组元素             |
+----------------------+
| 对齐填充             |
+----------------------+

比如 int[10] 数组：

• 对象头（12/16 字节）
• length（4 字节）
• 10 个 int（40 字节）
• 对齐到 8 的倍数。

数组元素本身的布局遵从元素类型规则：

• 原始类型数组：一块连续的原始值；
• 引用类型数组：连续的引用（指针），真正对象在堆的其他位置。

6.3 对象访问方式：句柄 vs 直接指针

#

JVM 规范并没有规定“引用”内部必须是指针，具体实现可以自己选。总体有两种典型方案：

graph LR
    subgraph Handle[句柄访问]
        A[引用] --> B[句柄表]
        B --> C[对象实例]
        B --> D[类型信息]
    end

    subgraph Direct[直接指针访问]
        E[引用\n直接指向对象]
        E --> F[对象头（含类型信息指针）]
    end

6.3.1 句柄访问（Handle）

#

设计：

• 堆上维护一个句柄池（Handle Table）；
• Java 引用变量存的是“句柄地址”；
• 句柄中包含：
  • 对象实例数据地址；
  • 类元数据地址（或 Klass 指针）。

优点：

• 对象移动更安全：

  • GC 做压缩/整理时，只需要更新句柄指向的实例地址；
  • Java 中的所有引用仍然指向原句柄位置，无需更新；

• 适合对象移动频繁的场景。

缺点：

• 访问多了一次间接寻址：引用 → 句柄 → 对象。

6.3.2 直接指针访问（Direct Pointer）

#

HotSpot 采用的是直接指针访问方案：

• Java 引用直接存储“对象起始地址”；
• 对象头中包含 Klass 指针等信息，JVM 可以通过对象头查元数据。

优点：

• 访问速度稍快（少一次指针间接）；
• 内存布局更简单。

缺点：

• GC 移动对象时，需要更新所有指向它的引用；
• 这就需要 GC Root 分析 + 遍历引用图，但现代 GC 本来就要做这些工作，因此成本可接受。

6.3.3 对我们意味着什么？

#

日常开发中：

• 你不需要关心“引用内部是不是指针”；
• 但理解 HotSpot 使用“直接指针访问”有助于你理解：
  • 为什么需要 压缩指针（Compressed Oops） 优化空间；
  • 对象头 + Klass 指针布局是如何被利用的；
  • GC 在移动对象时必须更新哪些引用。

6.4 逃逸分析 & 标量替换：JIT 如何让“对象消失”

#

当我们写：

public String concat(String a, String b) {
    StringBuilder sb = new StringBuilder();
    sb.append(a);
    sb.append(b);
    return sb.toString();
}

直觉上有：

• 一个 StringBuilder 对象；
• 若干临时 String 对象等。

但在充分优化后，JIT 有可能做到：

• 不真正分配 StringBuilder 对象在堆上；
• 直接把相关逻辑“展开”为栈变量或寄存器中的操作。

关键技术：逃逸分析（Escape Analysis） 和基于它的优化：栈上分配、标量替换、锁消除。

6.4.1 什么是“逃逸”？三种层级

#

逃逸分析关心的是：

一个对象是否会“逃出”当前作用域 / 当前线程？

大致分三类：

1. 不逃逸（No Escape）

   • 对象只在当前方法内部使用，不被返回，不赋值给外部变量；

   • 例如：

     void foo() {
         Point p = new Point(1, 2);
         int x = p.x + p.y;
     } // p 在方法结束后再也不需要
     

2. 方法逃逸（Arg Escape / Method Escape）

   • 对象被作为参数传递到其他方法；
   • 或被赋值给更大作用域的变量，但仍未跨线程。

3. 线程逃逸（Global Escape）

   • 对象被存入共享静态变量、逃逸到堆上被其他线程访问；
   • 例如存入全局集合、发布到其他线程。

6.4.2 基于逃逸分析的几种优化

#

当 JIT 检测到一个对象不会逃逸时，可以做三类优化：

a. 栈上分配（Stack Allocation）

#

• 原本应该在堆上分配的对象，直接在栈帧中分配；
• 方法执行结束后，栈帧销毁，对象随之销毁，不需要 GC 处理。

简化效果：

• 减少堆上的对象数量；
• 减少 GC 压力。

注意：

• “栈上分配”是一个概念结果；HotSpot 实现中往往更进一步做“标量替换”。

b. 标量替换（Scalar Replacement）

#

如果一个对象不逃逸，而且仅仅作为“若干字段的组合”使用：

• JIT 可以把对象拆解成若干独立标量变量（int、long 等）；
• 所有对该对象的操作都被编译期静态化，根本不再需要这个对象的内存布局。

示例（概念）：

class Point { int x, y; }

void foo() {
    Point p = new Point();
    p.x = 1;
    p.y = 2;
    int r = p.x + p.y;
}

经过标量替换后，相当于：

void foo() {
    int px = 1;
    int py = 2;
    int r = px + py;
}

真正运行时不会存在 Point 这个对象的实例。

c. 锁消除（Lock Elimination）

#

如果 JIT 发现：

• 某个带有 synchronized 的对象锁，
• 关联的对象没有发生线程逃逸（只在当前线程内部使用）；

那么它可以推断：

其实不存在“并发访问”这个场景。

于是，可以消除这部分同步代码开销。

典型代码：

public String concat(String a, String b) {
    StringBuffer sb = new StringBuffer(); // 内部方法是 synchronized 的
    sb.append(a);
    sb.append(b);
    return sb.toString();
}

• 在单线程 & 对象不逃逸的情况下，锁是可以被完全消除的。

6.4.3 如何观察 & 验证逃逸分析优化？

#

在生产中你无需显式开启，它默认开启（C2 编译器），但你可以通过参数做一些验证：

常见参数（JDK8 HotSpot，部分在高版本中有调整）：

# 显式开启/关闭逃逸分析（一般默认是开的）
-XX:+DoEscapeAnalysis
-XX:-DoEscapeAnalysis

# 打印相关优化日志，了解哪些对象被标量替换/锁消除
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintEscapeAnalysis
-XX:+PrintEliminateAllocations

一个典型的实践建议：

• 不要过早为了“相信栈上分配/标量替换”而写奇怪代码；
• 但要知道：
  • “短命小对象”在 JVM 下并没有那么可怕；
  • 不要为了减少对象数去写复杂可变代码，反而破坏了 JIT 优化机会。

6.5 常见 OOM：对象过多 / 引用未释放 / 内存泄漏模式

#

对象创建 & 布局搞清楚后，自然就会联想到：对象太多/没回收 → OOM / GC 压力。

这里先按“现象 → 原因模式”做一个归类，后面 GC & 调优章节会更细讲。

6.5.1 真·对象太多：业务确实需要那么多数据

#

典型场景：

• 一次把 1000 万条数据库记录全部 load 到内存；
• 把整个 Excel/图片/文件内容全部读入内存做处理；
• 使用了大量缓存、预加载数据结构，但容量设得过大或没有上限。

表现：

• 堆使用率稳定居高不下；
• GC 频繁且难以回收出可用空间；
• java.lang.OutOfMemoryError: Java heap space。

思路：

• 分批处理（流式处理 / 分页 / 迭代器）；
• 限制缓存大小（LRU/LFU/基于容量/基于时间的过期策略）；
• 必要时做数据抽样或降维处理，而不是“什么都全量放内存”。

6.5.2 “伪泄漏”：短时间对象风暴，GC 跟不上

#

典型场景：

• 瞬时高并发大流量，产生大量临时对象；
• 日志格式化、JSON 编解码、字符串拼接、集合创建等非常密集；
• 短期内新生代被迅速填满，引发频繁 Minor GC；
• 如果对象晋升速度过快或老年代空间不足，会进一步触发 Full GC。

表现：

• 堆的整体占用在一段时间跨度上是有起有落的（没有明显泄漏趋势）；
• 但在短时间窗口内，GC 频率很高，甚至 Full GC；
• 可能伴随着接口延迟抖动。

思路：

• 减少不必要的临时对象创建；
  • 例如：尽量复用 StringBuilder、合理设计 DTO、避免过度“装箱/拆箱”；
• 合理配置新生代大小，提高吞吐型 GC 效率；
• 在高并发路径上使用更轻量的序列化格式/库。

6.5.3 真·内存泄漏：对象本该被回收，却有“暗线引用”

#

Java 有 GC，并不意味着没有内存泄漏， 它只保证：没有引用的对象一定能被回收，但被错误引用住的“垃圾”没法帮你判断。

典型“泄漏模式”包括（但不限于）：

a. 静态集合持有

#

public class Cache {
    private static final List<Object> CACHE = new ArrayList<>();
}

• 把请求、Session、临时对象、“缓存”全部扔到静态集合里；
• 没有相应的淘汰机制或删除逻辑；
• 随运行时间增长，集合越来越大，最终撑爆堆。

b. 监听器 / 回调未注销

#

• 注册了各种 Listener、Observer；
• 卸载模块/用户退出/请求结束时，并没有从监听列表中移除；
• Listener 一直持有业务对象引用，导致整条引用链无法被回收。

c. ThreadLocal 使用不当

#

ThreadLocal 正常使用：

• 键：ThreadLocal 实例（弱引用）；
• 值：真正需要存放在线程局部的数据（强引用）。

泄漏风险来源：

• 线程（如线程池中的工作线程）是长生命周期的；

• ThreadLocal 不再使用时，如果你不remove()：

  • 键可能因为弱引用被 GC 回收，但值仍被 ThreadLocalMap 的 Entry 强引用着；

• 线程存活期间，这部分值不会释放。

实际上：

• HotSpot 做了清理过期 key 的逻辑（get/set/remove 时会清理）；
• 但仍然建议：使用完毕后显式 remove()，尤其在线程池场景。

d. 自定义缓存或 LRU 实现不当

#

• 自己用 HashMap 做缓存；
• 没有 TTL / 容量限制，或者键的 equals/hashCode 有 bug；
• 长期运行后缓存逐渐“无上限”增长。

6.5.4 如何排查“对象相关”的 OOM？

#

后面 GC & 工具章节会详细展开，这里先给个最小 checklist：

1. 确认是哪类 OOM

   • Java heap space / Metaspace / Direct buffer memory / unable to create new native thread …
   • 确保真的是“对象太多 → 堆不够”，而不是其他区域。

2. 抓一次堆转储（Heap Dump）

   • 可使用：

   jmap -dump:format=b,file=heap.hprof <pid>
   

   • 或在 OOM 时通过 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path 自动生成。

3. 使用 MAT / VisualVM / IDEA Profiler 打开 dump

   • 看哪种类型的对象最多；
   • 看大对象的引用链（Path to GC Roots）：
     • 是被静态变量持有？
     • 是被某个线程的局部变量/栈帧持有？
     • 是被某个单例/缓存几十万条持有？

4. 定位到具体业务逻辑

   • 例如定位到某个静态 Map；
   • 再回代码，补上：
     • 容量限制 / 过期策略；
     • 或在适当时机 clear()。

小结：对象视角下的 JVM 认知补全了什么？

#

本章从“对象”的视角补全了 JVM 里的一些关键拼图：

1. 一次new 背后的完整链路：

   • 类加载检查 → 堆上分配（TLAB/指针碰撞/空闲列表） → 对象头 & 零值初始化 → 构造函数；

2. HotSpot 中对象的内存布局：

   • 对象头（MarkWord + Klass 指针） + 实例数据 + 对齐填充；
   • 数组对象比普通对象多一个 length 字段；

3. JVM 访问对象的方式：

   • 句柄 vs 直接指针，HotSpot 选择了后者；

4. 逃逸分析 & 标量替换：

   • JIT 能让很多短命小对象“消失”，减少实际堆分配 & GC 压力；

5. 从“对象太多/没释放”联想到几类典型 OOM / 泄漏模式。

这些内容，会在后面讲：

• GC 算法与收集器（对象生命周期 & 代际假说）
• JMM 与并发（对象头的锁标志位、偏向锁等）
• 调优与诊断（Heap Dump 分析对象分布）

时不断用到。

下一章（第 7 章），我们将切换到并发视角，系统地梳理 Java 内存模型（JMM）、happens-before、volatile 与锁优化 —— 也就是“多线程下，对象的读写到底是如何被保证可见、有序、原子的”。

（七）JMM 与并发语义：从“看不见的重排序”开始

#

本章目标：

• 知道为什么需要 Java 内存模型（JMM），它试图解决什么问题
• 懂得“主内存 / 工作内存”这个抽象，以及 CPU 缓存与指令重排序的影响
• 记住 原子性 / 可见性 / 有序性 三大问题
• 掌握 happens-before 规则，知道 volatile / synchronized 在 JMM 中分别做了什么
• 理解偏向锁、轻量级锁等锁优化大致原理
• 理解 final 字段的特殊语义与“安全发布”
• 能用 JMM 视角分析几种常见并发 Bug 模式（单例乱序、双重检查锁等）

7.1 为什么需要 Java 内存模型（JMM）？

#

从单线程转到多线程，刚开始常见的直觉是：

“所有线程共享一个堆，大家读写同一个变量，应该就是你写我就能立刻看到。”

现实不是这样，原因在于底层硬件 & 编译器做了大量优化：

• CPU 有多级缓存（L1/L2/L3），不同核心的缓存内容不一定立刻同步；
• 编译器（包括 JIT）会进行指令重排序，只要不改变“单线程语义”即可；
• 很多指令是非原子的，比如 i++ 实际会被拆成多条机器指令。

结果就是：

• 在没有适当同步的情况下，多线程程序的行为变得“不可预测”；
• 在不同的 CPU / 不同的编译器 / 不同的 JDK 版本上表现还可能不同。

JMM 的目标：

• 定义一个语言层面的内存模型，
• 在它之上构建“多线程程序的可见性 & 有序性语义”，
• 让 Java 程序员不用直接脑补一堆 CPU & 缓存细节。

简单说：

JMM 是“Java 语言层面”给你的承诺，它告诉你：
在多线程场景下，只要你用了这些同步原语（volatile、synchronized 等），
程序的行为就会在所有平台上都一致。

7.2 主内存与工作内存：线程之间如何“说话”？

#

JMM 给出了一个抽象模型（与真实硬件不一一对应，但便于理解）：

graph LR
    subgraph Main[主内存 Main Memory]
        V[x 变量的共享值]
        W[其他共享变量...]
    end

    subgraph T1[线程 1]
        L1[工作内存\n（寄存器/CPU 缓存的抽象）]
        L1 -->|读/写| V
    end

    subgraph T2[线程 2]
        L2[工作内存\n（寄存器/CPU 缓存的抽象）]
        L2 -->|读/写| V
    end

JMM 抽象出：

• 主内存：

  • 存放所有共享变量（对象字段、静态字段、数组元素）；

• 每个线程都有自己的工作内存：

  • 存的是主内存变量的“拷贝”（或缓存）；
  • 线程只直接读写自己工作内存中的变量副本；
  • 最终通过特定协议把修改刷回主内存，让其他线程可见。

一个典型现象：

public class Visibility {
    static boolean running = true;

    public static void main(String[] args) throws Exception {
        Thread t = new Thread(() -> {
            while (running) {
            }
            System.out.println("stopped");
        });
        t.start();

        Thread.sleep(1000);
        running = false; // 修改标志位
    }
}

理论预期：

• 1 秒后把 running 改为 false，子线程应该跳出循环并打印 “stopped”。

实际在没有任何同步手段的前提下：

• 子线程可能永远循环下去；
• 因为它在工作内存中一直看到 old value（true），看不到主内存中新值。

JMM 通过：

• volatile、
• synchronized、
• final、
• 显式锁（Lock）、
• 原子类（AtomicXxx，基于 Unsafe / VarHandle）

来规定：在什么情况下，修改必须从工作内存刷新到主内存、其它线程又必须从主内存重新读取新的值。

7.3 原子性、可见性、有序性：并发问题的“三个维度”

#

7.3.1 原子性（Atomicity）

#

原子性：一个操作要么全部执行，要么全部不执行，中间状态对其它线程不可见。

• JVM 保证了 基本变量类型的单次读/写是原子 的（long/double 在早期有例外，新 JMM 已保证原子性）；
• 但像 ++、+= 等都是复合操作（读-改-写），不是原子。

示例：

public class Counter {
    private int count = 0;

    public void incr() {
        count++; // 非原子操作
    }
}

在多个线程同时调用 incr() 时：

• 期望是 +=1；
• 可能出现“丢失更新”，最后结果小于实际加的次数。

解决方案：

• synchronized（临界区互斥）；
• AtomicInteger 等原子类（CAS + 内存语义）。

7.3.2 可见性（Visibility）

#

可见性：一个线程对共享变量的修改，能够被其他线程“及时”看到。

常见丢失可见性的情况：

• 线程 A 修改了共享变量 x；
• 线程 B 因为一直读自己的工作内存中的旧值，迟迟看不到 A 的修改。

解决方案：

• 使用 volatile：写入 volatile 变量会强制刷新到主内存，读 volatile 变量时会从主内存重新获取；
• 使用 synchronized / Lock：
  • 释放锁前，JMM 会把工作内存中的变量刷新回主内存；
  • 获取锁后，会从主内存“重新加载”这些变量。

7.3.3 有序性（Ordering）与指令重排序

#

有序性：程序执行顺序是否与源码顺序一致。

编译器 & CPU 允许在不改变单线程语义的前提下，对指令进行 重排序（Reordering），例如：

int a = 1;      // 1
int b = 2;      // 2
int c = a + b;  // 3

在单线程下，编译器可以重排序为：

int b = 2;
int a = 1;
int c = a + b;

甚至某些场景也可以将写入/读取的时机向前/向后挪。

问题在于在多线程下，这种重排序可能改变程序行为：

• 一个线程中语句执行的实际顺序，可能与另一个线程看到的顺序不一致。

JMM 通过 happens-before 规则 来规定哪些操作之间不能重排序，从而保证程序在多线程下的“合理语义”。

7.4 happens-before 规则速记

#

JMM 没有直接规定“具体要怎么做缓存/重排序”，而是用一种更上层的方式表达：

如果 A happens-before B，那么在多线程环境下：

• A 的结果对 B 可见，
• 且 A 与 B 之间不能被重排序。

几个必须记住的规则（简化版）：

7.4.1 程序顺序规则（Program Order Rule）

#

在一个线程内，按照代码顺序，前面的操作 happens-before 后面的操作。

• 注意：这是在同一线程内；
• 编译器和 CPU 在保证“单线程语义”的前提下可以重排序，但 JMM 提供了一种“逻辑顺序”上的约束；
• 对你来说可以理解为：单线程语义你可以放心依赖。

7.4.2 监视器锁规则（Monitor Lock Rule）

#

对一个锁的 解锁（unlock） happens-before 后续对这个锁的加锁（lock）。

即：

• 线程 A 在 synchronized 块中退出（释放锁）之前对共享变量做的修改；
• 对于随后获取同一把锁的线程 B 来说，这些修改是可见的。

7.4.3 volatile 变量规则

#

对一个 volatile 变量的写（write） happens-before 后续对这个变量的读（read）。

• 写 volatile：会把当前线程对该变量的最新值刷新到主内存，并建立一定的顺序性；
• 读 volatile：会从主内存中重新获取最新值。

这是 volatile 提供“可见性 & 有序性”的基础。

7.4.4 线程启动与终止规则

#

• 线程启动（Thread Start）规则：

  • 对线程对象 Thread 调用 start() 之前，对共享变量的写入， 对新线程来说是可见的；

• 线程终止（Thread Join）规则：

  • 一个线程 A 执行 t.join() 成功返回后， 线程 t 内对共享变量的所有写入，对 A 来说都是可见的。

这就是说：

• start() 前对共享变量的初始化；
• join() 后对线程执行结果的读取；

在 happens-before 关系上是有保障的。

7.4.5 传递性（Transitivity）

#

如果 A happens-before B，B happens-before C，那么 A happens-before C。

这是组合推理的基础：

• 很多复杂的并发类（如 ConcurrentHashMap、CountDownLatch）内部， 通过精心设计，让你的业务代码在“最终可见性”上满足 happens-before。

7.4.6 总结记忆

#

可以用一句“伪口诀”帮助记忆（不严谨但好用）：

单线程内按顺序，锁与 volatile 建桥梁，start/join 连起线程，传递一下就全通。

7.5 volatile 的语义与使用边界

#

7.5.1 volatile 提供了什么？

#

volatile 关键字用于修饰变量（字段），JMM 给予它两种语义：

1. 可见性：
   • 一个线程写 volatile 变量后，其他线程能“立刻”看到；
   • 实现上通常会生成内存屏障（Memory Barrier），禁止缓存重排序。
2. 有序性（禁止特定重排序）：
   • 对 volatile 变量的写入，不会被重排序到其前面；
   • 对 volatile 变量的读取，不会被重排序到其后面；
   • 可以构建一种“轻量级的 happens-before 关系”。

但注意：

volatile 不保证复合操作原子性。

示例：

volatile int count = 0;

void incr() {
    count++; // 仍可能竞争，++ 不是原子
}

即使加了 volatile：

• 多线程并发执行 ++，仍会出现“丢失更新”。

7.5.2 典型正确用法：状态标志 / 配置刷新 / 单例双重检查

#

a. 状态标志

#

class StopFlag {
    private volatile boolean running = true;

    void worker() {
        while (running) {
            // do work
        }
    }

    void shutdown() {
        running = false;
    }
}

• 可见性：其他线程能看到 running 从 true → false 的变化；
• 有序性：确保对 running 之前的写入对观察者线程可见。

b. 配置信息 / 热更新

#

class ConfigHolder {
    private volatile Config current;

    public Config get() {
        return current;
    }

    public void update(Config newConfig) {
        current = newConfig;
    }
}

• 保证最新的 Config 实例能被所有线程及时看到；
• 借助 Config 的不变性（或安全发布），可以做到无锁读取。

c. 双重检查锁（DCL）单例

#

经典写法（JDK5 之后 + 正确使用 volatile 才是正确 DCL）：

class Singleton {
    private static volatile Singleton INSTANCE;

    private Singleton() {}

    public static Singleton getInstance() {
        if (INSTANCE == null) {              // 第一次检查（无锁）
            synchronized (Singleton.class) {
                if (INSTANCE == null) {      // 第二次检查（有锁）
                    INSTANCE = new Singleton();
                }
            }
        }
        return INSTANCE;
    }
}

volatile 的关键作用：

• 禁止指令重排序把“引用写入 INSTANCE”提前到构造器执行之前；
• 否则可能出现其它线程看到“非空但未完全初始化”的 INSTANCE。

7.5.3 不要用 volatile 做“所有并发控制”

#

容易踩坑的做法：

class WrongCounter {
    private volatile int count = 0;

    public void incr() {
        count++; // 仍有竞态
    }
}

volatile 不能代替锁，它只适合用在“状态标志 / 发布对象引用”这类场景，对于：

• 复合操作（++、累加、check-then-act）；
• 不可分割的状态变更（如从多个字段组合构成的一致性状态）；

仍然需要使用：

• synchronized / Lock；
• 或 AtomicXXX + 合理的 CAS 循环。

7.6 synchronized 与锁优化：偏向锁 / 轻量级锁 / 重量级锁

#

7.6.1 synchronized 的语义：互斥 + 可见性

#

synchronized 提供两大语义：

1. 互斥：同一时刻，只允许一个线程持有某个 monitor（锁），进入临界区；

2. 可见性 & 有序性：

   • 释放锁前，JMM 会把工作内存中对共享变量的修改刷新到主内存；
   • 获取锁后，会从主内存中重新加载这些变量；
   • 获取锁的操作 happens-before 随后对同一锁的释放。

字节码层面：

• 进入 synchronized 块 → monitorenter
• 退出 synchronized 块（正常或异常）→ monitorexit

JDK 实现中，锁对象的Mark Word 中会存储当前锁的状态以及持有线程等信息。

7.6.2 锁的几种状态：无锁 / 偏向锁 / 轻量级锁 / 重量级锁

#

HotSpot 中，为了减少加锁开销，引入了一套“锁状态升级/降级”机制（JDK15 之后偏向锁默认关闭，但理解概念仍有帮助）：

graph LR
    A[无锁] --> B[偏向锁]
    B --> C[轻量级锁]
    C --> D[重量级锁]

• 无锁（Unlocked）：
  • 对象刚创建时默认状态；
• 偏向锁（Biased Locking）：
  • 优化“长时间只被同一个线程使用的锁”；
  • 第一次加锁会在对象头记录“偏向线程 ID”；
  • 之后同一线程再次进入 synchronized，几乎无开销；
  • 一旦有其他线程参与竞争，再撤销偏向，升级成轻量级锁；
  • JDK15+ 默认禁用，可通过 -XX:+UseBiasedLocking 启用（未来版本可能移除）。
• 轻量级锁（Lightweight Locking）：
  • 利用 CAS + 自旋实现；
  • 当线程尝试获取锁时，使用 CAS 将对象头 Mark Word 替换为指向栈帧中 Lock Record 的指针；
  • 若 CAS 成功，即获取锁；失败则尝试短暂自旋，如果仍失败则膨胀为重量级锁；
  • 适用于“锁竞争短暂、冲突不激烈”的场景。
• 重量级锁（Heavyweight Locking）：
  • 线程进入阻塞状态，依赖 OS 的 Mutex/Monitor 实现；
  • 线程切换成本高；
  • 适用于“长时间持有锁、竞争激烈”的场景。

总体目标：

尽量让大部分 synchronized 在“无竞争/弱竞争”场景下成本很低， 需要真正阻塞的场景再升级。

7.6.3 锁消除（Lock Elimination）与锁粗化（Lock Coarsening）

#

除了锁的状态优化，JIT 还会做两种典型的锁相关优化：

a. 锁消除（Lock Elimination）

#

如果通过逃逸分析发现：

• 某个加锁对象不会被其它线程访问；
• 或者锁对象完全在当前方法内、不会逃逸；

那么加锁就没有意义，JIT 可以直接去掉 synchronized。

例如：

public String concat(String a, String b) {
    StringBuffer sb = new StringBuffer(); // 内部方法是 synchronized 的
    sb.append(a);
    sb.append(b);
    return sb.toString();
}

在单线程 & 不逃逸场景下，JIT 可能消除掉内部的锁开销。

b. 锁粗化（Lock Coarsening）

#

有时候源码里重复对同一个对象频繁加解锁，例如：

for (...) {
    synchronized (lock) {
        // 很小的一段代码
    }
}

在某些条件满足时（比如这些小块之间没有其他线程介入），JIT 会进行“锁粗化”：

• 将循环中多次短锁合并成一次大范围的锁包裹整个循环；
• 减少频繁加解锁的开销。

7.7 final 语义与“安全发布”

#

final 除了在语义上表示“不可修改”（对于字段，指不能被重新赋值），在 JMM 中还赋予了特殊的内存语义，特别是：

• final 字段在对象构造完成后，一旦发布出去，其他线程看到该对象时，一定能看到 final 字段的正确初始化值；
• 同时禁止编译器把对 final 字段的写重排序到构造函数之外。

这为不可变对象（Immutable Object） 提供了基础。

7.7.1 final 字段的初始化语义

#

示例：

class Point {
    final int x;
    final int y;

    Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
}

class Holder {
    static Point p;

    static void init() {
        p = new Point(1, 2);
    }
}

JMM 保证：

• 一旦其他线程读到 Holder.p 不为 null；
• 那么它看到的 p.x、p.y 一定是构造函数里写的 1 和 2，不会看到“0”或旧值。

前提是：

• 构造函数内没有“this 逃逸”行为；
• 即在构造函数执行完毕之前，不要把 this 发布出去。

7.7.2 this 逃逸的坑

#

错误示例：

class ThisEscape {
    public final int value;

    public ThisEscape(EventSource source) {
        value = 42;
        source.registerListener(e -> {
            // 在这里使用 ThisEscape.this
            doSomething(this);
        });
    }
}

问题：

• 在构造函数中，this 被注册到外部 source 的 listener 中；
• 其他线程可能在构造函数尚未完成时触发回调，访问到“未构造完的对象”；
• JMM 无法保证 final 字段在这种情况下的可见性。

规避方式：

• 使用工厂方法或静态工厂，在构造函数外完成注册；
• 或者让构造函数只做“纯初始化”，不发生 this 逃逸。

7.7.3 安全发布（Safe Publication）

#

安全发布：让一个对象在多线程间可见时，保证它处于“完全构造、状态可见”的一致性状态。

常见正确做法（部分）：

1. 通过 volatile 或 AtomicReference 写入共享引用；

2. 通过 synchronized 的释放锁操作把对象写入共享变量；

3. 通过线程启动：

   • 线程执行开始前对共享变量写入，对新线程可见；

4. 使用线程安全容器发布：

   • 把对象放入 ConcurrentHashMap、BlockingQueue 等。

配合 final 字段和不可变对象，可以构建非常安全、简单的无锁读模式。

7.8 常见并发 Bug 模式与 JMM 视角分析

#

最后，用 JMM 的视角看几个实际中常见的问题。

7.8.1 单例模式中的“半初始化对象”

#

错误写法（没有 volatile 的 DCL）：

class BadSingleton {
    private static BadSingleton instance;

    private BadSingleton() {}

    public static BadSingleton getInstance() {
        if (instance == null) {             // 1
            synchronized (BadSingleton.class) {
                if (instance == null) {     // 2
                    instance = new BadSingleton(); // 3
                }
            }
        }
        return instance;
    }
}