GC 调优与性能分析工具

• G1 Region 模型
• Humongous 对象定义
• 对 GC 的影响

G1 GC 把堆划分为等大小的 Region（默认 2048 个，大小由 G1HeapRegionSize 控制，通常 1-32MB），Region 在逻辑上分属新生代（Eden/Survivor）与老年代，且动态调整。对象在 Region 内分配。当对象大小超过 Region 的 50% 时，被视为 Humongous 对象，G1 会连续分配多个相邻 Region 存放（Humongous Region），这些 Region 不能与其他对象共享。Humongous 对象的影响：1) 浪费空间（Region 无法被小对象复用）；2) 分配时需找连续 Region，堆碎片化可能导致过早 Full GC；3) 回收时整块回收，进入老年代后 Mixed GC 处理较慢。优化：避免超大对象、调整 Region 大小、监控 Humongous 分配。

Region 模型是 G1 的基础，Humongous 对象是例外。理解 Region 与 Humongous 的影响是 G1 调优的核心。

• 并发标记流程
• Mixed GC 内容
• 回收策略

G1 的并发标记（Concurrent Marking）在堆占用达到 IHOP 时启动，分阶段：初始标记（STW，标记 GC Roots）、并发标记（并发遍历对象图）、重新标记（STW，修正并发期间的引用变化）、清理（STW/并发）。标记完成后，G1 识别出老年代中可回收的区域。Mixed GC（混合回收）在新生代回收后，额外回收一部分老年代区域（含高回收价值的 Region），目标是把老年代回收与新生代垃圾回收结合，控制停顿（MaxGCPauseMillis）。Mixed GC 不是全量老年代回收，而是分批回收高价值 Region，避免 Full GC。当老年代堆积过快、Mixed GC 跟不上时，会触发 Full GC。理解并发标记与 Mixed GC 是 G1 调优（IHOP、停顿目标）的关键。

并发标记找出可回收老年代 Region，Mixed GC 分批回收。理解两者交互是 G1 停顿与 Full GC 调优的核心。

• R2DBC 响应式数据库
• GC 压力
• 内存管理

R2DBC 是响应式数据库驱动，基于非阻塞 I/O，避免线程阻塞，提升了并发与吞吐。与 GC 的协作：R2DBC 的响应式处理会产生大量短生命周期对象（请求流水、数据缓冲、事件），增加新生代分配压力与 GC 频率；同时 R2DBC 使用 Netty 的堆外缓冲传输数据，涉及直接内存管理。协作要点：1) 监控分配速率与 GC 频率（响应式应用分配率高）；2) 合理设置新生代大小与 GC 选型（G1/ZGC 控制停顿）；3) 管理直接内存（MaxDirectMemorySize、Netty 池化），避免堆外 OOM；4) 避免数据缓冲泄漏（ByteBuf 未 release）。理解 R2DBC 的分配模式与 GC 交互，可优化响应式应用的 GC 与内存。

R2DBC 的高分配率与堆外缓冲影响 GC 与直接内存。理解其分配模式与 GC 协作是响应式应用调优关键。

• -Xlog:gc* 日志
• GC 日志分析
• GCeasy 工具

-Xlog:gc*（JDK9+ 统一日志）输出 GC 相关日志，包括 GC 停顿、各阶段耗时、堆使用、分配速率、晋升等。分析要点：GC 次数、停顿时长（均/最大）、堆使用趋势、晋升速率、Full GC 频率、分配速率。GCeasy 是 GC 日志分析工具：上传 GC 日志可自动生成报告，展示 GC 停顿分布、堆使用、分配速率、GC 原因、调优建议（如堆大小、GC 选型、参数）。生产诊断流程：开启 -Xlog:gc* 保存日志 → 用 GCeasy 或 GCViewer 分析 → 定位停顿来源（Full GC 频繁、晋升失败、分配过快）→ 针对性调优。GCeasy 让非专家也能快速读懂 GC 日志。

-Xlog:gc* 采集 GC 数据，GCeasy 自动分析给出调优建议。理解 GC 日志字段与工具分析是生产 GC 诊断的关键。

• STW 来源
• 治理策略
• 低延迟 GC

STW（Stop-The-World）是 GC 暂停所有应用线程的时间，是延迟的主要来源。治理策略：1) 选低延迟 GC：ZGC、Shenandoah 并发收集，STW 极短（<1ms）；G1 控制停顿目标；2) 调堆与分区：合理新生代大小减少 Minor GC 频率，避免 Full GC；3) 优化对象分配：减少对象创建、降低分配速率，减少 GC 压力；4) 监控并发标记与晋升：避免晋升失败、Humongous 导致 Full GC；5) 调 IHOP 避免并发标记滞后；6) 用 safepoint 日志排查 safepoint 停顿（非 GC 的 STW）。核心是"减少 STW 次数与时长"，通过低延迟 GC、合理堆与分配优化实现。

STW 治理围绕降低停顿频率与时长。选低延迟 GC + 优化分配与堆 + 排查 safepoint，是治理 STW 的关键。

• 吞吐/延迟/内存三角
• 各 GC 取舍
• 选型

GC 算法在吞吐量、延迟、内存占用三者间权衡：1) 吞吐型（Parallel）：追求总吞吐量，停顿时间长（STW 全量），内存利用率高；2) 延迟型（ZGC/Shenandoah）：追求低停顿，并发收集，内存占用与开销略高（需要额外内存/写屏障）；3) 平衡型（G1）：在延迟（停顿目标）与吞吐间平衡，通过 Region 与并发标记控制停顿。设计中"吞吐与延迟不可兼得"：低延迟需要更多并发工作与内存开销（牺牲吞吐/内存），高吞吐往往牺牲停顿。内存方面：低延迟 GC 可能需要更大堆或堆外结构。选型依据业务：高吞吐批处理选 Parallel，低延迟在线选 ZGC/Shenandoah，一般在线选 G1。

GC 是吞吐/延迟/内存的三角权衡。理解各 GC 的取舍点，才能按业务场景选型。

• 吞吐量与延迟指标
• 调优目标
• 取舍

GC 调优的两个核心指标：吞吐量（Throughput）= 应用执行时间 / 总时间（GC 时间占比越低吞吐越高），延迟（Latency）= 应用线程的停顿/响应时间（STW 时长）。调优目标：吞吐型追求 GC 时间占比最小（如 >99%），延迟型追求最大停顿可控（如 P99 < 阈值）。两者取舍：减少 GC 次数（大堆）提升吞吐但可能增加单次停顿；缩短停顿（并发 GC）降低延迟但增加 GC 开销降低吞吐。调优需先明确业务目标（吞吐优先还是延迟优先），再选 GC 与参数：吞吐优先选 Parallel/大堆，延迟优先选 ZGC/G1 + 停顿目标。监控指标：GC 时间、停顿分布、吞吐率，用 GC 日志与 JFR 评估。

