JVM 常用参数速查手册

所有参数基于 HotSpot JVM。参数后标注版本状态：[JDK8]仅 JDK 8 可用，[JDK17+]需要 JDK 17 及以上，[已移除]表示在后续版本中被删除。

LTS 版本关键差异速查

Java 的 LTS（长期支持）版本是8、11、17、21、25。跨版本升级时，JVM 参数有实质性变化的集中在以下几个点：

参数行为差异一览

已废弃 / 已移除参数对照

升级 JDK 时，启动脚本里的这些参数必须改掉，否则 JVM 会报错或静默忽略。

从 JDK 8 升级到 JDK 17 的参数改造清单

这是最常见的升级路径，需要改的东西最多：

# ═══ 必须改 ═══ # 1. GC 收集器：CMS 已移除，换 G1 或 ZGC - -XX:+UseConcMarkSweepGC -XX:+UseParNewGC + -XX:+UseG1GC # 2. GC 日志：旧格式全部换掉 - -XX:+PrintGCDetails - -XX:+PrintGCDateStamps - -Xloggc:/var/log/app/gc.log + -Xlog:gc*,gc+age=trace:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=5,filesize=10m # 3. 永久代参数：删掉 - -XX:PermSize=256m - -XX:MaxPermSize=512m + -XX:MetaspaceSize=256m + -XX:MaxMetaspaceSize=512m # 4. 偏向锁：JDK 17 已默认关闭，显式开启反而有警告 - -XX:+UseBiasedLocking # ↑ 直接删除此行，不需要替代 # 5. 强封装：如果用反射访问 JDK 内部类，必须加 --add-opens + --add-opens java.base/java.lang=ALL-UNNAMED + --add-opens java.base/java.util=ALL-UNNAMED # ═══ 建议改 ═══ # 6. Flight Recorder 现在免费了，可以加上 + -XX:StartFlightRecording=duration=60s,filename=/tmp/jfr.jfr # 7. G1 成为默认 GC，可以不显式指定（但建议还是写上，明确意图）

从 JDK 17 升级到 JDK 21 的参数改造

相对平滑，主要变化：

# ═══ 建议改 ═══ # 1. 分代 ZGC 大幅提升，低延迟场景强烈推荐 - -XX:+UseZGC + -XX:+UseZGC -XX:+ZGenerational # 2. 虚拟线程正式发布（不需要 JVM 参数，但需要 JDK 21） # 代码层面：使用 Executors.newVirtualThreadPerTaskExecutor() # 3. 字符串去重默认开启（减少内存，一般不用管） # ═══ 注意 ═══ # 4. 偏向锁参数已被移除，如果还在用会报错 - -XX:+UseBiasedLocking # ↑ 必须删除（JDK 18+ 默认关闭，JDK 19+ 参数已移除） # 5. G1 默认 Region 大小算法优化，通常不需要手动设了 # 如果之前手动设了 G1HeapRegionSize，可以试试去掉让 JVM 自己选

容器环境专属参数（Docker / K8s）

这是最容易踩坑的地方。JVM 在容器里看到的可能不是容器的资源限制，而是宿主机的。

容器感知（Container Awareness）

为什么这很重要 — 不设置的后果

场景：Docker 容器限制 4GB 内存，宿主机 64GB JDK 8u190（无容器感知）： JVM 看到 64GB → -Xmx 默认 16GB → 容器被 OOM Killed 💀 JDK 8u191+（有容器感知）： JVM 看到 4GB → -Xmx 默认 1GB（25%）→ 正常运行但堆太小 正确配置： -XX:+UseContainerSupport -XX:MaxRAMPercentage=75 → JVM 看到 4GB → -Xmx 约 3GB → 合理 ✅

容器里的 CPU 核数

