JVM 性能调优实战

• 调优目标定义
• 度量指标
• 调整与验证

GC 调优的通用方法论（目标-度量-调整-验证）：1) 目标：先明确调优目标（吞吐量、延迟、停顿目标），如"p99 延迟 < 100ms"或"GC 时间占比 < 5%"，避免无目标调优；2) 度量：用 GC 日志、JFR、监控采集度量（GC 停顿、次数、堆使用、分配速率、晋升率），建立基线；3) 调整：根据度量分析瓶颈，调整参数（堆大小、GC 选型、新生代比例、IHOP、停顿目标），一次只改一个变量；4) 验证：用压测/基准对比调整前后的度量，确认达到目标且无回归（吞吐、延迟、GC）；5) 迭代：若未达标回到度量/调整，持续迭代。关键是"先定目标、再度量基线、单变量调整、量化验证"。避免凭感觉调参。

GC 调优是"目标-度量-调整-验证"的闭环。先定目标、单变量调整、量化验证是方法论核心。

• CompileThreshold 编译阈值
• MaxInlineLevel 内联深度
• UseNUMA

JIT 调优参数：1) CompileThreshold：方法调用多少次触发 JIT 编译，调整编译激进程度（低阈值早编译、高阈值晚编译），影响启动性能与稳态性能；2) MaxInlineLevel：最大内联深度（默认 9），限制方法内联的嵌套层数，调整内联深度影响 JIT 优化（内联消除调用开销，但深内联增加编译与代码膨胀）；3) UseNUMA：启用 NUMA 感知的内存分配，减少跨节点访问（多 socket 场景）。JIT 调优要点：CompileThreshold 控制编译时机，MaxInlineLevel 控制内联深度，UseNUMA 影响内存分配。多数场景 JIT 默认参数已足够，调优需结合解剖（JFR/async-profiler）确认热点再调整，避免盲目调优。理解各参数作用是 JIT 调优基础。

CompileThreshold 控制编译时机、MaxInlineLevel 控制内联、UseNUMA 影响内存。JIT 调优需基于剖析与实测。

• 常见误区
• 反模式
• 避免方法

JVM 调优常见误区与反模式：1) 盲目套用网上的参数组合，不结合自身应用（无目标、无度量）；2) 只调堆大小/GC 选型，忽略代码层面的分配、锁、I/O 问题（调优应优先解决代码热点）；3) 一次调多个参数，无法归因；4) 只关注吞吐忽略延迟（或反之），不符合业务目标；5) 用未预热/未固定环境的基准对比，结果失真；6) 沿用旧参数（如偏向锁、CMS）在现代 JDK 无效；7) 内存调优只盯着堆，忽略堆外（元空间、直接内存）与容器限制；8) 过度调优（如堆设得过大导致 OOMKill）。避免：先定位问题（profiling/GC 日志）、明确目标、单变量调整、量化验证、结合代码与系统优化。理解误区是避免调优走弯路的关键。

调优误区源于无目标、无度量、盲目套参数。先定位问题、单变量、量化验证是避免误区的关键。

• TLAB 机制
• 分配速率与 GC
• 分配优化

TLAB（Thread Local Allocation Buffer）为每个线程在新生代预分配缓冲，线程内分配无需竞争，减少分配竞争。对象分配速率对 GC 的影响：分配速率高 → 快速填满新生代 → 频繁 Minor GC；若对象存活率高或晋升老年代，则老年代压力大、可能 Full GC。分配优化方向：1) 减少对象分配（复用对象、避免频繁创建、用池化/缓存）；2) 避免意外装箱（自动装箱）、字符串拼接（用 StringBuilder）；3) 减少大对象（避免 Humongous）；4) 调整 TLAB 大小（-XX:TLABSize）与新生代大小，匹配分配速率；5) 用分代 GC 合理处理短命对象。核心是"降低分配速率与减少存活对象"，从代码层面降低 GC 压力。理解 TLAB 与分配速率是 GC 调优关键。

