Java Diagnostics 是一个面向 JVM 应用的运行时诊断技能，核心原则是“从症状出发，选择能回答该问题的最轻量工具”。它不提供新的诊断程序，而是把 JDK 自带工具与常用第三方工具组织成一套可执行的排查流程。
用途 该技能用于排查 JVM 应用在生产或测试环境中的运行时问题，包括高 CPU、内存泄漏与 OOM、启动缓慢、死锁与线程饥饿、GC 暂停、原生内存增长、请求变慢以及 JVM 崩溃或挂起等。它强调先精确描述症状（发生时间、频率、自哪次变更起、JDK 版本、容器限制），再选择工具。
主要能力 技能覆盖的工具包括：jps、jcmd、jstack、jmap、jstat、JFR（JDK Flight Recorder）、GC 日志、async-profiler、Native Memory Tracking（NMT）以及 jhsdb。它提供一张决策表，把每种症状映射到第一步操作、后续步骤和对应参考文档。例如高 CPU 先用三次线程转储加 top -H 映射热点原生线程，再用 JFR 或 async-profiler 生成 CPU 火焰图；内存泄漏先用 jstat -gcutil 和两次间隔数分钟的 GC.class_histogram -all=true，再考虑堆转储加 Eclipse MAT 或 JFR OldObjectSample。
权限分层 技能把命令分为三个权限层级。第一层为只读，包括 jps -l、jcmd 的 help/VM.version/VM.flags/Thread.print、jstat、jstack 以及读取日志，可在说明确切命令后运行；但类直方图（GC.class_histogram、jmap -histo、jmap -histo:live）不属于第一层，因为它们在安全点执行堆检查，大堆上可能暂停应用线程，应视为第二层。第二层为录制/附加，包括 JFR、async-profiler、NMT、启用 GC 日志，需要用户同意，并说明持续时间和预期开销（JFR 默认配置约 1-2%，NMT 摘要约 5-10%，细节更高）。第三层为侵入/敏感，包括堆转储、jhsdb、打印 JVM 参数或系统属性的命令、带 suspend 的 JDWP 以及任何生产环境操作，需要明确同意、指定目标路径、检查磁盘空间并说明暂停时间；堆转储可能包含密码、令牌和个人数据，不应分享或上传，应在本地分析后删除。技能明确要求：除非用户明确指示，否则不要对生产环境运行第二层或第三层命令；诊断工具应以与目标 JVM 相同的操作系统用户运行；优先在开发或预发环境复现。
使用方式 技能建议的工作流是：精确捕获症状；选择所需层级，说明命令、开销和输出位置，第二、三层需取得同意；将数据采集到带时间戳的专用目录，优先多次采样；从数据形成假设，再用第二个来源确认（例如线程转储加火焰图）；修复后用相同方法复测，并清理转储和录制文件。技能还建议从 jps/jcmd 基础命令开始，先识别目标 JVM 并确认 JDK 版本。
应用层补充 技能指出 JDK 工具看到的是 JVM，而某些问题（哪个端点、哪条 SQL、哪个 bean）在应用层更容易回答。可选方案包括 Spring Boot Actuator 和 Quarkus Dev UI / Micrometer 指标，以及本地开发者控制台 BootUI（https://github.com/jdubois/boot-ui ，https://www.julien-dubois.com/boot-ui/），其技能可通过 gh skill install jdubois/boot-ui skills/bootui 安装。使用 BootUI 前需征得用户同意，仅限本地/开发配置，不得暴露在网络中，也不得在生产环境启用其堆转储、线程转储端点或 MCP 服务器，并应先阅读其 README 确认支持的版本与能力。
适用场景与限制 该技能适用于使用 JDK 工具排查 JVM 运行时问题的开发与运维场景，尤其适合需要按风险分级、谨慎操作生产环境的团队。限制方面：技能本身不替代官方文档，建议以所用 JDK 版本的官方文档为准；第二、三层命令有性能开销或敏感数据风险，必须取得同意；堆转储的脱敏并不可靠；容器环境下的附加工具、-XX:MaxRAMPercentage 和 cgroup 内存限制需参考其容器章节；基于调试器的调查则参考 java-debugging 技能。