JVM 学习

Thu, 19 Feb 2026 00:00:00 +0000

类加载与字节码

- 类加载与字节码
- 类加载机制
- 类的生命周期
- 流程
- Loading（加载）
- 把 .class 的字节流变成 JVM 内部的 Class 对象
- 验证
- 确保字节码符合 JVM 规范、类型安全、不会破坏虚拟机
- 准备
- 为类变量 static 字段分配内存并设置默认零值
- 解析
- 把常量池中的符号引用（字符串/描述符）转换成直接引用（指针/句柄）
- 初始化
- 执行类初始化方法 <clinit>
- 准备阶段：有 static 变量的空间+默认值，初始化阶段执行你的 static 赋值逻辑
- 准备阶段 vs 初始化阶段
- 默认值发生在准备阶段
- ![](https://an-img.oss-cn-hangzhou.aliyuncs.com/2026/02/19/20260219205053393.png,301,57)
- 显式赋值发生在初始化阶段
- ![](https://an-img.oss-cn-hangzhou.aliyuncs.com/2026/02/19/20260219205149229.png,283,54)
- 常量折叠
- <clinit> 类初始化方法
- <clinit> 是编译器合成的类初始化方法
- 来自于所有 static 字段的显式赋值语句和所有 static{} 块
- 按源码出现顺序合并执行
- JVM 保证同一个类的 <clinit> 在多线程下只会被一个线程执行，其他线程阻塞等待
- 初始化触发时机
- 初始化只在主动使用时触发
- 常用触发初始化场景
- new A()
- 读取写入 A.staticField
- 调用 A.staticMethod()
- Class.forName("A")
- 初始化子类前，先初始化父类
- JVM 启动时执行 main 类
- Class.forName 和 ClassLoader.loadClass
- Class.forName("A")：默认加载+连接+初始化
- ClassLoader.loadClass("A")，默认只做加载和必要时连接，不初始化
- 类加载体系与双亲委派
- 三类内置类加载器
- Bootstrap：加载核心库(rt/基础模块)，通常由 JVM 实现，不是 Java 对象
- Platform(JDK9+)/Ext(JDK8)：平台扩展库
- App：应用 classpath 下的类（写的业务代码）
- 双亲委派模型
- 流程
- loadClass(name) 先检查本加载器是否已经加载
- 没加载则委派给父加载器
- 父加载器加载不到，再由当前加载器尝试 findClass 加载
- 最终返回 Class<?>
- 动机
- 安全：防止核心类被伪造替换
- 一致性：保证同名类在 JVM 中尽量只加载一份，避免类型混乱
- 破坏双亲委派
- 破坏方式
- 自定义 ClassLoader，重写 loadClass，不再先委派
- 使用线程上下文类加载器绕过父类限制
- 典型场景
- SPI/ServierLoader：核心库需要加载应用层实现（反向委派）
- JDBC Driver：早期通过 Class.forName 强制注册类驱动
- 应用容器（Tomcat）：每个 WebApp 一个 ClassLoader，实现隔离与热部署
- 破坏带来的风险
- 类重复加载
- 内存泄露：容器热部署时，类加载器无法回收->元空间泄露
- 类相等判断
- JVM 中，一个类的唯一性由（类的全限定名）+（加载它的 ClassLoader）共同决定

JVM 内存结构与对象模型

- JVM 内存结构与对象模型
- 运行时数据区
- 整体结构
- 线程私有
- 程序计数器
- Java 虚拟机栈
- 本地方法栈
- 线程共享
- 堆
- 方法区（Hotspot 对应元空间 + 运行时常量池）
- 程序计数器
- 存放线程正在执行的字节码指令地址
- 线程私有：线程切换后能恢复执行位置
- 几乎不会 OOM
- 如果执行 Native 方法，PC 值不一定有意义
- Java 虚拟机栈
- 栈帧结构：一次方法调用对应一个栈帧
- 局部变量表：基本类型值、对象引用、returnAddress
- 操作数栈：字节码执行的临时计算区
- 动态链接：指向运行时常量池的方法/字段引用信息
- 方法返回地址
- 异常表
- 栈中存的对象
- 栈里一般不存对象本体，存的是对象引用
- 对象本体在堆上
- 栈相关错误
- StackOverflowError：递归太深/栈帧太大
- OutOfMemoryError：unable to create new native thread：系统资源耗尽
- 常见参数
- -Xss：每个线程的栈大小（越大单线程可递归更深，但是可创建线程数更少）
- 本地方法栈
- 执行 JNI/Native 方法用
- 堆
- 存放几乎所有对象实例 + 数组
- 常见结构
- 新生代：Eden + Survivor(S0/S1)
- 老年代
- G1 下是 Region 化，不强行分固定代区
- 常用参数
- -Xms 初始堆
- -Xmx 最大堆
- -XX:NewRatio/-XX:SurvivorRatio （传统分代）
- -XX:+UseG1GC 选择收集器
- 堆相关 OOM
- OutOfMemoryError: Java heap space 最常见
- OutOfMemoryError: GC overhead limit exceed
- 方法区/元空间
- 存放类元数据：类结构信息、字段/方法信息、运行时常量池、方法字节码元信息等
- JDK 8 以后 HotSpot 用 Metaspace （本地内存）替代永久代 PermGen
- 常见参数
- -XX:MaxMetaspaceSize 限制元空间上限
- -XX:MetaspaceSize 触发元空间 GC 的阈值
- 典型 OOM
- 动态生成大量类 CGLIB、ByteBuddy、JSP 编译、反射代理
- 热部署/自定义类加载器泄露导致旧类加载器无法回收
- 对象创建与内存分配
- 对象创建的典型步骤
- 类检查：该类是否加载、解析、初始化
- 分配内存：在堆上为对象划分出一块连续空间
- 零值初始化：对象实例字段设置为默认值
- 设置对象头：写入 Mark Word，类指针等元信息
- 执行 <init>：构造方法把字段设置为期望的初始值
- 内存分配方式：指针碰撞 vs 空闲列表
- 指针碰撞
- 堆内存规整，已用区和闲置区是连续的，只要把指针往后移
- 优点：速度快
- 空闲列表
- 堆存在碎片，需要维护空闲列表，从中找合适块
- 优点：有碎片（标记-清除类收集器）
- 是否能用指针碰撞，取决于 GC 是否会整理/复制使空间规整；不规整举要用空闲列表
- 并发分配：TLAB(Thread Local Allocation Buffer)
- TLAB：为每个线程在 Eden 预留一小块私有分配区域，线程在 TLAB 内分配对象时基本无需加锁。
- 原因
- 多线程并发 new 对象频繁，每次都竞争全局堆指针，会有锁/原子操作开销
- TLAB 把大多数分配变成线程本地，提升吞吐
- TLAB 不够时会申请新的 TLAB 或者退到全局分配路径
- 对象内存布局与引用类型
- 对象内存布局
- 对象头
- MarkWord：哈希码、GC 分代年龄、锁信息
- Klass Pointer：指向类元数据（对象属于哪个类）
- 实例数据：定义的字段
- 对齐填充：按 8 字节对齐
- 引用类型
- 强引用
- 默认引用：只要强引用存在，对象不回收
- OOM 大户：强引用过长导致对象一直存活
- 软引用
- 内存不足时才回收
- 弱引用
- 下一次 GC 旧可能回收（只要没有强引用）
- 典型：WeakHashMap、ThreadLocal 的 key
- 虚引用
- 不能通过它获取对象
- 用于对象回收后的通知/资源清理配合 ReferenceQueue
- ThreadLocal 为什么会内存泄露
- 关键结构
- 每个 Thread 内部有一个 ThreadLocalMap
- ThreadLocalMap 的 Key 是 ThreadLocal 的弱引用
- value 是强引用
- 泄露发生条件
- ThreadLocal 实例没有强引用
- 线程还活着
- ThreadLocalMap 里面出现 key=null，value=大对象的 entry
- value 可能长期挂挂着
- 正确姿势
- 用完必须 remove()
- 线程池环境更好要 remove

GC 体系

- GC 体系
- GC 基础原理
- GC 要解决的问题
- Java 对象生命周期动态、数量大、手动 free 易错
- GC 的核心目标：在可接受停顿和吞吐下，回收不可达对象占用的内存
- 判定垃圾
- 引用计数
- 优点：实现直接
- 缺点：循环引用难处理
- Hotspot 主流不靠它做 GC 判定
- 可达性分析
- 从 GC Roots 出发做图遍历，遍历不到的对象是垃圾
- GC Roots 常见来源
- 虚拟机栈（栈帧局部变量表）引用的对象
- 方法区/元空间中静态字段引用的对象
- 方法区中常量引用的对象
- JNI 引用的对象
- 活跃线程对象，同步锁持有的对象
- 三大经典回收算法
- 标记-清除（Mark-Sweep）
- 过程：标记可达 -> 清掉不可达
- 优点：简单
- 缺点：内存碎片
- 标记-整理（Mark-Compact）
- 过程：标记可达->把存活对象向一侧移动->整理出连续空闲区
- 优点：无碎片
- 缺点：移动对象成本高，停顿更长
- 复制
- 过程：把存活对象复制到另一块区域，清空原区域
- 优点：分配快、碎片少
- 缺点：需要额外空间
- 分代为什么有效
- 核心假设：大多数对象朝生夕死，少数对象存活很久
- 堆分为
- 新生代(Young)：频繁回收，复制算法为主
- 老年代(Old)：存活对象多，回收频率低，整理/并发标记策略为主
- STW 从哪里来
- STW 的根源
- 根枚举/安全点：要一致地拿到 GC Roots，需要让线程在安全点停下
- 对象移动/引用更新：复制/整理需要更新指针，必须在一致视图下完成
- 并发标记时代的写屏障/记忆集
- 当 GC 和应用线程并发时，会出现对象引用关系变化的一致性问题。需要
- 写屏障：在写入引用字段时执行一小段额外逻辑
- Card Table/Remembered Set (RSet)：记录跨代引用，避免全堆扫描
- 为避免扫描整个老年代/全堆，新生代回收时需要知道老年代指向新生代的引用；并发标记需要处理引用更新，因此用写屏障把变更记录到卡表/RSet，保证正确性与效率
- 收集器体系
- G1 (Garbage First)
- 设计目标
- 在吞吐与低停顿之间折中，提供可预测停顿
- 关键机制
- Region 化：堆切成很多等大小 Region
- 按收益优先回收：优先回收“垃圾最多、收益最高“的 Region
- RSet：每个 Region 维护“谁引用我“的集合，避免全堆扫描
- 并发标记：找出老年代可回收对象，随后 Mixed GC 回收部分 old Regions
- G1 的堆结构
- Region 是物理切片；在不同时间扮演不同角色
- Eden Region
- Survivor Region
- Old Region
- Humongous Region (大对象)
- G1 不是固定的新生代/老年代，而是逻辑分代
- G1 的回收类型与流程
- Young GC（仅回收 Young）
- 触发常见原因：Eden 满
- 步骤
- STW 暂停
- 处理根与 RSet，找出可达对象
- 复制存活对象：Eden/Survivor -> 新的 Survivor/Old （晋升）
- 更新引用，释放旧 Eden/Survivor Region
- 恢复执行
- Concurrent Mark （并发标记周期）
- 找出 Old 区的存活情况，为 Mixed GC 提供候选 Old Regions
- 阶段
- Initial Mark：STW，很短，标记 GC Roots 直接可达（通常搭车在一次 Young GC 上）
- Concurrent Mark（并发标记）：与应用并发，从根开始遍历可达视图
- Remark（再标记）：STW，修正并发期间引用变化
- Cleanup（清理/回收候选统计）：统计每个 Region 的存活率，为 Mixed 选择回收集合
- Mixed GC （回收 Young + 部分 Old）
- 触发条件：完成并发标记后，G1 会在若干 GC 中选择一批 Old Regions 与 Young 一起回收
- 特点
- Mixed 仍然是 STW（复制/整理 + 引用更新）
- 部分 Old 由 G1 按收益挑选
- G1 的 Old 回收不是一次性全回收，而是多次 Mixed 逐步回收
- Full GC（G1 不想发生，但会发生）
- Full GC 是兜底
- 并发标记跟不上分配速度
- 晋升失败/分配失败
- to-space exhausted（复制目标空间不足）
- Humongous 压力导致碎片/可用 Region 不够
- Full GC 特点
- STW 时间长
- 会做全堆标记整理
- Humongous（大对象）
- 在 G1 中，大对象通常定义为：大小 > Region 大小的 50%
- 表现
- 大对象会直接分配到 Humongous Regions
- Humongous 回收不如普通对象灵活，容易造成
- Old 快速膨胀
- Mixed 效果变差
- 频繁并发标记或 Full GC 风险上升
- RSet
- 作用：支持只回收一部分 Region 仍然能正确找到 Roots
- 代价：维护 RSet 需要写屏障与额外内存/CPU
- G1 调优
- 4 个参数
- -XX:+UseG1GC
- -XX:MaxGCPauseMillis=<N>: 停顿目标
- -Xms/-Xmx: 堆大小
- -XX:InitiatingHeapOccupancyPercent=<N>：老年代占用多少开始并发标记
- CMS
- CMS 是什么
- 是 HotSpot 里老年代并发收集器
- 核心目标是降低老年代回收的停顿时间-让标记尽可能与应用线程并发执行
- Young 通常配 ParNew
- CMS 总体结构
- 经典周期
- Initial Mark（初始标记）-STW
- Concurrent Mark（并发标记）- 并发
- Remark（重新标记）-STW
- Concurrent Sweep （并发清除）
- Initial Mark（初始标记，STW）
- 从 GC Roots 触发，标记直接可达的对象
- STW：一致性地枚举根，必须在 safepoint 停住线程
- Concurrent Mark（并发标记）
- 从初始标记得到的对象开始，遍历对象图，标记所有可达对象
- 与应用线程并发执行
- 问题：应用线程在改引用->可能影响标记正确性
- Remark（重新标记，STW）
- 修正并发标记期间因为引用变化导致的“漏标/标记不完整“
- 处理并发期间记录到变更（dirty card 等），把可达闭包补齐）
- STW 原因：并发期间引用一直在变，如果不暂停，就无法在一个确定点收束标记结果
- Concurrent Sweep（并发清除）
- 回收未标记对象的空间，把它们加入空闲链表
- 与应用线程并发执行
- 设计缺陷
- 内存碎片
- CMS 是 Mark-Sweep，不做压缩整理
- 老年代空闲空间可能变成很多不连续小块
- 后果：触发 Full GC（Serial Old/Parallel Old）来做一次标记-整理压缩
- 浮动垃圾
- CMS 标记是并发进行的
- 并发标记开始后，应用线程还在不断创建新对象，产生新垃圾
- 这些对象可能在本轮标记后才产生，不会被本轮回收
- CMS 回收触发的典型机制
- 不会等老年代完全满才开始
- 老年代使用率达到阈值开始一次 CMS 周期 -XX:CMSInitiatingOccupancyFraction 配合 -XX:+UseCMSInitiatingOccupancyOnly
- 如果阈值太高，容易并发失败；阈值太低，吞吐下降
- 常用参数
- -XX:+UseConcMarkSweepGC：启用 CMS
- -XX:+UseParNewGC：新生代用 ParNew
- -XX:+CMSParallelRemarkEnabled: Remark 并行化
- ParNew 回收
- 作用范围：新生代（Eden+S0+S1）
- 算法：标记复制
- 并发：STW，但是 GC 线程并行执行
- 核心流程
- STW（停顿）
- 所有应用线程到达 safepoint 暂停，保证 Roots 枚举一致
- 根扫描（Roots）
- 扫各线程栈、静态引用等 GC Roots
- 额外要处理老年代 -> 新生代的引用
- YoungGC 不能扫描整个老年代，需要靠卡表 Card Table 记录老年代那些卡页变脏，只扫描这些变脏区域找到 Old->Young 的引用作为额外 Roots
- 复制存活对象
- Eden 中存活对象复制到 Survivor（或者晋升到 Old）
- Survivor（From）中存活对象复制到另一个 Survivor，年龄 + 1
- 复制过程中会设置 forwarding pointer，避免重复复制并更新引用
- 交换 Survivor
- Eden 和旧 From Survior 清空
- To Survivor 变成新的 From
- 恢复引用线程
- 对象如何从 Young 晋升到 Old
- 年龄阈值：对象每熬过一次 YoungGC 年龄 +1，达到阈值 -XX:MaxTenuringThreshold 晋升
- Survivor 放不下：Survivor 容量不足，直接晋升到 old
- 大对象直接进老年代：如果开启/配置了相关策略，大对象可能绕过 Young
- ZGC
- 目标：极低停顿
- 核心：并发标记+并发重定位，依赖读写屏障等机制
- 适合：大堆、强延迟敏感

JIT 与性能

线上排障与工具链

- 线上排障与工具链
- 保存现场
- 采集 4 件套
- GC 日志
- 线程栈 jstack
- Heap Dump jcmd GC.heap.dump 或 jmap -dump
- 关键进程信息：jcmd VM.flags、VM.command_line
- 判断 CPU、内存、锁、I/O
- CPU 高：先看线程在干什么
- RT 抖动：优先看 STW + 锁阻塞 + IO 等待
- 内存涨：看堆/元空间/直接内存 + 是否泄露
- Full GC：看触发原因、晋升、存活率
- OOM：先 dump，再分析引用链
- jps：快速找到 Java 进程
- 列出 Java 进程 PID，主类/jar 名称
- jps -l：显示主类全名或 jar
- 定位 PID 的第一步，用于后续 jcmd/jstack/jstat
- jcmd：万能入口
- jcmd 是 Hotspot 的控制台
- jcmd <pid> VM.version：JDK/Hotspot 版本
- jcmd <pid> VM.command_line: 启动参数
- jcmd <pid> GC.heap_info: 堆概要
- jcmd <pid> GC.class_histogram: 类直方图
- jcmd <pid> GC.heap_dump xx.hprof 生成 heap dump
- jcmd <pid> Thread.print: 线程栈
- jcmd <pid> PerfCounter.print: 性能计数器
- jstack: 线程栈、死锁、阻塞、热点定位
- 用途
- CPU 高：找 RUNNABLE 热点线程在跑啥
- RT 抖动：看 BLOCKED/WAITING/TIMED_WAITING
- 死锁：Found one Java-level deadlock 直接给出环
- 间隔 5-10s 连续采样 3 次，看热点栈是否稳定
- jstat: 快速查看 GC/类加载/编译统计
- 用户
- 判断 GC 是否频繁、老年代是否持续增长、晋升是否异常
- 看 metaspace/class load 是否异常增长
- 常用命令
- jstat -gcutil <pid> 1s 20: 每秒输出 20 次 GC 利用率
- jstat -gc <pid> 1s 20: 更详细的各区大小/容量
- jstat -class <pid> 1s 20: 类加载数量
- jstat -compiler <pid> 1s 20: JIT 编译情况
- jmap vs jcmd heap_dump: dump 与直方图
- 直方图
- 快速看到哪个类对象最多/占用最大
- 常用于 OOM 前后或内存上涨时的第一眼判断
- heap dump
- 确定谁在引用链上把对象留住
- Arthas: 线上动态诊断
- dashboard: CPU/内存/线程/GC 全览
- thread -n 5: 找 CPU 占用最高的线程
- thread <id>: 看指定线程栈
- jvm: JVM 信息、参数、内存、GC、类加载器
- heapdump xx.hprof: 导出 heap dump
- trace com.xx.Service method: 方法调用链耗时
- watch com.xx.Service method '{params,returnObj,throwExp}' -x 2: 观察入参/返回/异常
- tt：录制与回放
- 高频场景
- CPU 100%
- 目标：找到哪个线程在烧 CPU，以及烧 CPU 的代码路径
- 标准流程：
- OS 层确认
- top/htop 看进程 CPU
- 定位 java 线程
- Arthas: thread -n 5
- top -H -p <pid> 找到线程 TID
- 将 TID 转 16 进制
- printf "%x\n" 12345
- jstack <pid> 或 jcmd Thread.print 中搜索 16 进制 nid
- 找到对应线程栈
- 判断栈顶
- 如果是业务循环/正则灾难/大 JSON 解析/排序/加密->代码问题
- 如果是 GC 线程占 CPU -> 看 GC 是否频繁
- 需要更准时，上 profiler
- JFR/async-profiler 火焰图确认热点
- RT 抖动/毛刺
- 目标：分辨是 STW、锁阻塞、还是 IO/下游慢
- 标准流程
- 先看是否有 STW
- GC 日志看 pause
- jstat -gcutil 看 GC 是否在尖峰时频繁
- 非 GC，查看线程状态分布
- jstack 多次采样
- BLOCKED 多：锁竞争
- WAITING/TIME_WAITING 多：可能在等 IO/队列/park
- 下游排查
- DB 慢查询、线程池队列积压，连接池耗尽
- 频繁 Full GC
- 目标：解释为什么 Full 以及回收效果如何
- 标准流程：
- 看 GC 日志：Full GC 的触发原因
- jstat -gcutil 看
- Old 是否增长
- FGC 是否增长
- YGC 后 Old 增长是否很快
- 先做直方图
- jcmd GC.class_histogram 看大对象/大集合
- 必要时 heap dump:
- MAT 看 Dominator Tree + Path to Roots

JVM on 安橙的博客

JVM 学习

类加载与字节码

JVM 内存结构与对象模型

GC 体系

JIT 与性能

线上排障与工具链