吞吐与延迟是 GC 调优的目标维度，需先明确业务优先级。理解取舍并用指标验证是调优核心。

• ThreadMXBean API
• 线程 CPU 时间
• 线程状态采样

ThreadMXBean 是 JMX 的线程管理接口，提供线程 CPU 时间（getThreadCpuTime、getThreadUserTime）、线程状态（getThreadInfo 的 RUNNABLE/BLOCKED/WAITING/TIMED_WAITING）、线程栈、线程数等。工程价值：1) 线程 CPU 时间可定位 CPU 消耗高的线程（无需外部 profiler 即可采样）；2) 线程状态采样可发现线程阻塞、死锁、线程池满、资源等待；3) 结合监控定时采样线程状态，可定位线程问题（如大量 BLOCKED 表示锁竞争，大量 WAITING 表示池等待）。JDK 25 中 ThreadMXBean 支持虚拟线程（getThreadInfo 含虚拟线程），对虚拟线程的 CPU 时间与状态可监控。工程上用于线程健康监控、死锁检测、性能瓶颈初判。

ThreadMXBean 提供线程 CPU 时间与状态采样，是线程监控与诊断的基础。理解其能力与虚拟线程支持是关键。

• -Xlog:gc* 配置
• GC 日志内容
• 诊断价值

-Xlog:gc*（JDK9+ 统一日志）输出 GC 日志，包含每次 GC 的停顿时间、各阶段耗时（STW）、堆使用变化（before/after）、晋升/存活对象、GC 原因（GCTause）、Full GC 信息等。诊断价值：1) 定位 GC 停顿（次数、时长、分布）；2) 识别 Full GC 频繁（原因、触发）；3) 观察堆使用趋势与晋升速率（判断是否内存泄漏、对象存活）；4) 分析分配速率与 GC 压力；5) 结合 safepoint 日志定位停顿来源。通过 GC 日志可判断 GC 是否健康、是否需要调优（堆大小、GC 选型、参数）。是 GC 调优与故障诊断的基础数据。

-Xlog:gc* 是 GC 诊断的第一手数据。理解日志字段（停顿、堆、晋升、原因）是定位 GC 问题与调优的基础。

• JFR 虚拟线程事件
• 钉住（pinning）
• 载体线程与提交失败

分析虚拟线程，JFR 提供相关事件：jdk.VirtualThreadStart（启动）、jdk.VirtualThreadEnd（结束）、jdk.VirtualThreadPinned（钉住事件，虚拟线程被钉在载体线程上，阻塞了载体线程）、jdk.VirtualThreadSubmitFailed（提交失败，虚拟线程无法调度到载体线程）、以及载体线程相关事件、jdk.ThreadPark（挂起）。定位问题：1) 钉住事件 + 载体线程视角：若虚拟线程在 synchronized 块或 native 调用中钉住载体线程，会阻塞其他虚拟线程，通过 jdk.ThreadPinned 定位钉住点；2) 提交失败事件 + 载体线程池：若载体线程池耗尽（线程数不足/被钉住），虚拟线程无法调度，定位并发瓶颈；3) 结合启动/挂起事件看虚拟线程生命周期与等待。核心是识别"钉住导致载体线程被占"与"提交失败导致调度失败"。

虚拟线程性能问题常源于钉住与载体线程池耗尽。结合 JFR 的 VirtualThreadPinned/SubmitFailed 等事件定位根因。

• DirectByteBuffer
• MappedByteBuffer
• GC 与堆外内存

DirectByteBuffer（直接缓冲）与 MappedByteBuffer（内存映射文件）都是堆外内存（native memory），不受堆 GC 管理，但 DirectByteBuffer 的 Java 对象（DirectByteBuffer 实例）在堆上，其引用的堆外内存由 Cleaner 在 GC 时回收（DirectByteBuffer 被 GC 时触发 Cleaner 释放堆外内存）。协作要点：1) 堆不能直接 GC 堆外内存，堆外内存回收依赖 DirectByteBuffer 对象被 GC + Cleaner；2) 若 DirectByteBuffer 对象泄漏（长期持有），堆外内存泄漏，需 NMT 监控；3) MappedByteBuffer 映射文件，未显式 unmap 时 GC 释放映射，可能延迟；4) 大量堆外分配会导致 MaxDirectMemorySize OOM。理解 DirectByteBuffer 的 GC 触发回收机制与堆外管理，是避免堆外泄漏的关键。

DirectByteBuffer 堆外内存由 Cleaner 在 GC 时回收，堆外泄漏常因对象泄漏或未 unmap。理解 GC 与堆外协作是关键。

• jstat 监控
• jcmd GC.* 命令
• 采样策略

jstat 用于实时监控 JVM 统计（-gc 显示堆各区使用、GC 次数、GC 时间；-gcutil 显示各区使用率；-gccapacity 显示容量），用于观察 GC 频率与堆使用。jcmd 的 GC.* 命令：jcmd pid GC.class_histogram（类直方图）、GC.heap_info（堆信息）、GC.run（触发 GC）、GC.heap_dump（堆转储）。生产实时监控与采样策略：1) 定期采集（如每 30-60s）jstat -gcutil 与 GC 日志，观察趋势；2) 结合 JFR 持续录制（低开销）而非频繁手工命令；3) 生产环境优先用 JMX/JFR 采集，jcmd/jstat 用于按需诊断（有轻微停顿影响，如 class_histogram、heap_dump 会 STW）；4) 采样频率需平衡观测粒度与开销，避免高频命令干扰生产。策略：常态化 JFR/JMX 采集 + 按需 jstat/jcmd 诊断。

jstat 实时观测，jcmd GC.* 按需诊断，但部分命令有 STW。生产用 JFR/JMX 常态化采集 + 按需命令，控制开销。

• jdk.OldObjectSample 事件
• 堆外采样
• 资源限定

jdk.OldObjectSample 是 JFR 的"老对象采样"事件，用于识别内存泄漏（长生命周期对象），通过采样堆中存活对象并记录其分配调用栈，事件本身开销低。堆外采样（如分配采样）用于分析堆外内存。限定队列长度、并发上限和请求截止时间：这些是采样/监控参数设计的考量——1) 队列长度：限制采样事件缓冲队列大小，防止采样事件过多溢出；2) 并发上限：限制并发采样/分析线程数，避免资源竞争；3) 请求截止时间：对采样/分析请求设置超时，避免拖延。工程上配置 JFR 采样参数（如 OldObjectSample 的采样间隔、事件阈值）与监控系统的资源限制，避免采样本身成为性能瓶颈。理解这些限定的目的在于控制采样开销。

