不存在jhc这一JVM工具，它既非JDK自带也非主流JVM发行版组件；常见混淆源于误拼javac、误引Haskell编译器jhc或内部脚本别名。
没有 jhc 这个官方或主流 JVM 工具。 你大概率是记混了名称——JDK 自带的性能分析工具里，jstat、jcmd、jfr（Java Flight Recorder）和 jvisualvm 是真实可用的；而 jhc 并不存在于 OpenJDK 或 Oracle JDK 的任何版本中，也不是 GraalVM 或其他主流 JVM 发行版的组件。
为什么搜不到 jhc，但有人提过类似名字？
可能是以下几种混淆：
- 把
javac（Java 编译器）或java命令误拼为jhc； - 将 Haskell 的
jhc（一个已停止维护的 Haskell 编译器）错误关联到 JVM 场景； - 看到某些内部脚本、第三方封装工具（如某公司自研的
jhc别名脚本）后当成通用工具。
实际做 GC 停顿分析，必须依赖 JDK 自带或标准生态工具，否则数据不可信、无法复现。
用 jfr + JDK Mission Control 精确捕获停顿时间分布
jfr 是目前最可靠、开销最低、支持全阶段 GC 事件记录的机制，尤其适合对比不同 GC 算法下的停顿分布。关键不是“启动就录”，而是控制采样粒度与目标事件：
- 启用时明确指定 GC 相关事件：
jcmd <pid> VM.native_memory summary配合jcmd <pid> VM.unlock_commercial_features（如需商业特性）； - 录制命令示例：
java -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+FlightRecorder -XX:StartFlightRecording=duration=120s,filename=gc-g1.jfr,settings=profile -jar app.jar； - 对
Parallel、ZGC、Shenandoah分别重复上述命令，确保业务负载完全一致（建议用相同压测脚本 + 固定 QPS）； - 用
JDK Mission Control（jmc）打开多个.jfr文件，在 “Event Browser” 中筛选GCGarbageCollection事件，导出 CSV 后用 Excel 或 Python 统计pauseTime字段的分布（P50/P90/P99/最大值）。
用 jstat 快速验证 GC 频次与平均停顿趋势
jstat 不记录单次停顿，但能暴露算法行为差异，适合初步筛查：
- 高频
Young GC+ 低Full GC：说明新生代策略激进（如Parallel Scavenge默认行为）； - 大量
Concurrent Mode Failure日志伴随长停顿：典型 CMS 在堆增长过快时的崩溃信号； -
G1下mixed gc次数突增但pauseTime波动大：可能-XX:InitiatingHeapOccupancyPercent设得太低，或大对象分配打乱 Region 选择； - 执行命令：
jstat -gc -h10 <pid> 1000 60（每秒输出 10 行，持续 60 秒），观察GCT（总 GC 时间）、YGCT（年轻代耗时）、FGCT（Full GC 耗时）三列变化节奏。
容易被忽略的关键控制点
对比结果失真，往往不是工具问题，而是环境没控住：
- 所有测试必须关闭
-XX:+UseAdaptiveSizePolicy（默认开启），否则 GC 会动态调堆，让不同算法跑在不同内存条件下； - 堆大小必须固定：
-Xms4g -Xmx4g，避免 OS 内存抖动干扰停顿； - 禁止混用
-XX:+UseStringDeduplication等非 GC 主路径特性，它们会引入额外 STW 阶段； - 业务负载要“稳态”：前 30 秒预热（触发 JIT 编译、GC 初始化），后 120 秒才开始采集，跳过 GC 初始震荡期。
真正决定停顿分布的，从来不是“选哪个工具”，而是能否让每次运行只变一个量——GC 算法本身。其余所有参数、负载、系统状态，都得锁死。否则你看到的不是算法差异，只是噪声。
