1. 从一次线上排查说起为什么我们需要jstat那天晚上系统监控突然告警一个核心服务的GC时间飙升接口响应时间从几十毫秒直接拉到了秒级。登录服务器第一反应是看JVM堆内存使用情况。top命令显示Java进程CPU占用不高但内存使用量RES却在一个较高的水平徘徊。这时候光看top或者ps已经不够了我们需要知道堆内存内部到底发生了什么是新生代满了在频繁Minor GC还是老年代快满了即将触发耗时的Full GC亦或是元空间Metaspace在泄漏此时jstat就成了手边最锋利的那把“手术刀”。它不需要开启JMX等远程管理端口无需修改JVM启动参数直接通过进程IDPID就能实时窥探JVM内部各种内存池和垃圾收集器的运行状态。对于线上问题的紧急定位和日常的性能瓶颈分析jstat提供的是一种轻量级、低侵入的观测能力。很多Java开发者可能对jps,jstack,jmap更熟悉但jstat在监控GC行为和内存动态变化方面有着不可替代的作用。它输出的那些看似简单的数字和百分比背后是理解JVM内存世界的一扇窗。简单来说jstatJava Virtual Machine Statistics Monitoring Tool是JDK自带的一个命令行工具用于监控JVM的各种运行时统计信息尤其是与垃圾回收GC和内存池Heap/Non-Heap相关的指标。它通过JVM内置的PerfData共享内存区域获取数据因此开销极低非常适合生产环境下的持续监控和问题排查。2. jstat命令的核心语法与常用选项解读jstat命令的基本格式如下jstat [generalOption] [outputOptions] vmid [interval [count]]这个结构看起来简单但每个部分都藏着细节。我们来逐一拆解。2.1 命令参数深度解析vmid(Virtual Machine Identifier): 虚拟机标识符。这是最重要的参数它告诉jstat你要监控哪个JVM进程。在本地它通常就是Java进程的PID进程ID。你可以用jps -l命令快速列出所有Java进程及其PID。对于远程JVM格式为[protocol:][//]lvmid[hostname[:port]/servername]但远程监控需要JVM开启PerfData共享内存的远程访问通过-XX:PerfDataSaveToFile和-Dcom.sun.management.jmxremote*等参数实践中较少直接使用jstat进行远程监控更多用JMX。interval与count: 采样间隔与次数。interval: 连续输出之间的时间间隔单位是毫秒ms。例如1000表示每秒采样一次。count: 打印多少次采样数据。如果不指定count只指定了intervaljstat会持续输出直到你手动中断CtrlC。组合使用场景jstat -gc 12345 1000 5: 对PID为12345的进程每秒采集一次GC数据共采集5次后停止。这适合抓取一个时间片段的数据进行分析。jstat -gcutil 12345 1000: 对PID为12345的进程每秒持续输出GC概览用于实时观察趋势。outputOptions: 输出选项。这部分决定了你看到什么样的数据是jstat的灵魂。它由一个-开头后跟一个或多个选项字符。主要分为两大类常规选项generalOption和统计选项statOption。但通常我们直接使用统计选项。2.2 最常用的统计选项-optionsjstat -options可以列出当前JVM支持的所有监控选项。不同版本的JDK和不同的垃圾收集器支持的选项可能略有不同。以下是最核心、最常用的几个-gc垃圾回收统计的“全景图”这是最全面的GC统计视图输出各内存区域的容量Capacity、使用量Used和上次GC后的容量GC后容量但通常与Capacity相同或略小。单位是KB。jstat -gc pid输出列包括S0C,S1C,S0U,S1U,EC,EU,OC,OU,MC,MU,CCSC,CCSU,YGC,YGCT,FGC,FGCT,GCT。S0C, S1C: Survivor 0/1区容量 (Capacity)EC, EU: Eden区容量和使用量 (Used)OC, OU: 老年代容量和使用量MC, MU: 元空间Metaspace容量和使用量 (JDK 8)CCSC, CCSU: 压缩类空间Compressed Class Space容量和使用量YGC, YGCT: Young GCMinor GC的次数和总耗时FGC, FGCT: Full GC的次数和总耗时GCT: GC总耗时什么时候用当你想了解JVM内存的绝对使用量、各区域大小配置是否合理以及GC发生的频率和累积耗时。-gcutil垃圾回收统计的“百分比仪表盘”这是使用频率最高的选项。它显示各内存区域使用量占总容量的百分比以及GC次数和时间的摘要。信息高度浓缩一眼就能看出“水位”。jstat -gcutil pid 1000输出列包括S0,S1,E,O,M,CCS,YGC,YGCT,FGC,FGCT,GCT。S0, S1, E, O, M: 分别是Survivor0, Survivor1, Eden, Old, Metaspace区的使用百分比。关键看O老年代和M元空间如果O长时间高于70-80%或者持续增长可能预示老年代对象过多或存在内存泄漏有触发Full GC的风险。如果M持续增长可能意味着类加载器泄漏或动态生成类过多。什么时候用实时监控内存“水位”和GC频率的首选。-gcutil 1000是线上问题排查的经典组合。-gccapacity各内存池的容量信息显示各内存区域当前容量、最小容量、最大容量等。有助于了解JVM内存的动态伸缩如元空间、堆的弹性扩展。jstat -gccapacity pid输出包括NGCMN,NGCMX,NGC,OGCMN,OGCMX,OGC等分别对应新生代、老年代的最小、最大、当前容量。-gcnew/-gcold新生代/老年代详情-gcnew: 专注于新生代的统计包括Eden和Survivor区的详细分配、晋升情况。-gcold: 专注于老年代和元空间的统计。 当你的问题可能局限于某个代时用这两个命令可以获取更聚焦的信息。-printcompilationJVM编译统计显示JVM HotSpot编译器编译方法的信息。包括编译完成的方法数、字节码大小等。在分析JIT编译行为时有用。注意jstat的数据来源于JVM的PerfData如果JVM进程是以-XX:PerfDisableSharedMem参数启动的或者/tmp/hsperfdata_user/目录下的perfdata文件被删除或无法访问jstat将无法工作并报错“not found”。3. 实战演练通过jstat诊断典型JVM问题光看命令说明不够直观我们结合几个具体的场景看看如何让jstat的输出“说话”。3.1 场景一频繁Full GC导致服务卡顿现象应用间歇性卡顿监控显示接口耗时毛刺。排查步骤找到应用PIDjps -l或ps -ef | grep java。使用jstat -gcutil pid 1000持续观察。S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 96.88 25.50 85.66 95.12 91.88 200 5.123 15 12.456 17.579 0.00 96.88 48.90 85.66 95.12 91.88 200 5.123 15 12.456 17.579 0.00 96.88 72.31 85.66 95.12 91.88 200 5.123 15 12.456 17.579 0.00 96.88 98.45 85.66 95.12 91.88 201 5.145 15 12.456 17.601 0.00 0.00 6.67 85.66 95.12 91.88 202 5.167 15 12.456 17.623 0.00 0.00 28.90 98.77 95.12 91.88 202 5.167 16 15.123 20.290解读输出观察O老年代列一开始是85.66%水位已经很高。观察FGCFull GC次数和FGCTFull GC总时间在第六行FGC从15增加到16FGCT从12.456s猛增到15.123s。这意味着刚刚发生了一次Full GC耗时约2.667秒15.123-12.456。同时O列在Full GC后从98.77%下降虽然这里下一行没显示下降后的值但理论上应该下降EEden区也从98.45%在Young GC后下降。关键发现老年代(O)使用率长期居高不下85%且很快被填满达到98.77%触发了耗时的Full GC。这是典型的老年代内存不足或存在内存泄漏的迹象。下一步行动结合jmap -histo:live pid或jmap -dump:live,formatb,fileheap.hprof pid生成堆转储用MAT或JProfiler分析老年代中的大对象和对象引用链查找泄漏点。检查JVM参数是否老年代(-Xmx)设置过小或者新生代(-Xmn)比例过大导致对象过早晋升。3.2 场景二元空间Metaspace泄漏现象应用运行一段时间后物理内存占用持续增长但堆内存使用正常。排查步骤同样使用jstat -gcutil pid 1000观察。S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 0.00 35.67 45.23 45.67 40.12 50 1.234 2 0.456 1.690 0.00 0.00 65.12 45.23 56.89 48.90 50 1.234 2 0.456 1.690 0.00 0.00 12.34 45.23 68.45 57.34 51 1.256 2 0.456 1.712 ... (时间推移) 0.00 0.00 22.45 45.23 99.88 98.76 60 1.567 2 0.456 2.023 0.00 0.00 22.45 45.23 99.88 98.76 60 1.567 3 3.456 5.023解读输出重点看MMetaspace和CCSCompressed Class Space列。可以看到M从45.67%开始在几次采样间持续增长直到99.88%。当M达到接近100%时触发了一次Full GCFGC从2变为3FGCT大幅增加。JVM会尝试在Full GC中卸载不再使用的类来回收元空间但如果类加载器存在泄漏卸载会失败。Full GC后M的使用率可能没有明显下降这里假设还是99.88%这意味着元空间无法被有效回收。根因与解决元空间存储类的元数据。持续增长通常意味着应用在动态生成类如大量使用CGLib/ASM/Javassist进行动态代理、Groovy脚本引擎、JSP编译等并且生成的类没有被及时卸载。常见罪魁祸首Spring AOP的CGLib代理如果未正确配置proxyTargetClass或作用域、热部署框架、自定义类加载器管理不当。解决方向检查并优化动态类生成逻辑增加缓存或复用。确保类加载器如Web应用的WebAppClassLoader在应用停止如Tomcat reload时能被正常回收。可以适当调大元空间最大值-XX:MaxMetaspaceSize作为临时缓解但根本上是解决泄漏。3.3 场景三Young GC频繁且耗时长现象应用吞吐量不高CPU资源消耗较多。排查步骤使用jstat -gc pid 1000观察关注新生代相关列和YGC/YGCT。S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT5120.0 5120.0 0.0 0.0 33280.0 33280.0 87424.0 12345.6 9728.0 8567.1 1152.0 987.6 150 45.750 5 1.234 46.984 5120.0 5120.0 0.0 0.0 33280.0 33280.0 87424.0 12345.6 9728.0 8567.1 1152.0 987.6 151 45.900 5 1.234 47.134 5120.0 5120.0 0.0 5120.0 33280.0 0.0 87424.0 17345.6 9728.0 8567.1 1152.0 987.6 152 46.120 5 1.234 47.354 2.解读输出 *EC/EU: Eden区容量为33280KB。可以看到EU在第二行是满的33280.0第三行在YGC后变为0.0同时S1U从0.0变为5120.0存活对象晋升到Survivor1区OU老年代使用量也从12345.6增加到17345.6可能有对象晋升到老年代。 *YGC/YGCT: Young GC次数从151增加到152耗时增加了0.220秒46.120 - 45.900。平均每次Young GC耗时约0.22秒这个时间对于频繁的Minor GC来说可能偏长。 *计算关键指标 *Young GC频率观察YGC的增长速度。如果1秒内YGC增加好几次说明Eden区分配太快对象生命周期短GC频繁。 *Young GC平均耗时YGCT / YGC。本例中45.750 / 150 ≈ 0.305秒。如果这个值很大如0.1秒意味着每次Young GC停顿时间较长。 *对象晋升率粗略估算看每次YGC后OU老年代使用量的增长。增长过快意味着很多对象“逃过”了Survivor区的多次GC直接进入了老年代可能导致老年代过快填满引发Full GC。 3.优化思路 *如果频率过高考虑增大新生代尤其是Eden区的大小-Xmn或-XX:NewRatio让对象在Eden区停留更久减少GC次数。但注意单次GC时间可能变长。 *如果单次耗时过长 * 检查Survivor区S0C/S1C是否过小导致对象复制开销大。可以适当调整-XX:SurvivorRatio。 * 检查是否存在大量“朝生夕死”的大对象直接分配在老年代通过-XX:PretenureSizeThreshold参数可以观察但默认值较大。考虑优化代码避免创建不必要的中间大对象。 *如果晋升率过高检查-XX:MaxTenuringThreshold晋升年龄阈值是否设置过小。可以尝试增大该值让对象在Survivor区多“熬”几轮GC。同时检查Survivor区空间是否充足。4. jstat的局限性、进阶技巧与工具协同jstat虽然强大但并非万能。清楚它的边界并知道何时该切换到其他工具是资深工程师的必备技能。4.1 jstat的局限性历史数据缺失jstat只提供从JVM启动到当前时刻的累积数据或瞬时快照无法回溯查看历史某一时刻的详细状态。对于分析已经发生过的问题如果当时没有监控jstat无能为力。无对象级信息它告诉你内存池用了多少但不告诉你里面具体是哪些对象。无法定位是哪个类的实例、哪个数据结构占用了大量内存。这是jstat与jmap/MAT等堆分析工具的核心区别。依赖PerfData如前所述如果PerfData被禁用或损坏jstat失效。输出为纯文本对于长期趋势分析需要自己编写脚本采集jstat输出并存储、绘图不如专业的APM应用性能监控系统直观。4.2 进阶使用技巧定时采集与可视化可以写一个简单的Shell脚本定期执行jstat并将输出重定向到文件然后用PythonPandasMatplotlib或Excel进行解析和绘图观察内存和GC的趋势。# 每5秒采集一次gcutil数据共采集100次保存到文件 jstat -gcutil pid 5000 100 gc_log.txt结合其他命令快速定位# 1. 找到最耗CPU/内存的Java进程 top -c | grep java # 2. 获取该进程的PID并用jstat快速看一眼GC情况 jstat -gcutil pid_from_top 2000 3理解不同GC收集器的输出差异使用G1 GC时-gc选项的输出列会和Parallel Scavenge/CMS有所不同例如会有GCT分区信息。在使用前最好先用java -XX:PrintCommandLineFlags -version确认一下当前JVM使用的垃圾收集器。4.3 与jstat协同的JVM排查工具链jstat通常是JVM问题排查链条中的第一环用于快速定位问题方向。jps: 先用它来定位Java进程PID。jstat: 如上所述用于初步判断是GC问题、内存泄漏问题还是元空间问题。jstack: 如果jstat发现GC频繁且耗时但CPU不高可能是线程阻塞或死锁。用jstack pid或jstack -l pid抓取线程转储分析线程状态。jmap: 当jstat强烈暗示堆内存或元空间有问题时使用jmap进行深度诊断。jmap -histo:live pid: 查看堆中存活对象的直方图快速找出占用内存最多的类。jmap -dump:live,formatb,fileheap.hprof pid: 生成堆转储文件用于后续在MAT、JProfiler等图形化工具中进行泄漏点根因分析。jcmd: JDK 7的“瑞士军刀”功能覆盖了上述很多命令。例如jcmd pid GC.heap_info可以查看堆信息jcmd pid VM.native_memory可以查看更详细的本机内存包括元空间使用情况。jcmd pid help可以列出所有支持的命令。一个典型的排查流程可能是服务报警 -top/jps找到PID -jstat -gcutil观察内存水位和GC频率 - 怀疑内存泄漏 -jmap -histo:live查看大对象 - 确认可疑类 -jmap -dump生成堆转储 - 用MAT分析引用链找到泄漏根源。掌握jstat意味着你拥有了在终端里实时感知JVM生命体征的能力。它输出的每一行数字都是JVM向你发出的信号。结合对内存模型和GC原理的理解你就能从这些信号中诊断出性能瓶颈的症结所在。它可能不是最强大的工具但一定是最高效、最便捷的入门钥匙。下次遇到JVM性能问题时别急着重启先打开终端输入jstat -gcutil pid 1000看看你的JVM到底在经历什么。