jdk.OldObjectSample 用低开销采样定位泄漏，采样需限定队列、并发、截止时间以控制开销。理解资源限定是采样实践关键。

• NMT baseline/diff
• 本地内存增长定位
• 无法归类的 malloc

NMT（Native Memory Tracking）通过 jcmd pid VM.native_memory baseline 建立基线，jcmd pid VM.native_memory detail.diff 对比基线后的变化，定位哪些 native 类别（thread、code、gc、internal、native、arena 等）内存增长。通过 diff 可定位增长来源（如线程栈增长、代码缓存增长、内部结构增长）。无法归类的 native malloc（NMT 无法归类的内存，显示为 "malloc" 或 "Unknown"）：需继续追踪：1) 用 -XX:NativeMemoryTracking=detail 获得更细分配点；2) 用 Linux 的 pmap/malloc 监控，或 jemalloc 的堆分析（若 JVM 使用 jemalloc）；3) 检查 JNI 代码、第三方 native 库的直接 malloc；4) 用 gdb/内存分析器定位原生分配；5) 对比系统 RSS 与 NMT 总和，差值即无法归类的 native 内存。无法归类的内存常来自 JNI/native 库的直接分配。

NMT baseline/diff 定位可归类 native 增长，无法归类的 malloc 需用 pmap/jemalloc/JNI 分析继续追踪。理解分工是关键。

• time to reach safepoint
• operation time
• 异常诊断

Safepoint 日志（-Xlog:safepoint）中，time to reach safepoint 是 JVM 发起 safepoint 请求到所有线程到达安全点的时间（等待线程到达），operation time 是 safepoint 内执行操作（如 GC 标记、JIT 的 Deoptimization）的时间。time to reach safepoint 异常（过长）说明有线程无法及时到达 safepoint，常见原因：1) 长循环未插入 safepoint 轮询；2) JNI 临界区/长时间 native 调用（safe-region）；3) 线程在系统调用中长时间阻塞；4) 线程数非常多，收敛慢。这会导致 GC 等操作延迟开始，表现为停顿/延迟毛刺。诊断：看 safepoint 日志中哪个线程阻塞，结合 JFR 的 safepoint/线程事件定位。

time to reach safepoint 反映等待线程到达的时间，异常说明有线程阻塞 safepoint。理解两者与异常成因是定位延迟的关键。

• 各 GC 特点
• 演进脉络
• 适用场景

GC 代际演进：Serial（单线程、简单、小堆/客户端）→ Parallel（多线程、高吞吐、批处理）→ CMS（并发标记清除，低延迟但碎片与 Full GC 问题，已被移除）→ G1（Region 化、并发标记、可预测停顿，JDK9+ 默认）→ ZGC（染色指针、分代、超低停顿 <1ms，大堆）→ Shenandoah（Brooks Pointer、并发移动，超低停顿）。演进方向：从"吞吐优先"到"延迟可预测"，从"全量 STW"到"并发收集"，从"单代"到"分代 + 并发"。当前主流：G1 默认，ZGC/Shenandoah 用于超低延迟，Parallel 用于高吞吐。理解演进脉络有助于按场景选型与理解各 GC 设计。

GC 演进是吞吐到低延迟的推进。理解各代 GC 特点与背景，才能正确选型与理解新 GC 设计。

• Spring Insights
• IntelliJ Profiler
• 本地与远程模式

Spring Insights 是 Spring Boot 4.0 提供的应用内可观测性诊断能力（基于 Spring 的观测自动埋点），在本地开发环境可查看请求耗时、SQL、Bean 初始化等诊断信息。IntelliJ Profiler 是 IntelliJ IDEA 的 Profiler 插件，支持 CPU/内存剖析（基于 async-profiler/JFR），本地开发可直接启动剖析。集成与远程模式：本地开发用 IntelliJ Profiler 直接对 Spring Boot 应用剖析（CPU/内存/线程），结合 Spring Insights 的观测数据定位问题；远程模式把 IntelliJ Profiler 或 JFR 远程连接（JMX/JFR 录制）到生产/测试实例分析，用 IntelliJ 打开远程 JFR 文件剖析。工程价值：本地快速定位、远程深入分析，Spring Insights 提供应用级诊断，IntelliJ Profiler 提供底层剖析。

Spring Insights 提供应用级诊断，IntelliJ Profiler 提供底层剖析，本地集成与远程模式互补。理解两者定位与远程连接是开发调优关键。

• ZGC 并发线程
• 子阶段
• 低停顿机制

ZGC 通过大量并发工作实现超低停顿，其 GC 流程分为多个子阶段：初始标记（STW，极短）、并发标记（并发遍历对象图）、并发重定位准备（收集确定重定位区域）、并发重定位（并发移动对象并更新引用）、并发重映射（更新引用）。并发线程（如并行 GC 工作线程）在并发阶段执行标记、重定位等，应用线程与 GC 线程并发运行，只在极短的初始标记/重定位停顿阶段 STW。ZGC 的并发线程数与并发标记、并发重定位的效率相关，通过 -XX:ConcGCThreads 控制并发 GC 线程数。子阶段协调使停顿保持在 <1ms。理解 ZGC 的并发子阶段是调优（并发线程数、堆）与诊断停顿的关键。

ZGC 并发子阶段分工协作，把 STW 压缩到极短。理解并发线程与子阶段是 ZGC 低停顿机制的核心。

• 染色指针机制
• 标记/重定位信息存储
• 工程价值

ZGC 的染色指针（Colored Pointer）把对象引用的 64 位指针的高位用于存储 GC 元数据（标记位、重定位地址、重映射状态），把 GC 状态信息编码在指针中，而非对象头。工程价值：1) 无需修改对象头即可记录 GC 状态，减少对象访问开销；2) 支持并发标记与重定位（通过指针位判断对象状态）；3) 减少内存占用（无需额外存储 GC 状态）；4) 配合读屏障实现并发的引用更新。局限：指针位数被占用，限制了最大堆大小（JDK 15+ 的 ZGC 在 64 位平台支持最大 16TB 堆，4TB 为 JDK 15 之前的限制）。染色指针是 ZGC 低停顿与并发设计的关键，理解其原理有助于理解 ZGC 特性与限制。

染色指针把 GC 状态编码进指针，减少对象头开销并支持并发。理解其原理与堆上限限制是 ZGC 调优基础。

• eBPF 系统调用追踪
• 与 trace id 关联
• 时钟校准