TLAB 减少分配竞争，分配速率决定 GC 频率。优化分配（减少对象、防装箱）是降低 GC 压力的关键。

• SoftMaxHeapSize
• UncommitDelay
• ZGC 调优

ZGC 的调优参数：1) -XX:SoftMaxHeapSize：设置 ZGC 的"软性堆上限"，ZGC 优先保持堆不超过该值，但当内存压力大时可超过（避免 GC 停顿），用于平衡堆大小与 GC 频率（软上限内尽量不触发 GC，超限后加大 GC）；2) -XX:ZUncommitDelay（UncommitDelay）：设置 ZGC 将堆内存归还给操作系统前的延迟时间（默认 300s），控制堆内存的释放时机（避免频繁归还/重新申请的开销）。ZGC 调优要点：SoftMaxHeapSize 控制堆的目标上限与 GC 节奏，UncommitDelay 控制内存归还延迟。理解这两个参数可精细调 ZGC 的堆与内存行为，适合大堆低延迟场景。

SoftMaxHeapSize 是软上限平衡 GC，UncommitDelay 控制内存归还延迟。理解其语义是 ZGC 调优关键。

• Young/Old 比例
• 晋升阈值
• Humongous 对象

堆内存调优：1) Young/Old 比例：通过 NewRatio/G1 的新生代配置调整新生代与老年代大小，新生代大 → Minor GC 少但阶段长、晋升慢；老年代大 → 减少 Full GC 但对象堆积；需匹配对象存活率与分配速率；2) 晋升阈值（-XX:MaxTenuringThreshold，提升到老年代的存活次数阈值）：调高可减少短期晋升（对象在新生代多存活几轮），调低可减少新生代复制；需结合对象存活分布；3) Humongous 对象：G1 中超过 Region 50% 的对象，跨 Region 分配浪费空间并可能触发 Full GC，需避免大对象或调整 Region 大小。调优结合 GC 日志观察对象存活、晋升、Humongous，按实际调整。理解三者平衡是堆调优核心。

Young/Old 比例、晋升阈值、Humongous 是堆调优的三个维度。结合 GC 日志观察对象行为再调整。

• cgroup 感知
• MaxRAMPercentage
• 容器调优

容器环境 JVM 调优：1) cgroup 感知（-XX:+UseContainerSupport，默认开启）：JVM 读取 cgroup 内存/CPU 限制，按容器限额计算默认堆与 CPU 数，避免按宿主机配置导致 OOM；2) MaxRAMPercentage：设置堆占容器内存的百分比（如 70-75%），留出堆外空间（元空间、直接内存、线程栈、CodeCache）；3) 配合 ActiveProcessorCount 指定 CPU 数（避免容器 CPU 视图不准）；4) 设置 MaxMetaspaceSize、MaxDirectMemorySize 控制堆外；5) 监控容器内存（RSS 与 limits），避免 OOMKill。要点：容器内堆 + 堆外 ≤ 容器内存限额，MaxRAMPercentage 留足堆外，CPU 配额正确。理解 cgroup 感知与 MaxRAMPercentage 是容器调优核心。

容器调优关键是堆+堆外≤限额。MaxRAMPercentage 留堆外、cgroup 感知正确识别资源。

• -Xss 线程栈
• 虚拟线程调度
• 栈与线程

线程栈调优：1) -Xss：设置线程栈大小（默认 1MB），栈影响递归深度与线程内存占用；栈小省内存但深递归易 StackOverflowError，栈大支持深递归但线程多时内存大；需按方法调用深度调整；2) 虚拟线程调度：虚拟线程栈在堆中动态分配，不受 -Xss 直接限制（可设置 -XX:MaxStackSize），虚拟线程数量可极大（不占固定栈内存），由 JVM 调度到载体线程；调优关注堆内存（虚拟线程栈）与载体线程池（避免钉住导致调度瓶颈）。平台线程用 -Xss 控制栈，虚拟线程用调度配置与堆管理。理解 -Xss 与虚拟线程栈的差异是线程栈调优关键。

-Xss 控制平台线程栈，虚拟线程栈在堆中动态分配。理解两者差异是线程栈调优关键。

