jmap -histo（JDK 8 默认）和 jmap -dump:live 均会触发 Stop-The-World；前者在 JDK 8 中几乎必触发 Full GC，后者强制堆遍历与序列化，大堆下停顿可达 10–30 秒。
哪些 jmap 操作会触发全局停顿
jmap -histo 和 jmap -dump 是最常误用的高危命令。前者在 JDK 8 中默认触发 Full GC（除非加 -F 且目标 JVM 未响应），后者无论是否加 -F，只要执行 jmap -dump:live,format=b,file=heap.hprof <pid></pid>，就会强制进行一次完整的堆遍历和序列化——这必然引发 Stop-The-World。
容易踩的坑：
- 线上直接跑
jmap -dump:live查内存泄漏？等于主动给服务“打麻醉针”，尤其在大堆（>4G）场景下，停顿可能长达 10–30 秒 -
jmap -histo在 JDK 17+ 默认不触发 GC，但若目标 JVM 已处于 GC 压力下，仍可能加剧卡顿；JDK 8 下几乎必触发 Full GC - 容器环境里用
jmap还可能因 cgroup 内存限制被 OS 杀死，而非 JVM 自身报错
jstack 在什么情况下不是“安全”的
多数人以为 jstack 是纯读操作、零停顿，其实不然。当 JVM 正在执行 safepoint 操作（如 GC、类加载、JIT 编译等）时，jstack 会等待所有线程进入 safepoint —— 如果此时有线程长时间无法到达（比如在执行 JNI 本地方法、自旋锁或长耗时 IO），jstack 就会卡住，而等待过程本身会让 JVM 暂停其他所有 Java 线程。
典型表现：
- 执行
jstack <pid></pid>后终端无响应，几秒到几十秒不返回 -
jstack -l（带锁信息）比普通jstack更容易卡，因需额外采集 Monitor 状态 - 在虚拟线程（JDK 21+）密集场景下，
jstack输出量爆炸，可能导致终端缓冲区溢出或解析延迟，间接拖慢诊断节奏
为什么 jcmd VM.native_memory 要慎用
jcmd <pid> VM.native_memory</pid> 看似轻量，但它依赖 JVM 的 NMT（Native Memory Tracking）功能。如果启动时没加 -XX:NativeMemoryTracking=summary 或 =detail，运行时调用该命令会失败；而即使已开启，NMT 本身就有约 5–10% 的性能开销，且每次采集需遍历所有 native 分配器——在高并发 Netty 或 DirectByteBuffer 泛滥的服务中，这个操作可能引发短暂但可测的调度延迟。
更隐蔽的问题：
- NMT 开启后，
jcmd VM.native_memory的首次调用会触发内部缓存重建，延迟明显高于后续调用 - 容器环境下，若 JVM 运行在非 root 用户下，NMT 可能因权限不足无法读取部分 mmap 区域，返回不完整结果却无明确错误提示
- 它不会导致 STW，但可能让本已紧张的 CPU 调度雪上加霜，尤其在
top -Hp已看到多个线程 95%+ 占用时
Arthas 的 thread -n 和 watch 也有代价
Arthas 虽号称“无侵入”，但其动态字节码增强机制本质是运行时修改 class 字节码并重定义类（Instrumentation.redefineClasses）。这意味着：
-
thread -n 10本身不 STW，但如果目标线程正在执行被增强过的方法，可能触发 JIT deopt，带来微秒级抖动 -
watch *Class method * params这类表达式监控，在高 QPS 接口上启用等于给每个调用加一层 if 判断 + 参数序列化，极易引发 CPU 突增 - 在 JDK 17+ 使用
trace命令追踪深度调用链时，若匹配到大量java.lang.String::concat或StringBuilder::append，Arthas 会为每个调用生成 trace event，内存和 CPU 开销陡增
真正容易被忽略的是：这些操作本身不 crash JVM，但会把一个原本只是“慢”的问题，推到“不可用”边缘——尤其当它叠加在 GC 压力、CPU 饱和或网络超时之上时。