eBPF 可追踪系统调用（如文件、网络、锁），获取系统调用延迟。与 Java trace id 关联：通过线程 ID（TID）与时间戳关联——eBPF 记录系统调用的线程 ID 与时间，Java 应用在日志/监控中带 traceId 与线程 ID，按线程 ID 和时间戳把 eBPF 系统调用延迟与 Java trace（traceId）关联，定位"哪个请求的哪次系统调用慢"。时钟源不一致时校准：eBPF 与 Java（JFR/JVM）可能用不同时钟源（CLOCK_MONOTONIC vs CLOCK_REALTIME）或不同基准，需校准：1) 统一时钟源（都用 CLOCK_MONOTONIC）或记录偏移；2) 用同一时间戳基准（如启动时间）换算；3) 采样同一时刻的时钟对齐；4) 用时间戳差值补偿时钟偏移。关联精度取决于时钟校准与线程 ID 匹配。

eBPF 系统调用与 Java trace 通过线程 ID + 时间戳关联，跨时钟源需校准。理解关联与校准是跨层诊断的关键。

• eBPF 火焰图
• 内核态/用户态追踪
• 瓶颈定位

eBPF（Linux 4.x+）可在内核安全执行追踪程序，无需修改内核。用于系统级性能分析：1) 内核态火焰图（on-cpu 内核栈）、off-cpu 火焰图（等待/阻塞）、系统调用延迟跟踪；2) 追踪热点（perf、bpftrace、BCC）定位内核态瓶颈（磁盘、网络、锁、调度）；3) 用户态（Java）通过 JFR/async-profiler 获得用户态火焰图。定位内核态/用户态瓶颈：若用户态火焰图显示热点在系统调用/native 方法，需结合内核态火焰图（eBPF）看系统调用内部（如磁盘 I/O、网络、锁、页错误）定位内核瓶颈；结合 off-cpu 火焰图定位等待时间。联合用户态与内核态火焰图，定位跨层瓶颈（如 Java 应用触发大量系统调用导致内核繁忙）。

eBPF 提供内核态火焰图与系统调用追踪，与用户态剖面联合定位跨层瓶颈。理解内核/用户态联合分析是关键。

• 各命令停顿影响
• 权限影响
• 生产使用注意

jcmd 命令的停顿与权限影响：1) VM.native_memory：查看 NMT 内存，通常无 STW（读快照），需启用 NMT（-XX:NativeMemoryTracking），有内存开销；2) GC.class_histogram：输出类实例直方图，会触发 STW（全堆扫描），有停顿影响，需小心在生产使用；3) Thread.print：打印线程转储，会触发 safepoint（STW 短停顿），有轻微停顿影响。权限影响：jcmd 需能 attach 到目标 JVM（同用户或调试权限），容器内可能受限。生产使用注意：class_histogram 与 Thread.print 会 STW，需在低峰或谨慎使用；频繁执行会加重停顿。选择低停顿命令（native_memory、thread dump 用 jstack 但同样 safepoint）并控制频率。

不同 jcmd 命令停顿影响不同（class_histogram 全量 STW，Thread.print 短暂 safepoint）。生产需权衡停顿与诊断价值。

• VisualVM/JMX 远程
• 安全配置
• 堆/线程转储分析

VisualVM 2.x 通过 JMX 远程连接 JVM，可查看堆/线程、生成堆转储与线程转储、运行 JFR 等。Spring Boot 4.0 远程分析的安全配置：1) 启用 JMX 远程（spring.jmx.enabled、-Dcom.sun.management.jmxremote），配置监听端口；2) 认证：启用 JMX 认证（-Dcom.sun.management.jmxremote.authenticate=true，配置用户/密码文件），避免未授权访问；3) SSL：配置 JMX SSL（-Dcom.sun.management.jmxremote.ssl=true + keystore）加密传输；4) 限制访问：绑定内网/管理网段，用防火墙/网络策略限制 JMX 端口；5) 只读 vs 读写的权限最小化。生产建议通过 SSH 隧道或专用管理通道访问 JMX，避免直接暴露。堆/线程转储分析用 VisualVM 打开转储文件分析。

远程 JMX/VisualVM 必须启用认证与 SSL 并限制访问。理解 Spring Boot 4.0 的 JMX 配置与安全边界是关键。

• 分配火焰图含义
• 分配速率 vs 存活内存
• 交叉验证

分配火焰图（allocation profiling）显示的是各分配点的分配速率（分配频率/体积），而非存活内存（当前存活的占用）。分配热点高不代表内存泄漏（可能对象短命被快速回收）。为准确判断内存问题，需交叉验证：1) 与 OldObjectSample 交叉：OldObjectSample 识别长生命周期对象（存活对象），若分配热点对应 OldObjectSample 中的对象，说明对象存活（潜在泄漏）；若分配热点但对象短命（GC 回收），则只是高频分配，非泄漏；2) 与堆转储交叉：堆转储（当前存活对象的快照）看哪些对象占用大、被谁持有，若分配热点对象在堆转储中占大且被长期持有，则确认泄漏；3) 结合 GC 日志看对象晋升/存活率。核心：分配速率（火焰图）区分"频繁分配"与"存活泄漏"，需用存活数据（OldObjectSample/堆转储）佐证。

分配火焰图反映速率，需用存活数据交叉验证才能区分高频分配与泄漏。理解两者的差异与配合是关键。

• 锁火焰图
• 等待时间与持锁路径
• 采样盲区

锁火焰图（lock profiling）展示锁相关的时间：等待锁的时间（线程等待获取锁）与持锁路径（谁持有锁、持锁期间调用栈）。async-profiler 的 lock 事件采样锁等待/阻塞，火焰图宽度反映等待锁的比例，可定位热点锁与持锁路径。采样不到短锁不能证明没有竞争：采样是抽样，短锁（持有时间极短）可能很少被采样到，即使存在竞争也可能漏采；且锁竞争的开销（上下文切换、缓存线冲突）可能不在采样点。因此未采样到不代表无竞争，需结合：1) 增加采样频率（lock 事件）；2) 用 JFR 的锁事件（更精确的锁等待统计）；3) 用 jstack 多次采样看线程 BLOCKED 状态；4) 压测观察吞吐/延迟。结论：采样盲区需多手段佐证。

锁火焰图展示等待与持锁路径，但采样对短锁有盲区。需结合 JFR 锁事件与多采样佐证，不能仅凭未采样判定无竞争。

• GC 日志与 JFR
• 交叉验证
• GC 停顿定位