• 堆大小
• GC 选型
• 线程栈与直接内存

高并发服务 JVM 参数组合：1) 堆大小：根据容器内存与对象规模设置（容器用 MaxRAMPercentage，如 70-75%），避免堆外挤占；2) GC 选型：高并发在线服务常用 G1（可预测停顿）或 ZGC（超低延迟），低延迟优先；设置 MaxGCPauseMillis 停顿目标；3) 线程栈：-Xss 按需（默认 1MB 一般够用，避免过大浪费内存）；高并发用虚拟线程可降低线程栈内存；4) 直接内存：设 MaxDirectMemorySize（Netty/IO 场景），避免 DirectBuffer OOM；5) 元空间：MaxMetaspaceSize 限制防膨胀；6) 其他：CodeCache、UseContainerSupport。组合原则：堆 + 堆外 ≤ 容器内存，GC 匹配延迟需求，线程栈/直接内存按需限制。示例：-Xmx${heap} -XX:MaxRAMPercentage=70 -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:MaxMetaspaceSize=256m -XX:MaxDirectMemorySize=512m -Xss512k。理解参数组合与限制是配置关键。

高并发 JVM 组合考虑堆、GC、线程栈、直接内存、元空间。关键是内存预算与延迟匹配。

• -Xms/-Xmx 堆
• 元空间/直接内存
• 配置关系

JVM 内存参数分层：1) 堆（-Xms 初始、-Xmx 最大）：对象存储，受 -Xms/-Xmx 控制（容器用 MaxRAMPercentage）；2) 元空间（-XX:MaxMetaspaceSize 限制）：类元数据，默认无上限（JVM 动态增长），需设置上限防膨胀；3) 直接内存（-XX:MaxDirectMemorySize 限制）：DirectBuffer，默认等于 -Xmx，需按需设置；4) 线程栈（-Xss）、CodeCache（-XX:ReservedCodeCacheSize）。配置关系：堆 + 元空间 + 直接内存 + 线程栈 + CodeCache 等组成了 JVM 进程总内存，配置时需统一预算（尤其容器内 ≤ 限额）。-Xms/-Xmx 控制堆，-XX 系列控制堆外（元空间/直接内存/栈/CodeCache）。理解各层配置与总预算关系是 JVM 内存配置关键。

JVM 内存分堆与堆外（元空间/直接内存/栈/CodeCache）。各层需统一预算，避免堆外挤占或 OOM。

• Region 大小
• 停顿目标
• IHOP 与日志验证

G1 关键调优参数：1) G1HeapRegionSize：Region 大小（默认按堆自动计算，1-32MB），影响 Humongous 阈值与回收粒度；2) MaxGCPauseMillis：停顿目标（默认 200ms），G1 自适应调整；3) InitiatingHeapOccupancyPercent（IHOP）：并发标记触发阈值（默认 45%），影响 Mixed GC 与 Full GC。日志验证：用 -Xlog:gc* 观察 GC 停顿（是否满足停顿目标）、Full GC 频率（IHOP 是否滞后）、Humongous 分配、Region 使用；用 JFR 的 GC 事件验证阶段耗时。调优流程：观察 Full GC 频繁 → 调 IHOP/Region；停顿超目标 → 调 MaxGCPauseMillis/新生代；结合日志验证调整效果。理解参数与日志验证是 G1 调优关键。

Region、停顿目标、IHOP 是 G1 三大参数。用 GC 日志验证停顿与 Full GC 再调整。

• THP 机制
• HugePages 配置
• 对 JVM 影响

透明大页（THP）与 HugePages 都使用大页内存提升 TLB 命中：HugePages 是显式配置的大页（系统预留，JVM 用 -XX:+UseLargePages 启用）；THP 是内核自动把普通页合并为大页（透明，无需应用配置）。对 JVM 影响：1) HugePages 显式大页可减少 TLB miss，提升性能，但需系统预留大页，JVM 才能申请；2) THP 自动合并可能引入性能波动（后台合并线程、内存碎片、延迟毛刺），生产环境常建议关闭 THP（echo never > /sys/kernel/mm/transparent_hugepage/enabled）或调整，因为 THP 对大堆 JVM 的延迟/稳定性有负面影响。配置：生产用显式 HugePages（-XX:+UseLargePages）+ 系统预留，或关闭 THP。理解 THP 与 HugePages 差异与影响是 JVM 大页配置关键。

