jstat 通过 -gc 等选项实时监控 gc 频率与堆内存分布，推荐 jstat -gc 1000 5 查看 ygct/fgct；s0c/s1c 为 0 属正常动态调整；eu 持续 >90% 且 ygc 频繁需先分析对象生命周期。
如何用 jstat 实时查看 GC 频率和堆内存分布
jstat 是 JVM 调优最轻量、最常驻的工具，不依赖 JMX、无需开启额外参数（JDK 8+ 默认可用），适合在生产环境快速判断 GC 压力。
关键在于选对选项和间隔：频繁 Young GC 看 -gc，怀疑元空间泄漏用 -gcmetacapacity，长期运行服务建议加 -t 打印时间戳便于比对。
-
jstat -gc <pid> 1000 5</pid>：每秒输出一次 GC 统计，共 5 行，重点关注YGCT（Young GC 总耗时）和FGCT（Full GC 次数）是否突增 - JDK 8 中
S0C/S1C持续为 0？可能是 UseParallelGC 或 UseG1GC 下 Survivor 区动态调整，不代表异常 - 如果
EU（Eden 使用量）长期 >90% 且YGC频繁，说明 Young 区偏小或对象晋升过快，不是立刻调-Xmn，先确认对象生命周期是否合理
为什么 jstack 抓到的线程状态里 BLOCKED 不等于死锁
jstack <pid></pid> 输出中大量线程卡在 java.lang.Thread.State: BLOCKED (on object monitor)，只是表示在争抢 synchronized 锁，未必是瓶颈。真正要盯的是锁持有者是否长期不释放，以及是否形成环路。
- 用
jstack -l <pid></pid>可显示锁 ID 和持有者线程名，配合grep -A 10 -B 5 "locked "快速定位谁持有了哪个锁 - 若发现多个线程反复在同一个
java.util.HashMap上 BLOCKED，大概率是并发修改导致 resize 死循环（JDK 7）或长时锁竞争（JDK 8+），应换ConcurrentHashMap -
jstack无法捕获 native 方法阻塞（如socketRead0），这类线程显示RUNNABLE却不干活，需结合top -H -p <pid></pid>看具体 LWP CPU/等待状态
jmap 生成堆转储前必须确认的三件事
直接执行 jmap -dump:format=b,file=heap.hprof <pid></pid> 在大堆（>4G）上可能引发长时间 STW，甚至触发 OOM Killer 杀进程。不是所有场景都该 dump。
立即学习“Java免费学习笔记（深入）”；
- 先用
jmap -histo <pid></pid>看类实例数量TOP 20，若byte[]、char[]或某业务 VO 实例数异常高，再决定是否 dump - 避免在高峰期执行；JDK 8u262+ 支持
jmap -dump:format=b,file=heap.hprof,live <pid></pid>的live参数，可只导出存活对象，减小文件体积和暂停时间 - 导出后别直接用 Eclipse MAT 打开超大文件（>2G），先用
jhat或jdk.jfr配合事件过滤缩小分析范围，或者用jmap -dump+arthas memory做增量对比
jinfo 修改运行时参数的实际限制有哪些
jinfo -flag +PrintGCDetails <pid></pid> 这类操作看似方便，但仅对部分 boolean 和 manageable 级别参数生效，很多关键参数（如 -Xms、-XX:MaxMetaspaceSize）根本无法动态调整。
- 可动态修改的典型参数只有：
PrintGCDetails、HeapDumpBeforeFullGC、UseG1GC（仅限从 Parallel 切到 G1，反之不行）等极少数 -
jinfo -sysprops <pid></pid>能看到系统属性，但修改（jinfo -sysprop key=value）只影响当前 JVM 进程的System.getProperty()，不影响已加载类的行为逻辑 - 想改 GC 类型或堆大小？必须重启。试图用
jinfo强行覆盖只会报Not able to signo process或静默失败——JVM 启动后这些内存布局已固化
真正容易被忽略的是：所有这些命令行工具依赖 tools.jar（JDK 提供），但 OpenJDK 11+ 已移除该 jar，jstat/jstack 等仍可用，因为它们被重构进 libjvm.so；而 jinfo 在某些精简版 JRE 中可能根本不存在。