GC 日志（-Xlog:gc*）与 JFR 的 GC 事件（jdk.GCPhase、jdk.GCHeapUsage、jdk.GCAllocation 等）都记录 GC 停顿，需交叉验证：1) 时间对齐：GC 日志与 JFR 事件的时间戳对齐（同一时钟/时间基准），确认同一 GC 停顿对应；2) 交叉验证停顿来源：GC 日志给出 GC 停顿时长与阶段，JFR 的 GCPhase 事件给出各阶段细分耗时，验证停顿构成（标记/清除/重定位）；3) 关联性能事件：把 GC 停顿与 JFR 的线程事件（线程阻塞）、锁事件、safepoint 事件关联，判断停顿是否由 GC 引起还是 safepoint 阻塞；4) 验证分配速率：GC 日志的分配速率与 JFR 的 Allocation 事件交叉，确认 GC 压力来源。交叉验证可避免单一数据源误判，准确定位停顿根因。

GC 日志与 JFR 交叉验证停顿来源与阶段，关联性能事件定位根因。理解时间对齐与维度互补是关键。

• -Xmx 堆大小
• MaxGCPauseMillis 停顿目标
• G1HeapRegionSize

G1 的关键调优参数：1) -Xmx：堆最大大小，决定堆容量，影响 GC 频率与停顿（堆越大 GC 次数越少但单次停顿可能更大，超过压缩指针阈值还会增加内存）；2) -XX:MaxGCPauseMillis：G1 的停顿目标（默认 200ms），G1 自适应调整新生代/回收策略以尽量满足停顿目标，但无法保证绝对；3) -XX:G1HeapRegionSize：Region 大小（默认按堆自动计算，通常 1-32MB），影响 Region 数量、Humongous 阈值与回收粒度。调优联动：堆大小与停顿目标影响 G1 决策，Region 大小影响 Humongous 与回收粒度。调优需结合 GC 日志观察实际停顿与 Full GC，权衡堆大小与停顿目标，避免目标过严导致频繁 GC。

这三个参数是 G1 调优基础，堆大小、停顿目标、Region 大小联动影响 GC 行为。理解相互作用与调优原则是关键。

• Shenandoah 与 ZGC 对比
• 低停顿机制
• 适用场景

Shenandoah 与 ZGC 都是低延迟 GC，目标超低停顿（<1ms）：Shenandoah 用 Brooks Pointer（前向指针）与并发移动对象，实现并发回收；ZGC 用染色指针与读屏障，实现并发标记与重定位。对比：两者停顿都极低，但机制不同（Shenandoah 用 Brooks Pointer + 写屏障，ZGC 用染色指针 + 读屏障）；Shenandoah 在 JDK 引入早、实验性，ZGC 分代模式更成熟；ZGC 有堆上限（染色指针限制），Shenandoah 无严格堆上限；实现细节上，Shenandoah 的并发移动开销略高，ZGC 的读屏障开销略高。适用场景：都适合大堆、低延迟在线服务（如高并发 Web、支付、实时系统）；选择取决于 JDK 版本支持、堆大小、团队熟悉度与实测。G1 仍是一般在线默认，超低延迟场景选 ZGC/Shenandoah。

Shenandoah 与 ZGC 都是超低停顿 GC，机制不同。适用超低延迟在线场景，按机制、堆限制与实测选择。

• JFR 默认事件开销
• 存储开销
• 长时间运行策略

JFR 2.x 在 JDK 25 中默认事件（profile 配置）通过环形缓冲（默认最大 100MB 内存缓冲）记录，通常不直接落盘（除非持续录制），运行开销低（profile 配置约 1-2% CPU）。存储开销：环形缓冲固定大小，事件满时覆盖最旧，不无限增长；持续录制到文件时，文件按配置增长，需管理磁盘。Spring Boot 长时间运行策略：1) 用持续的 JFR 录制（-XX:StartFlightRecording=disk,filename=...,maxage/maxsize 限制），保留最近窗口（如 24h/1GB）；2) 用 -XX:FlightRecorderOptions 限制缓冲/文件大小；3) 定期转储与归档（jcmd JFR.dump，配合定时任务），避免文件无限增长；4) 用 JFR Streaming API 实时消费低开销也可；5) 监控 JFR 本身开销（避免影响生产）。策略是"持续录制 + 限制窗口 + 定期归档"。

JFR 默认低开销、环形缓冲不无限增长。长时间运行需限制录制窗口、定期归档，监控开销。理解存储策略是关键。

• jdk.GCHeapSummary 事件
• 堆使用变化
• 延迟分析

jdk.GCHeapSummary 是 JFR 的 GC 堆摘要事件，在 GC 事件时记录堆使用情况（各代使用、总堆、提交内存），用于观察堆变化趋势。与延迟分析关联：结合其他 GC 事件（jdk.GCPause、jdk.GCPhase）可分析：1) GC 前后堆使用变化，判断回收效率与对象存活；2) 堆使用趋势（持续上升可能内存泄漏）；3) GC 停顿与堆变化的关系（堆增长导致停顿增加）。延迟分析：通过 GC 停顿事件（jdk.GCPause）的耗时与堆摘要关联，定位"堆增长 → GC 停顿增加"的延迟问题。工程上 JFR 的 GC 事件组合（HeapSummary + Pause + Phase）提供完整的 GC 与延迟视角。

jdk.GCHeapSummary 记录堆使用，与 GC 停顿事件关联可分析延迟根因。理解事件组合是 JFR GC 诊断关键。

• CPU Load
• 执行采样
• 样本比例 vs 耗时

JMC（JDK Mission Control）中：CPU Load 反映进程/系统的 CPU 占用率（用于判断 CPU 是否饱和）；执行采样（Execution Sampling）反映各方法被采样的次数比例（方法在 CPU 上被采样到的占比）；方法耗时（Method Profiling）反映方法的实际耗时。不能把样本比例直接当耗时：样本比例是"采样频率下的近似占比"，而非绝对耗时；且采样只覆盖 CPU 上的时间（on-CPU），不含等待/IO/锁阻塞时间；采样频率有限，短方法可能漏采；方法耗时受调用次数影响（高频小方法样本占比高但单次耗时小）。因此样本比例用于"相对热点排序"，需结合调用次数、实际耗时（如 JFR 的方法耗时数据）与 off-CPU 分析综合判断。

样本比例是相对热点，非绝对耗时。理解采样局限（on-CPU、频率、漏采）是正确解读 JMC 剖析的关键。

• perf/bpftrace
• native 方法分析
• 系统调用分析