场景：容器限制 2 核，宿主机 32 核 JDK 默认行为： Runtime.getRuntime().availableProcessors() → 32（宿主机核数） ParallelGCThreads → 32 → 创建 32 个 GC 线程 → 浪费内存 + 上下文切换 解决方案： 1. JDK 10+：自动读取 cgroup CPU 限制 ✅ 2. JDK 8：手动指定 -XX:ParallelGCThreads=2 -XX:ConcGCThreads=1 3. 或者设置 -XX:ActiveProcessorCount=2（JDK 8u191+）

容器环境推荐配置

# Docker 容器通用模板（JDK 17+）java\-XX:+UseContainerSupport\# 启用容器感知-XX:MaxRAMPercentage=75\# 堆占容器内存的 75%-XX:InitialRAMPercentage=75\# 初始堆也一样（避免扩容）-XX:+UseG1GC\-XX:MaxGCPauseMillis=100\-XX:+HeapDumpOnOutOfMemoryError\-XX:HeapDumpPath=/tmp/heapdump.hprof\-Xlog:gc*:file=/var/log/app/gc.log:time,uptime:filecount=3,filesize=10m\-jarmyapp.jar

注意：MaxRAMPercentage=75意味着堆占 75%，剩下 25% 给堆外内存。容器内存越紧张，这个值越要精确计算。

一、堆内存参数

要点：

• -Xms和-Xmx设成一样是最重要的一条规则 — 消除扩容带来的停顿
• -Xmn和-XX:NewRatio二选一，不要同时设

二、分代与晋升参数

Survivor 放不下的判断：

# 观察 GC 日志中是否有： "Desired survivor size XXX bytes, new threshold N" # 如果 threshold 被自动调低了（如降到 3），说明 Survivor 太小 # 解决：减小 SurvivorRatio（如从 8 改为 6），增大 Survivor 空间

三、元空间参数

什么时候该关注：

• Spring Boot + 大量 AOP 代理 → 动态生成很多类
• 热部署 / 频繁重新加载 → 类卸载不及时
• OOM: Metaspace → 先排查是否有类加载泄漏，再调大上限

JDK ≤ 7 用户注意：永久代参数-XX:PermSize/-XX:MaxPermSize从 JDK 8 起已被忽略（启动时会打印警告）。
升级到 JDK 8+ 后应替换为上方表格中的-XX:MetaspaceSize/-XX:MaxMetaspaceSize。
完整的新旧参数对照见 已废弃 / 已移除参数对照。

四、GC 收集器选择参数

选择决策：

JDK 版本？ ├── JDK ≤ 8 → 延迟敏感？ │ ├── 是 → -XX:+UseConcMarkSweepGC（CMS） │ └── 否 → -XX:+UseParallelGC（默认） ├── JDK 9~14 → -XX:+UseG1GC（默认，通用最优） └── JDK 15+ → 延迟要求？ ├── 极低（< 1ms）→ -XX:+UseZGC ├── 中等（< 200ms）→ -XX:+UseG1GC（默认） └── 不在乎 → -XX:+UseParallelGC

五、GC 行为调优参数

通用参数

G1 专用参数

Parallel GC 专用参数

ZGC 专用参数

六、GC 日志参数

JDK 9+ 统一日志格式（推荐）

# 基础配置：GC 日志输出到文件，滚动保留 5 个文件，每个 10MB-Xlog:gc*:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=5,filesize=10m# 详细配置：包含 GC、堆、元空间信息-Xlog:gc*,gc+heap=debug:file=/var/log/app/gc.log:time,uptime,level,tags:filecount=5,filesize=20m# 打印安全点信息（排查 STW 延迟）-Xlog:gc+safepoint=info:file=/var/log/app/gc.log

JDK 8 格式（旧）

