jcmd生产诊断核心是“快、轻、稳”：不触发stw、无显著开销、无需重启；需用jcmd -l精准查pid，启用nmt后用vm.native_memory summary查堆外内存隐患，搭配thread.print和gc.class_histogram轻量验证，严禁使用gc.run、gc.heap_dump及常驻detail模式。
在生产环境中用 jcmd 做性能诊断，核心是“快、轻、稳”——不触发 STW、不增显著开销、不依赖重启。它本身是 JVM 内置通道，只要进程在跑、NMT 已启用、权限匹配，就能秒级获取关键指标。
先精准定位目标进程
别靠 ps aux | grep java 猜 PID，容易误操作：
- 执行 jcmd -l，输出格式为 PID 主类名或 jar 路径（如
12345 /opt/app.jar），准确过滤掉 shell 包装脚本或非 JVM 进程 - 若只显示数字或
sun.tools.jcmd.JCmd，说明主类被混淆或用了自定义 Launcher，可查cat /proc/12345/cmdline看真实启动命令 - 容器中运行时，确保
/tmp可写、/proc已挂载，否则jcmd -l可能为空
查内存隐患：聚焦 native 内存三类高危信号
堆内对象暴增通常有日志或监控告警，而堆外泄漏更隐蔽。重点看 VM.native_memory summary：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 先确认已启用：
jcmd 12345 VM.native_memory summary，若报 Native memory tracking is not enabled，需重启加-XX:NativeMemoryTracking=summary - 重点关注三模块持续增长：[thread]（线程数失控）、[class]（类加载器泄漏，常见于热部署）、[internal]（DirectByteBuffer 积压、JIT 缓存膨胀）
- 该命令毫秒返回，无 GC 开销，适合高频巡检；如需调用栈才用
detail，但仅限低峰期临时启用
查线程与对象分布：轻量交叉验证
单看 NMT 不够，需搭配其他低开销命令快速佐证：
-
Thread.print：比
jstack更稳定，能捕获卡在IN_NATIVE的线程；加-l参数可看锁详情，搜VirtualThread或carrier=null快速定位挂起虚拟线程 -
GC.class_histogram：秒出存活对象 TOP 20（按字节数倒序），一眼识别某类实例暴增（如
ByteBuf、FutureTask）；注意它会触发 Full GC，高负载服务慎用；替代方案是VM.class_hierarchy（不触发 GC） -
VM.flags -all 和 VM.system_properties：确认
-Xmx、-XX:+UseG1GC、spring.profiles.active等关键参数是否符合预期，避免配置漂移
生产环境必须避开的雷区
有些命令看似有用，但在生产中属于高风险操作：
- 禁用
GC.run和GC.heap_dump——前者强制 Full GC，后者可能长时间暂停应用 - 禁用
VM.native_memory detail常驻开启——性能开销达 5–10%，只在问题复现时临时启用，排查完可用VM.native_memory shutdown关闭（无需重启） - 避免用
sudo jcmd切用户执行——生产环境应以应用用户身份操作，权限不足时优先检查-XX:+DisableAttachMechanism是否被启用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