Linux perf 与 bpftrace 用于内核级与 native 级性能分析：perf 可采样 CPU 事件（含 native 栈、内核栈），bpftrace 用 eBPF 追踪系统调用、内核函数、动态探针。在 JDK 分析中：1) Native 方法（如 JNI 调用、JDK 内 native 代码、第三方 native 库）的 CPU 热点，Java profiler（async-profiler）可结合 perf 采样 native 栈；2) 系统调用级别：用 bpftrace/perf 追踪应用触发的系统调用（read/write/recv/send/lock/fsync），定位系统调用瓶颈（磁盘 I/O、网络、锁）；3) 内核态 + 用户态联合火焰图定位跨层瓶颈。适用场景：Java 应用的 native 热点（如加密、压缩、I/O 库）、系统调用延迟、内核瓶颈。配合 async-profiler 的 perf 支持可分析 native 栈，bpftrace 分析系统调用。

perf/bpftrace 深入 native 与系统调用层，配合 Java profiler 定位跨层瓶颈。理解其能力与适用场景是关键。

• Brooks Pointer 原理
• 并发移动
• 前向指针

Shenandoah 的 Brooks Pointer 是在对象头中预留的一个前向指针（forwarding pointer），用于支持并发移动对象（concurrent evacuation）。当对象被移动时，Brooks Pointer 指向新位置；访问对象时通过读屏障检查 Brooks Pointer，若对象已移动则跟随前向指针访问新对象。这使得 Shenandoah 能在应用线程并发运行的情况下移动对象并更新引用，实现低停顿（移动不 STW）。Brooks Pointer 增加对象头开销（对象头变大）与写屏障/读屏障开销，但换来了并发移动与超低停顿。Brooks Pointer 是 Shenandoah 与 ZGC（染色指针）不同的并发移动机制，理解其原理是理解 Shenandoah 低停顿与开销的关键。

Brooks Pointer 是对象头中的前向指针，配合读屏障支持并发移动。理解其原理与开销是 Shenandoah 设计核心。

• jcmd 命令
• jstat 命令
• 诊断用途

jcmd 是 JDK 的诊断命令工具，常用命令：jcmd pid help（列出命令）、VM.system_properties（系统属性）、VM.flags（生效 JVM 参数）、VM.native_memory（NMT）、GC.class_histogram（类直方图）、GC.heap_dump（堆转储）、GC.run（触发 GC）、Thread.print（线程转储）、JFR.start/dump（JFR 录制）、Compiler.codecache（代码缓存）。jstat 是 JVM 统计监控工具：jstat -gc pid（堆各区 GC 与容量）、-gcutil（各区使用率）、-class（类加载）、-compiler（编译）、-gccapacity（堆容量）。jcmd 用于诊断操作（转储、参数、NMT），jstat 用于实时观测统计。理解两者命令与用途是 JVM 诊断基础。

jcmd 诊断操作，jstat 观测统计。掌握常用命令与用途是 JVM 故障排查的基础。

• 火焰图结构
• 宽度与栈
• 热点识别

火焰图是一种可视化调用栈的剖析图：x 轴表示采样占比（宽度），y 轴表示调用栈深度（从底部调用者到顶部被调用者）。每个矩形代表一个函数，宽度表示该函数在采样中出现的比例（对该事件类型的占比）。解读要点：1) 顶部（最上层）函数是"叶子"（实际执行的方法），顶部宽表示热点函数自身耗时高；2) 底部宽表示被广泛调用（调用方多）；3) 每个矩形宽度代表相对占比，找"最宽顶部"即热点；4) 颜色通常表示类型（CPU/内存/锁）；5) 结合事件类型解读（CPU 火焰图看 CPU 热点，lock 火焰图看锁竞争，off-cpu 火焰图看等待）。查看"栈顶最宽的平顶"是定位热点最直接的方法。

火焰图通过矩形宽度与栈深展示热点，顶部宽是热点关键信号。理解结构与解读方法是性能分析基础。

• 容量规划
• 回滚条件
• 生产变更安全

生产操作（上线、调优、扩容）前应设置容量与回滚条件：1) 容量：明确峰值流量下的容量需求（吞吐、内存、连接数、存储），预留缓冲（如 2 倍峰值），配置监控阈值（CPU/内存/GC 亚健康预警）；2) 回滚条件：定义明确的回滚触发指标（如吞吐下降 >X%、错误率上升 >Y%、p99 延迟超阈值、GC 停顿异常、内存 OOM），达到即回滚；3) 回滚机制：配置镜像/版本化，能快速回滚（如容器镜像回退、参数回退）；4) 观察期：变更后观察一段时间（如 30min）确认稳定再视为成功；5) 备份：变更前备份配置与数据。核心是"先定义可量化的成功/回滚标准，再操作"，避免盲目操作无法评估。

生产操作前需定义容量与回滚标准，量化指标与快速回滚机制是生产安全的关键。理解"先定标准再操作"原则。

• profile 与 default 配置
• 事件阈值与栈深
• 开销取舍

JFR 的 profile 与 default 是两种录制配置：default 配置只记录高价值、低开销事件（如 GC、异常、线程开始），事件阈值高、栈深小、开销最低；profile 配置记录更多事件（如方法采样、sockets、I/O、分配），事件阈值低、栈深大、开销较高（约 1-2% CPU）。取舍：生产持续录制常用 default（低开销、关键事件），按需用 profile（详细剖析）短期录制；profile 的栈深大（如 2048 帧）能捕获深调用栈，但开销高；default 栈深小、开销低。工程上：持续运行用 default 或自定义低开销配置，排障时临时用 profile 录制窗口。profile 与 default 的取舍是"详细度 vs 开销"。

default 低开销适合持续录制，profile 详细但开销高适合短期排障。理解阈值/栈深/开销取舍是 JFR 配置关键。

• JMC 功能
• JFR 事件分析
• 可视化诊断

JMC（JDK Mission Control）是 JDK 的可视化诊断工具，用于分析 JFR 录制数据，提供：1) 概览（CPU、内存、线程、GC 的摘要）；2) 事件浏览器（按类型查看 JFR 事件，如 GC、异常、方法采样、锁）；3) 代码热方法（方法采样分析 CPU 热点）；4) 线程分析（线程状态、阻塞、锁）；5) GC 分析（GC 停顿、堆使用）；6) 内存分析（分配、泄漏）。JDK 25 中 JMC 支持最新 JFR 事件（虚拟线程、AOT 等）。工程价值：加载 JFR 文件即可可视化诊断，定位 CPU 热点、GC 停顿、线程阻塞、内存泄漏。配合自动规则（如 JMC 的规则引擎）可自动提示问题。

JMC 是 JFR 分析的可视化入口，提供 CPU/GC/线程/内存多维诊断。理解其功能是高效分析 JFR 的关键。

• Foreign Function & Memory API
• 堆外内存管理
• 与 GC 协作