# 基础配置-XX:+PrintGCDetails-XX:+PrintGCDateStamps-Xloggc:/var/log/app/gc.log# 详细配置-XX:+PrintGCDetails-XX:+PrintGCDateStamps-XX:+PrintTenuringDistribution# 打印对象晋升年龄分布-XX:+PrintHeapAtGC# GC 前后堆信息-XX:+PrintReferenceGC# 引用处理耗时-Xloggc:/var/log/app/gc.log# 大堆时打印堆区域变化（G1）-XX:+PrintAdaptiveSizePolicy

日志中看什么

# JDK 9+ 格式示例 [2024-01-15T10:30:05.123+0800][12.345s][info][gc] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 209M->45M(2048M) 8.234ms ↑ ↑ ↑ ↑ ↑ 第几次GC 类型 触发原因 前→后 耗时 关键指标： - 频率：Young GC 几分钟一次正常，Full GC 几小时一次以上就有问题 - 耗时：Young GC < 50ms 正常，Full GC < 200ms 可接受 - 回收后使用率：GC 后仍 > 80% → 堆不够或有泄漏

七、引用类型与 GC 行为

Java 有四种引用类型，GC 对它们的回收策略完全不同。理解这个对写缓存、避免 ThreadLocal 泄漏至关重要。

GC 回收优先级：

强引用 → 永不回收（OOM 也不回收） ↓ 失去强引用后 软引用 → 内存不足时回收（GC 会尽量保留） ↓ 失去软引用后 弱引用 → 下次 GC 立刻回收 ↓ 失去弱引用后 虚引用 → 入队通知，对象已死

实际影响：

// 1. 软引用做缓存 — 内存紧张时自动清理Map<String,SoftReference<byte[]>>cache=newHashMap<>();cache.put("key",newSoftReference<>(newbyte[1024*1024]));// 2. ThreadLocal 用弱引用 — 但 key 弱引用不意味着 value 也弱！// ThreadLocalMap 的 key 是弱引用，value 是强引用// → 线程不销毁时 value 永远不会被回收 → 内存泄漏！ThreadLocal<Session>session=ThreadLocal.withInitial(Session::new);// 必须在使用完后显式 remove()session.remove();// 3. WeakHashMap — key 被回收时整个 entry 自动移除Map<Key,Value>map=newWeakHashMap<>();

GC 调优相关：

• 大量软引用对象 → Minor GC 时需要额外判断"内存是否充足"，可能拖慢 GC
• -XX:SoftRefLRUPolicyMSPerMB=N：控制软引用的存活时间（默认 1000ms/MB 空闲堆），调小可以更积极地回收软引用

八、JIT 编译参数

九、直接内存参数

什么时候关注：

• Netty / NIO 应用 → 直接内存用量大
• OOM: Direct buffer memory → 检查是否有 buffer 未释放

十、诊断与调试参数

OOM 时自动保存现场

# 发生 OOM 时自动 dump 堆（必加）-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=/var/log/app/heapdump.hprof# OOM 时直接退出进程（配合 K8s 自动重启，容器环境必加）-XX:+ExitOnOutOfMemoryError# OOM 时执行自定义脚本（如发告警）-XX:OnOutOfMemoryError="/opt/scripts/oom-alert.sh %p"

JFR（Java Flight Recorder）

# JDK 11+ 免费使用（JDK 8 需 Oracle JDK）-XX:StartFlightRecording=duration=60s,filename=/tmp/recording.jfr-XX:FlightRecorderOptions=stackdepth=128

常用诊断开关

十一、常用 JDK 诊断命令速查

Arthas（生产环境推荐）

# 安装curl-Ohttps://arthas.aliyun.com/arthas-boot.jarjava-jararthas-boot.jar# 常用命令dashboard# 实时仪表盘（线程、内存、GC）thread-n3# CPU 最高的 3 个线程watchcom.example.Service getUser'{params, returnObj, throwExp}'-n5# 观察方法调用trace com.example.Service getUser'#cost > 100'# 方法耗时追踪sc-dcom.example.Service# 查看类加载信息jad com.example.Service# 反编译（确认线上代码版本）