HugePages 显式预留、THP 自动合并。THP 可能引入延迟波动，生产常关闭 THP 用显式大页。

• 低延迟 GC
• 高吞吐 GC
• 业务匹配

GC 选型按业务匹配：1) 低延迟（在线服务、交易、实时交互）：选 ZGC/Shenandoah（超低停顿 <1ms，但开销略高），或 G1（停顿可预测，默认），满足尾延迟要求；2) 高吞吐（批处理、离线计算、大数据）：选 Parallel GC（高吞吐、STW 长但吞吐优先），或 G1（吞吐与延迟平衡）；3) 一般在线：G1（默认，平衡）。选型依据：延迟敏感度（能否容忍 STW）、吞吐需求、堆大小、内存预算。ZGC/Shenandoah 牺牲部分吞吐/内存换取低停顿，Parallel 牺牲停顿换取吞吐。理解业务匹配是 GC 选型核心：低延迟选 ZGC/Shenandoah/G1，高吞吐选 Parallel/G1。

GC 选型匹配业务：低延迟选 ZGC/Shenandoah，高吞吐选 Parallel。理解吞吐与延迟权衡是选型关键。

• JMC/JFR
• async-profiler
• GCViewer

JVM 调优工具链组合：1) JFR：JDK 内置事件录制，低开销，采集 JVM 事件（GC、锁、线程、异常、分配），用于持续监控与数据采集；2) JMC：分析 JFR 文件，可视化 CPU/GC/线程/内存，定位 JVM 内部问题；3) async-profiler：采样剖析，生成火焰图（CPU/alloc/lock/wall），定位代码级热点；4) GCViewer：分析 GC 日志，可视化 GC 停顿、堆使用、分配速率，辅助 GC 调优。组合流程：JFR+JMC 采集与定位 JVM 内部（GC/锁）、async-profiler 定位代码热点、GCViewer 分析 GC 日志辅助 GC 调优。工具链覆盖"全局监控 → 内部定位 → 代码定位 → GC 调优"。理解工具链分工是高效调优关键。

工具链：JFR/JMC 采集分析、async-profiler 火焰图、GCViewer 分析 GC。组合覆盖完整调优流程。

• Full GC 频繁成因
• 内存泄漏/大对象/元空间
• 参数误配

Full GC 频繁的定位：1) 内存泄漏：堆转储（-XX:+HeapDumpOnOutOfMemoryError + MAT 分析）定位泄漏对象与 GC Roots，确认对象无法回收导致老年代持续增长；2) 大对象/Humongous：G1 大对象跨 Region 浪费空间并触发 Full GC，用 GC 日志/分配剖析定位大对象；3) 元空间：类加载器泄漏导致元空间膨胀，触发 Full GC（元空间回收），用 NMT/类加载监控定位；4) JVM 参数误配：堆太小（-Xmx 不足）、新生代过大、IHOP 设置不当、GC 选型不合适，导致频繁 Full GC。排查流程：看 GC 日志（Full GC 原因、堆趋势）→ 判断是内存泄漏/大对象/元空间/参数 → 用堆转储/NMT/GC 日志定位 → 修复。理解各成因与排查手段是关键。

Full GC 频繁的成因（泄漏、大对象、元空间、参数）需逐一排查。用 GC 日志、堆转储、NMT 定位。

• 停顿来源
• 分配速率
• 晋升失败