Foreign Function & Memory API（JEP 454，JDK 22 定稿，JDK 25 稳定）提供安全、高效地访问堆外内存与调用 native 函数的能力，替代 JNI 的部分场景。堆外内存管理：通过 MemorySegment/Arena 显式管理堆外内存（allocate、scope、release），支持自动（try-with-resources 的 Arena）与手动释放，比 JNI 更安全。与 GC 协作：堆外内存由 Arena 管理，不占用堆 GC；内存段可关联到 GC 作用域（Arena 关闭时自动释放），避免直接/堆外内存泄漏；与 GC 配合（如映射到堆外减少堆压力）可降低 GC 频率。工程价值：安全建堆外内存、减少 JNI 复杂性与风险、提升 native 调用性能，是堆外内存与 GC 协作的现代方案。

FFM API 提供安全堆外内存管理与 native 调用，Arena 作用域与 GC 协作防泄漏。理解其价值是堆外内存现代方案。

• UseZGC 启用
• 分代 ZGC
• <1ms 停顿价值

JDK 25 中启用 ZGC 用 -XX:+UseZGC，JDK 25 默认分代模式（JEP 439，Generational ZGC）。分代 ZGC 通过年轻代/老年代分代回收，提升吞吐与内存效率，同时保持极低停顿（<1ms）。工程价值：<1ms 停顿让 GC 停顿几乎不可感知，对延迟敏感的服务（实时交易、高并发 API、游戏）可在不牺牲吞吐的前提下享受低延迟，避免 GC 停顿导致的延迟毛刺；分代模式比单代 ZGC 更高效（短命对象快速回收）。启用注意：ZGC 需要足够内存（与堆大小相关）、支持染色指针（堆上限约 4TB）、与容器/调优参数配合。适合大堆低延迟在线服务。

ZGC 分代模式的 <1ms 停顿是低延迟服务的核心价值。理解启用方式与分代收益是关键。

• JFR 采集
• OTel 导出
• K8s 集成

在 K8s 中实现 Spring Boot 应用的 Profile 数据采集与导出：1) JFR 采集：容器内启动 JFR（持续录制或按需），或用 JFR Streaming API 实时读取事件；2) OTel 集成：用 OpenTelemetry Java Agent 的 JFR 集成（或 jfr 相关 exporter）把 JFR 事件转换为 OTel 的 profile 信号，通过 OTLP 导出到 OTel Collector；3) K8s 部署：容器挂载 JFR 文件/配置，用 sidecar 或 Collector 采集；4) 导出：Collector 把 profile 数据转发到后端（如持续剖析平台、Jaeger、OTel 后端）。工程价值：把 JFR 的剖析数据纳入统一可观测性（与 metrics/traces/logs 关联），实现 K8s 中 Spring Boot 的持续剖析与下钻。需配置 JFR 录制参数与 OTel exporter。

JFR 采集 + OTel 导出，把 profile 纳入统一可观测。理解采集与导出链路是 K8s 持续剖析的关键。

• -Xlog:gc* 维度
• jdk.GCPhase 维度
• 差异与互补

-Xlog:gc* 与 JFR 的 jdk.GCPhase 事件都记录 GC 停顿，但维度不同：1) -Xlog:gc* 是文本日志，按 GC 事件输出（每次 GC 的停顿、堆、原因），粒度到"GC 事件级别"，侧重于整体停顿与堆变化，适合事后 grep 分析与趋势统计；2) jdk.GCPhase 是结构化事件，记录每个 GC 阶段（标记、清理、重定位等）的细分耗时与 STW 标记，粒度到"阶段级别"，适合精确分析停顿构成与定位阶段瓶颈。差异：GC 日志看"整体与原因"，JFR 看"阶段细节与时间线"。互补：用 GC 日志看 GC 频率与 Full GC，用 JFR 的 GCPhase 下钻各阶段停顿，交叉验证停顿来源。JFR 事件可与 GC 日志时间对齐关联。

GC 日志看整体，JFR 看阶段细节。理解维度差异，结合两者交叉验证停顿构成是关键。

• JFR Streaming API
• 实时事件流
• 自定义消费

JFR Streaming API（jdk.jfr.consumer 的 RecordingStream）允许在 JVM 运行时实时消费 JFR 事件流，无需转储文件。工程价值：1) 实时监控：应用内实时订阅事件（GC、异常、线程、分配）并处理（统计、告警）；2) 自定义分析：按需开启事件、过滤、聚合，无需外部工具；3) 低开销：Streaming 按需订阅，避免全量录制；4) 与监控集成：把 JFR 事件实时推送到监控系统（如自定义 exporter）。用法：try (RecordingStream rs = new RecordingStream()) { rs.enable("jdk.GCPhase").withPeriod(...); rs.onEvent("jdk.GCPhase", e -> {...}); rs.start(); }。JDK 25 中 Streaming API 支持虚拟线程等新事件。价值是让 JFR 数据可编程、可实时接入应用逻辑。

JFR Streaming API 实时消费事件流，可编程接入监控。理解其实时性与自定义能力是工程应用关键。

• park/unpark 事件
• 虚拟线程同步
• 热点分析

JFR 在虚拟线程下采集 park/unpark 事件（jdk.ThreadPark、jdk.VirtualThreadPinned 等），记录虚拟线程的挂起/恢复。park/unpark 是虚拟线程同步的基础（虚拟线程阻塞通过 park 实现），JFR 的 ThreadPark 事件记录挂起时间、原因、栈，可分析同步热点：1) 定位虚拟线程频繁 park/unpark（抖动、忙等）导致的同步开销；2) 分析锁等待（synchronized）与 park 的关联；3) jdk.ThreadPinned 定位钉住（阻塞载体线程）的同步点；4) 结合载体线程事件看调度。通过 JFR 的 park/unpark 事件分析虚拟线程的同步原语热点，识别锁竞争、无效唤醒、调度开销。JDK 25 对虚拟线程的 JFR 支持更完善。

JFR 的 park/unpark 事件分析虚拟线程同步热点。理解事件与虚拟线程同步机制，可定位同步开销。

• jdk.CPUTimeSample 事件
• 采样与脱敏
• 诊断价值

jdk.CPUTimeSample（JEP 509，JDK 25）是 JFR 的 CPU 时间采样事件，提供线程的 CPU 时间采样（按线程维度），用于 CPU 使用分析。异常信息脱敏与保留诊断价值平衡：JFR 事件可能包含方法名、类名、异常信息等，其中可能含敏感数据（如类路径、业务标识）。脱敏（如 JFR 配置过滤、事件字段掩码）可保护合规，但过度脱敏会丢失诊断价值（无法定位热点方法与异常）。平衡策略：1) 对敏感字段（如业务类名、含用户信息的字符串）脱敏，保留方法名/栈结构；2) 用 JFR 的过滤/自定义事件隔离敏感内容；3) 保留关键诊断信息（方法、耗时、栈）以满足排障；4) 按数据级别（内部 vs 生产合规）配置脱敏粒度。核心是"可诊断前提下的最小化脱敏"。

