JVM、GC 与诊断工具

运行时与版本01

JDK 21 生成的 class 文件主版本号是 65（Java 8 是 52，每六个月 +1）。跨版本运行时，低版本 JVM 无法加载高版本 class。

Runtime.Version version = Runtime.version();
System.out.println(version);            // 21.0.12+8-LTS
System.out.println(version.feature());  // 21

System.out.println(System.getProperty("java.version"));
System.out.println(System.getProperty("java.vendor"));
System.out.println(System.getProperty("java.vm.name"));
System.out.println(System.getProperty("os.arch"));

# 查看 class 文件版本
javap -verbose MyClass.class | grep "major version"

# JDK 21 -> major version: 65
# JVM 参数与默认值
java -XX:+PrintFlagsFinal -version | grep -E "UseG1GC|UseZGC|MaxHeapSize"

内存结构：堆、元空间、直接内存02

JDK 21 的堆仍然分代（年轻代 / 老年代），G1 按 Region 管理。对象优先在 Eden 分配，经历多次 GC 后晋升老年代；大对象可能直接进入 Humongous Region。

# 查看堆与 GC 概况
jcmd <pid> GC.heap_info
jcmd <pid> GC.class_histogram | head -30
jstat -gcutil <pid> 1000 10

# OOM 时自动 dump
java -Xmx512m -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/tmp/heap.hprof -jar app.jar

GC 选型：G1 默认，ZGC 低延迟03

JDK 21 默认 G1。ZGC 在 15 转正，21 引入分代 ZGC（JEP 439），需要在 21 上显式开启分代模式；到 23 分代成为默认，24 移除非分代模式。

# G1（JDK 21 默认）
java -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar app.jar

# ZGC 分代模式（JDK 21 需显式开启）
java -XX:+UseZGC -XX:+ZGenerational -Xmx16g -jar app.jar

# 查看 GC 日志
java -Xlog:gc*:file=gc.log:time,uptime,level,tags -jar app.jar

• 堆越大，ZGC 的相对优势越明显；小堆用 G1 通常足够。
• ZGC 的吞吐与内存开销通常高于 G1，不要只看停顿。
• MaxGCPauseMillis 是目标不是保证；G1 会通过调整年轻代大小逼近目标。
• 不要同时开启多个 GC 参数；-XX:+UseZGC 与 -XX:+UseG1GC 互斥。
• 升级到 JDK 23+ 后，ZGC 分代是默认，不需要再写 ZGenerational。

jcmd / JFR / 线程转储04

JDK 21 的诊断入口首选 jcmd：它把 JFR、线程、GC、VM 信息整合到一个工具里，不需要额外安装。JFR 是低开销的持续记录器，适合生产环境。

# 发现 Java 进程
jps -l

# 采集 60 秒 JFR（低开销）
jcmd <pid> JFR.start duration=60s filename=/tmp/app.jfr

# 线程转储
jcmd <pid> Thread.print > /tmp/threads.txt

# 查看死锁
jcmd <pid> Thread.print -l | grep -A 20 "Found one Java-level deadlock"

JFR 的默认配置开销很低，适合长期开启。线上排障时先看 jdk.GCPhasePause、jdk.ExecutionSample、jdk.VirtualThreadPinned、jdk.JavaMonitorEnter 等事件。

OOM 类型与第一动作05

# 生产环境建议常开
java -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/data/dumps \
     -Xlog:gc*:file=/data/logs/gc.log:time,uptime:filecount=5,filesize=50M \
     -jar app.jar

• 先保现场：堆 dump、GC 日志、线程转储，再重启。
• 不要在没有 dump 的情况下反复重启；问题会重复出现。
• Metaspace OOM 常见于热部署、动态代理、脚本引擎反复生成类。
• Direct buffer memory 不占堆，堆 dump 看不出来；需要 NIO 泄漏检测或 JFR。

JIT、启动与性能06

HotSpot 使用分层编译：C1 快速编译，C2 深度优化。方法需要「热」到阈值才会被 C2 编译，因此短命进程、微基准测试很容易测到解释执行或 C1 代码。

• 性能测试必须预热，或使用 JMH 这类框架；不要用 System.currentTimeMillis 循环测单次调用。
• 逃逸分析可以把未逃逸对象标量替换，减少分配；但这依赖 JIT，不要据此写「聪明」代码。
• -Xint 只用于调试，不要用于生产。
• 代码缓存满会导致退化为解释执行，日志里会出现 CodeCache 相关警告。
• 启动优化可考虑 AppCDS（JDK 10+）、AOT 缓存（JDK 24+ 逐步成熟）。

# 查看 JIT 与代码缓存
jcmd <pid> Compiler.codecache
jcmd <pid> Compiler.queue

# 统一日志查看类加载 / GC
java -Xlog:class+load=info,gc*=info -jar app.jar

虚拟线程的运行时观测07

虚拟线程不是 OS 线程，传统 jstack 只能看到载体线程。JDK 21 提供了 JSON 线程转储与 JFR 事件，专门用于观察虚拟线程。

# JSON 转储，包含虚拟线程
jcmd <pid> Thread.dump_to_file -format=json /tmp/threads.json

# JDK 21 检测 pinning
java -Djdk.tracePinnedThreads=full -jar app.jar

# JFR 事件
jcmd <pid> JFR.start duration=60s filename=/tmp/vt.jfr
jfr print --events jdk.VirtualThreadStart,jdk.VirtualThreadEnd,jdk.VirtualThreadPinned /tmp/vt.jfr

• jdk.VirtualThreadPinned 默认记录超过 20ms 的钉住事件。
• 虚拟线程数量不是问题本身；要关注载体线程利用率与下游瓶颈。
• JDK 24+ 已消除 synchronized 导致的 pinning，升级后相关告警会消失。
• JFR 的 jdk.ThreadStart 与 jdk.VirtualThreadStart 是不同事件，不要混淆。

版本边界BOUNDARY

这张表比 API 本身更值得记。写代码时先确认你的运行时版本。

费曼自检SELF CHECK

先合上页面，用自己的话回答，再展开对照。能讲出因果和反例，才算真正掌握。