GC 日志与 JFR 联合分析：1) 停顿来源：GC 日志给出 GC 停顿与原因，JFR 的 GCPhase 事件给阶段细分，结合 safepoint 事件定位停顿来源（GC 还是 safepoint 阻塞）；2) 分配速率：GC 日志/GC 摘要显示分配速率，JFR 的分配事件（ObjectAllocationSample）定位分配热点，确认 GC 压力是否来自高分配；3) 晋升失败：GC 日志显示晋升失败（promotion failed），JFR 的 GC 事件关联，确认是否老年代空间不足或碎片，定位晋升失败根因（对象存活率、老年代大小、Humongous）。联合分析交叉验证：用 GC 日志看整体，JFR 看细节与分配/晋升，时间对齐定位停顿与 GC 压力来源。理解联合分析是 GC 诊断关键。

GC 日志看整体停顿，JFR 看阶段与分配/晋升。联合交叉验证定位停顿与 GC 压力来源。

• 各工具用途
• 诊断场景
• 组合

线上 JVM 诊断工具箱：jps 列出 JVM 进程（pid）；jstat 实时监控统计（GC、堆、类加载、编译，如 -gcutil）；jmap 内存信息（-heap 堆摘要、-dump 堆转储、-histo 类直方图）；jstack 线程转储（线程状态、死锁）；jcmd 综合诊断（VM.flags、VM.native_memory、GC.class_histogram、GC.heap_dump、Thread.print、JFR.start 等）。用途：jps 找进程；jstat 看 GC/堆趋势；jstack 看线程阻塞/死锁；jmap -dump 堆转储分析内存；jcmd 一站式诊断（NMT、JFR、参数）。诊断流程：jps 定位进程 → jstat 看 GC/资源 → jstack 看线程 → jmap 转储分析内存 → jcmd 深入（NMT/JFR）。注意停顿时长（jmap -dump、jstack 有 STW）。理解工具组合是线上诊断基础。

jps/jstat/jmap/jstack/jcmd 构成诊断工具箱。按问题类型选用，注意 STW 命令谨慎使用。

• DirectByteBuffer 泄漏
• Netty 堆外泄漏
• 定位方法

堆外内存泄漏排查：1) DirectByteBuffer 泄漏：直接内存未被释放（DirectByteBuffer 对象未 GC 或 Cleaner 未触发），用 NMT（-XX:NativeMemoryTracking）看 direct buffer 占用，结合堆转储看 DirectByteBuffer 对象数量与持有者；2) Netty 堆外泄漏：ByteBuf 未 release（池化内存未归还），导致堆外内存持续增长；用 Netty 的 -Dio.netty.leakDetectionLevel=paranoid 开启泄漏检测，日志报告泄漏位置；用 JFR 的 jdk.DirectBufferStatistics 或 NMT 监控直接内存；3) 定位：监控直接内存增长（NMT/JFR），开启 Netty 泄漏检测，分析堆转储/分配点，找出未释放的 ByteBuf 或 DirectByteBuffer。堆外泄漏常导致 RSS 持续增长最终 OOM。理解排查手段是堆外泄漏定位关键。

DirectByteBuffer 用 NMT/堆转储定位，Netty 用 leakDetection 检测。监控直接内存增长是定位关键。

• PrintFlagsFinal
• 参数校验
• 生效确认

-XX:+PrintFlagsFinal 在 JVM 启动时打印所有 JVM 标志的最终值（含默认值与显式设置值），用于校验参数是否生效。用法：java -XX:+PrintFlagsFinal -version 或 java -XX:+PrintFlagsFinal -jar app.jar 输出所有标志。校验：1) 查看某个参数的实际生效值（如 -XX:+PrintFlagsFinal | grep MaxHeapSize 确认堆大小）；2) 确认显式参数是否被接受（如已废弃参数会报错或忽略）；3) 区分默认值（用 = 表示默认）与显式设置（用 := 表示被修改）；4) 对比不同 JDK 版本默认值。运行时用 jcmd pid VM.flags 查看当前生效参数。校验参数生效可避免"以为设置了但没生效"或"参数被废弃"导致的调优无效。理解 PrintFlagsFinal 是参数校验关键。

PrintFlagsFinal 打印所有标志最终值，= 默认、:= 显式设置。校验参数生效避免调优无效。