平衡纪律与诊断可用性，对敏感字段脱敏但保留诊断结构。理解 JFR 事件字段与脱敏粒度是关键。

• JProfiler/YourKit 功能
• 内存泄漏检测
• CPU 热点定位

JProfiler 与 YourKit 是商业 Java 剖析工具，提供：1) CPU 剖析：CPU 热点定位（方法耗时、调用树、火焰图），识别热点方法；2) 内存剖析：堆分配、存活对象、对象引用路径，检测内存泄漏（找泄漏对象与 GC Roots）；3) 线程剖析：线程状态、阻塞、锁；4) 数据库/JDBC 分析。工程价值：内存泄漏检测通过"对象分配回溯 + 引用路径"定位泄漏源；CPU 热点定位通过采样/插桩定位性能瓶颈。相比 JFR/async-profiler，它们的优点是可视化、易用、自动规则与向导，适合开发/测试环境快速定位；生产环境常用 JFR/async-profiler（低开销）。价值在交互式定位开发阶段问题。

JProfiler/YourKit 提供交互式内存泄漏与 CPU 热点定位，适合开发测试。理解其价值与生产工具的差异。

• 分配采样 vs CPU 采样
• 采样模式差异
• 生产线程干扰

JProfiler/YourKit 的分配采样（allocation sampling）采样对象分配点，统计分配频率与体积，用于定位分配热点；CPU 采样（CPU sampling）采样线程在 CPU 上的调用栈，定位 CPU 热点。差异：分配采样关注"分配在哪里"，CPU 采样关注"CPU 花在哪里"。对生产线程的干扰：1) 采样型（sampling）干扰小（定期采样，低开销）；2) 插桩型（instrumentation）干扰大（在方法插入探针，增加调用开销，可能改变方法行为）；3) 分配采样可能触发 JVMTI 事件，有开销；4) 生产环境使用采样模式（非插桩）减少干扰，且避免长时间运行。理解采样模式差异与干扰，生产用低干扰的采样模式，避免插桩影响性能。

分配采样 vs CPU 采样定位不同问题，采样模式干扰小、插桩干扰大。生产用采样模式避免干扰线程。

• Actuator 指标
• JFR 事件关联
• GraalVM Native Image 兼容

Spring Boot 4.0 的 Actuator 指标（Micrometer）与 JFR 事件关联（如 GC 指标 ↔ JFR 的 GC 事件），在 GraalVM Native Image 下需处理 AOT 兼容性：Native Image 是 AOT 编译，基于反射/动态代理的指标绑定（如 JFR 事件、Micrometer 的运行时绑定）需在构建时配置。配置要点：1) 用 GraalVM 的反射配置（reflect-config.json）声明 JFR 事件类与 Micrometer 反射依赖；2) 用 -H:ReflectionConfigurationFiles 或 Spring Boot 的 native 提示（hints）注册；3) 用 Spring AOT 的 hints（@NativeHint、RuntimeHintsRegistrar）注册 JFR 事件与指标绑定；4) 验证 JFR 事件在 Native Image 下是否可用（JFR 在 Native Image 支持有限，需确认）。工程上通过 Spring 的 native hints 与反射配置注册，保证 Actuator 指标与 JFR 关联在 Native Image 下正常。

Native Image 下 JFR 与指标绑定需 AOT hints 与反射配置。理解 Spring native hints 与反射注册是关键。

• 各工具命令
• 最佳实践
• 生产注意事项

JDK 25 诊断工具：jcmd（综合诊断，VM.flags、VM.native_memory、GC.class_histogram、GC.heap_dump、Thread.print、JFR.start 等）；jstack（线程转储，打印线程栈与死锁）；jmap（内存信息，-heap 堆信息、-dump 堆转储、-histo 类直方图）；jstat（统计监控，-gc、-gcutil、-class、-compiler）。最佳实践：1) jstack 查看线程状态/死锁（瞬时，生产可用但触发 safepoint）；2) jmap -dump 堆转储用于内存分析（STW，需谨慎）；3) jstat 实时观测 GC/堆（低开销）；4) jcmd 一站式诊断（prefer 到 jcmd 替代部分 jmap/jstack 功能）；5) 生产环境控制 STW 命令频率，用 JFR/JMX 常态化采集。理解各工具用途与停顿影响，组合使用是 JVM 诊断最佳实践。

jcmd/jstack/jmap/jstat 各有用途，需理解停顿影响并组合使用。生产环境用 JFR/JMX 常态化，工具按需诊断。

• jstack 诊断
• jconsole 监控
• jvisualvm 可视化

jstack 用于打印线程转储，查看线程状态（RUNNABLE/BLOCKED/WAITING）、死锁、锁持有，定位线程阻塞与死锁。jconsole 是 JMX 监控控制台，实时查看堆内存、线程、类加载、GC 摘要、MBean，监测进程健康。jvisualvm（VisualVM）提供可视化剖析：CPU/内存抽样、线程分析、堆转储/线程转储、JFR 集成，是图形化诊断工具。诊断价值：jstack 快速定位线程问题；jconsole 实时监控 JVM 资源；jvisualvm 综合可视化（剖析、堆分析、线程）。三者配合：jstack 定位线程阻塞，jconsole 看资源趋势，jvisualvm 深入剖析（CPU 热点、堆泄漏）。对生产环境，jstack/jconsole 开销小，jvisualvm 剖析适合开发/测试；远程访问需安全配置。

jstack 线程诊断、jconsole 实时监控、jvisualvm 综合剖析。理解三者定位与使用场景是 JVM 诊断基础。

• coordinated omission
• 尾延迟低估
• 开放模型与补偿

coordinated omission（协调遗漏）是压测工具在系统变慢时"停止计时"导致的误差：压测工具按固定节奏发请求（闭合模型），当请求排队变慢时，工具可能在等待期间不采样/不注入新请求，导致慢请求的等待时间被记入"请求进程内部"而非"延迟"，从而低估高百分位（尾延迟，如 p99）。修正：1) 开放模型（open model）：按固定速率持续注入请求（无论系统响应快慢），使慢请求的排队时间被计入总延迟，如实反映尾延迟；2) 补偿记录：把"因排队而延迟发出的请求"的等待时间补记入延迟，或用"时间戳差异"记录真实响应时间；3) 用异步/非阻塞注入避免工具自身阻塞影响计时。本质是"不要因系统变慢而停止计时或漏记请求"。

coordinated omission 低估尾延迟源于工具在变慢时遗漏计时。开放模型与补偿记录能如实反映排队延迟。