JDK Mission Control 安装、JFR 分析与工作区治理手册
JMC 不是 JFR 的另一个名字
JDK Mission Control，简称 JMC，是独立安装的分析与监控产品。它可以读取 JFR 文件、运行自动分析规则、浏览原始事件，也能通过 JMX 观察在线 JVM。JFR recording 是否启动、repository 如何轮换、最终文件是否完整，仍由目标 JVM 和 JDK 工具负责。把两者写成一个工具，会让人误以为关闭 JMC 窗口就结束了录制，或者为了看一份离线文件去开放远程管理端口。
JMC 最擅长的不是“找出最宽的方法”，而是把 CPU、GC、分配、锁、I/O 和线程事件放回同一问题窗口。规则页可以提示异常区域，真正可交付的结论仍需回到事件、调用栈、目标构建和业务指标。它是分析工作台，不是自动根因判定器。
安装时先选发行方和运行 JDK
OpenJDK JMC 项目发布源码，不直接规定唯一二进制发行物；官方项目列出了 Oracle、Eclipse Adoptium、Azul、BellSoft、Red Hat 等下游。团队应固定一个批准来源，不要让每位分析者从不同下载站取包。本文使用 Oracle JMC 9.1.2 作为可复现实验基线，这个版本号只约束实验与截图，不表示将来仍是最新版本。
Oracle JMC 9 系列需要合适的 64 位 JDK 运行 JMC 本身。这个 JDK 与生成 recording 的目标 JDK 是两件事：前者决定桌面应用能否启动、插件能否加载，后者决定 .jfr 中存在哪些事件与字段。安装记录至少保存 JMC 发行方、完整版本、压缩包校验值、运行 JDK 的供应商与完整 build、操作系统和架构。
Windows、Linux 与 macOS 的包结构略有不同，启动后都应在 About 或安装详情中核对实际版本。若需要显式选择运行 JDK，可以按发行包说明使用启动参数或配置文件，不要只修改全局 PATH 后假设所有桌面快捷方式已经切换。受控工作站的验收可以包含：
JMC distribution = Oracle JMC 9.1.2
JMC runtime JDK = approved 64-bit JDK 21+ build
Workspace = encrypted user-owned directory
Network = no direct production access by default
Plugins = base installation only这里是配置合同，不是 Markdown 任务列表。升级时把新版本装在独立目录，用同一组脱敏录制回归，再切换桌面入口；直接覆盖旧目录会混淆插件、缓存和回退边界。
第一件事是核对录制身份
打开 .jfr 后先看起止时间、JVM 版本、进程与主机信息、录制设置和事件概况。文件名可能在传输或工单中被改过，不能用名字证明它属于目标实例。证据清单中的 SHA-256、实例 ID、应用构建、JDK build 和采集窗口应与文件内信息互相印证。
随后在 JMC 中框选告警前后的一段时间。整份录制的平均值会把短暂锁竞争、GC 峰值或 I/O 尖峰摊薄。多个页面应共享同一选择窗口，否则 CPU 页看到故障段，GC 页却仍在显示全程，最后会拼出一个并不存在的因果链。
| 首轮核对 | 能证明什么 | 不能证明什么 |
|---|---|---|
| 录制起止与目标身份 | 文件来源和问题窗口大致匹配 | 文件没有被截断或缺少关键事件 |
| Event Type 数量 | 某类事件确实被记录 | 没有事件就代表没有问题 |
| JVM 与 OS 信息 | 解释器、GC、主机上下文 | 容器配额和邻居竞争已被完整记录 |
| Recording Settings | 当时使用的模板和阈值 | 实际业务开销一定在可接受范围 |
Automated Analysis 负责指路，不负责签字
JMC 的 Automated Analysis 会按规则评估 GC、线程、方法分析、环境等区域，并给出分数或提示。规则阈值基于通用经验，不理解服务的 SLO、业务阶段或容量模型。高分项适合确定下一步打开哪个页面，不能直接复制为事故结论。
例如规则提示长 GC pause，应回到暂停事件、GC 原因、分配速率、回收后的 live set 和请求窗口。堆使用率高但回收后稳定，不等于泄漏；堆占用不高但分配率极高，也可能频繁触发回收。规则提示锁竞争时，要区分 jdk.JavaMonitorEnter 和 jdk.JavaMonitorWait，再看持有者、等待者与业务线程池；连接池等待和 LockSupport.park 也不能都归入 synchronized 锁。
JMC 版本升级可能改变规则实现和阈值。同一份录制在两个版本中分数不同，并不表示原始事件改变。团队若把规则分数用于门禁，必须固定 JMC 与规则版本，保存阈值来源，并让门禁最终落在可核验事件或业务指标上。
CPU 页面先分清机器、JVM 和方法样本
机器 CPU 高而 JVM CPU 低，可能是邻居进程或宿主层争用；JVM CPU 高才继续看 thread CPU 与 execution samples。容器中还要补充 cgroup throttling，因为配额耗尽会让可运行线程排队，JMC 看到的 host 视角不一定等于 Pod 可用容量。
方法样本的宽度表示采样命中次数，不是精确业务耗时，也不是调用次数。短方法、native 代码、未被采中的线程和错误的窗口都会造成空白。热点栈若指向序列化或日志格式化，还要用请求量、对象大小与相同输入复测；仅凭一个宽框就重写代码，常常只是把成本移到另一个调用者。
Method Profiling 页面中要同时看调用者和被调用者。叶子方法很宽，可能是它本身昂贵，也可能只是所有上游都经过这里。若优化方案改变了内联、线程调度或分配，采样形态也会随之改变，比较前后必须保持负载、JDK、JFC 和窗口一致。
GC 与内存页面按生命周期解释
GC 分析先对齐暂停，再看回收效果。最长暂停、总暂停、触发原因、代际或区域变化、分配速率和回收后 live set 共同决定结论。Old Object 或 GC root 相关事件能帮助筛选潜在长寿命对象，但成本高于普通 allocation sample；它们仍不是完整 heap dump 的 dominator tree。
Allocation sample 回答“哪些路径不断分配”，不回答“哪些对象仍被谁保留”。某个 byte array 分配热点可能来自高吞吐但及时回收的编码路径；某个实例数很少的容器对象却可能保留大量图。需要完整对象关系时，应按 jcmd、jstack 与 jmap 手册 的摘流、容量、权限和销毁流程升级 heap dump，而不是在 JMC 中把采样结果强行解释成泄漏。
内存结论应包含业务生命周期。缓存随预热增长后稳定、批任务阶段性抬升后回落，与持续跨周期增长是三种现场。JMC 时间轴需要和请求量、缓存命中、批次边界及 GC 日志同步，不能把绝对值脱离负载比较。
线程、锁和 I/O 要回到等待对象
线程页中 RUNNABLE 不等于正在烧 CPU，位于 native Socket read 的线程也可能显示可运行。WAITING 不一定异常，空闲线程池就应等待。真正有价值的是同一问题窗口中，哪些线程反复停在同一调用链，谁持有关键 monitor，等待是否与连接池、队列或下游端点指标同步增长。
Socket 与 File I/O 事件可以显示持续时间、端点和调用栈，但事件阈值、异步框架和 native 实现会让记录不完整。一个端点没有慢事件，只能说明当前配置没有记录到；一个端点事件很长，也要确认它是否对应用户请求关键路径。Trace、连接池指标和系统调用证据负责补齐 JFR 视角之外的部分。
事件浏览器适合做反向核对。先从规则或页面形成假设，再在 Event Browser 中过滤相应事件类型，检查阈值、字段、线程和栈。不要一开始导出全量事件到表格后凭肉眼搜索，那会丢失时间选择和事件语义，还容易把敏感字段复制到不受控位置。
JMX 是另一条在线控制边界
JMC 可以连接本地或远程 JMX，查看 MBean、触发器、内存、线程与诊断命令。JMX 在线视图和 JFR 离线分析不是同一风险：前者需要网络、认证、TLS 与目标可用性，部分 MBean 操作还会改变状态；后者只需受控分析文件。生产默认优先导出 JFR 离线分析，不为方便打开 JMX 公网入口。
确需远程 JMX 时，registry 端口与 RMI 服务端口都要固定，绑定管理网地址，启用认证和 TLS，通过防火墙或受控隧道限制来源。口令文件、truststore 与 keystore 由密钥系统下发，权限只给运行用户。JMC 工作区可能保存主机、连接名、用户名或证书引用，因此工作区也属于敏感配置，不应同步到普通网盘或提交源码仓库。
JMX 连接成功只证明管理通道建立。团队还要验证权限是否只能读取批准对象、触发器是否真的执行、断开后临时端口是否关闭，以及证书轮换后旧信任是否退出。为了排查连接失败而临时关闭认证、TLS 或改为监听 0.0.0.0，会把一次性能分析变成远程控制面暴露。
插件会扩展能力，也会扩大供应链
JMC 支持独立应用和 Eclipse 形态的插件。插件拥有读取录制、访问工作区，甚至连接目标 JVM 的能力，不能按“只是一个视图”处理。基线安装应从无额外插件开始，每个插件记录来源、版本、更新站、许可、所需网络和实际用途。
安装后用固定脱敏录制验证页面能打开、字段能解释、导出不会泄露额外数据。插件升级失败时，先回到独立工作区和基础 JMC 复现；不要在唯一工作区中反复卸载、重装并继续产出正式结论。代理仅用于下载插件或访问更新站，不参与本地 JFR 解析，代理凭证不能写进可分享的首选项导出。
JMC 的自动更新也应进入变更管理。分析工作台可能在两次事故之间悄然改变规则与导出格式，导致同一录制得出不可复现的页面。受控环境更适合显式升级、保存安装包与校验值，并让旧版本在回退窗口内可启动。
一个可重复的分析实验
实验输入应由 JFR 手册 的小堆样本产生，并把文件复制到只读源目录。为本次分析建立独立工作区和输出目录，先用 CLI 记录摘要与哈希：
SRC="/approved/evidence/lab-profile.jfr"
test -s "$SRC"
sha256sum "$SRC"
jfr summary "$SRC" > summary.txt在 JMC 中打开文件，确认录制身份和窗口，然后查看 Automated Analysis、Method Profiling、Garbage Collections、Threads、Lock Instances 与 Event Browser。正向证据是 CPU 样本能指向实验线程，锁事件在降低阈值的录制中更明显，并且两份文件的设置差异可解释。反向证据是默认阈值下锁事件缺失；此时应得出“当前录制不足以判断”，而不是“没有锁竞争”。
将时间窗口移出实验活跃段再观察一次，可以直观看到窗口选择如何改变排名。随后恢复到正确窗口，并用 Event Browser 查到原始事件。实验结论只保存必要截图、事件类型、窗口和解释，不导出全量事件。关闭 JMC 后重新计算源文件哈希，证明分析过程没有修改原始制品。
文件打不开时从兼容与完整性分层排查
JMC 报错首先用产生录制的同版本 JDK 运行 jfr summary。CLI 也失败，优先检查文件是否仍在写入、传输是否截断、磁盘是否曾满，或它其实是 repository chunk 而非完整录制。CLI 成功而 JMC 失败，再检查 JMC 发行版、运行 JDK、插件和文件版本兼容性。
规则页为空不等于文件无价值，可能是相关事件没有开启、窗口太短或规则不支持该事件版本。Event Browser 仍可查看原始类型。页面卡顿则要考虑文件体积、事件数量、工作站内存和第三方插件；不要把超大敏感录制上传到公共在线分析器换取便利。
本地进程看不到时，确认 JMC 使用的是完整 JDK，而非只有 JRE 的运行环境，再检查目标 PID、effective UID/GID、Attach 禁用和 PID namespace。远程连接失败另查 JMX 地址、两个端口、TLS 信任与认证，不能把离线文件问题和在线连接问题混为一类。
导出报告不能丢掉分析上下文
JMC 页面截图适合说明一个局部现象，却很容易丢失录制身份、选择窗口、单位、筛选条件和工具版本。正式报告应让截图旁边保留源文件哈希、JMC 发行版、运行 JDK、窗口起止的相对位置、事件类型与筛选表达式。若只留下“CPU 热点”四个字和一张调用树，接手者无法判断它来自整段平均、告警窗口还是一次错误选择。
团队需要批量生成规则报告时，可以使用 JMC Core API 或项目提供的报告入口，但自动化仍要锁定依赖版本并保存原始 .jfr。规则输出适合做待复核信号，不适合作为无需人工解释的发布裁决。API 升级要用同一批脱敏录制比较规则 ID、阈值、严重度和缺失事件处理；输出格式变化也要进入消费者契约测试。
导出的 HTML、CSV 或截图可能复制线程名、路径、主机、Socket 地址与自定义事件字段，敏感级别不低于源录制。最小化导出比全量转存更容易治理：只保留支持结论的窗口和字段，记录派生文件哈希与源哈希关系，并让源文件、报告、工单附件和分析机缓存共享同一删除期限。
工作区、导出和结论都需要退出
JMC 工作区会积累连接定义、插件状态、缓存、最近打开文件和界面布局。正式分析使用按事件隔离的工作区，源 .jfr 保持只读，临时导出进入同一受控证据根。分析结束后记录工具版本、源哈希、选择窗口、关键事件、交叉证据与结论置信度，再按保留策略销毁缓存、截图和下载副本。
每次 JMC、插件或运行 JDK 升级，都用固定脱敏录制重跑打开、规则、事件浏览、时间窗口、导出、JMX 拒绝路径和清理。长期指标可关注文件打开失败率、版本不兼容数、规则结论被原始事件推翻的比例、工作区残留和按期销毁率。一个成熟的 JMC 流程，不是规则页全绿，而是任何结论都能回到原始事件、目标身份和业务窗口。
安装与产品能力继续参考 OpenJDK JMC 项目、OpenJDK JMC 仓库的发行说明和 Oracle JMC 9 用户指南。JFR 录制状态不在本文重复，按 JDK Flight Recorder 生产录制手册 执行。