大杀器jstat，再也不怕 JVM 发脾气了

本文链接：https://blog.csdn.net/kingcoding/article/details/107496997

开足码力，码动人生，微信搜索【 程序员大帝 】，关注这个一言不合就开车的的代码界老司机
本文 GitHub上已经收录 https://github.com/BeKingCoding/JavaKing ，一线大厂面试核心知识点、我的联系方式和技术交流群，欢迎Star和完善

前言

上一篇文章《重大事故！线上系统频繁卡死，凶手竟然是 Full GC ？》，咱们通过一个现实的故障讲解了如果 JVM 出现问题，如何快速进行定位与排查。

其中提到了 jstat 这样一个工具，它可以很好地帮助我们了解 JVM 运行情况，轻易地实时显示 JVM 内的 Eden、Survivor、老年代的内存使用情况，还有 Young GC 和 Full GC 的执行次数以及耗时。

通过这些指标，我们可以按照之前的分析过程，判断系统的压力和内存分配是否合理。很多小伙伴看完上篇文章，都要求好好讲讲 jstat，接下来我们就来看看如何使用这个小而强大的工具。

正文

01 jstat -gc [PID]

默认大家的服务器都是Linux，可以通过 jps 命令先获取 Java 进程号，然后通过这个命令就可以显示 JVM 的内存和 GC 情况了。

在这里插入图片描述

命令运行后会告诉我们很多重要的指标，图片比较小，我们就把每一列挨个来解释下：


S0C	From Survivor 区的大小
S1C	To Survivor 区的大小
SOU	From Survivor 区已使用的内存大小
S1U	To Survivor 区已使用的内存大小
EG	Eden 区的大小
EU	Eden 区已使用的内存大小
OC	老年代的大小
OU	老年代已使用的内存大小
MC	方法区（元空间）的大小
MU	方法区（元空间）已使用的内存大小
YGG	系统运行迄今为止的 Young GG 次数
YGGT	Young GC 的耗时
FGC	系统运行迄今为止的 Full GC 次数
FGCT	Full GC 的耗时
GCT	所有 GC 的总耗时

02 如何利用 jstat

其实 jstat -gc 命令基本上可以满足对 JVM 的初步分析了，在得到这么多指标之后，我们还需要对信息进一步加工。

为大家讲述一下，其实在了解 JVM 进程时，我们最想要知道的信息有哪些呢？

（1）Eden区、老年代对象的增大速率

（2）Young GC、Full GC 触发的频率和每次的耗时

（3）每次 Young GC 后有多少对象可以存活下来，又有多少进入了老年代

我们可以遵循一个最基本的原则，那就是合理分配内存空间，尽可能让对象留在年轻代不进入老年代，避免发生频繁的FullGC，这就是对 JVM 好的性能优化了！

03 总结

本文主要是对上几篇内容的补充，希望可以让大家学会 jstat 命令的使用，对我们定位和排查 JVM 相关问题有很大的帮助。

大家完全可以灵活运行 jstat 这个实用的工具，轻而易举的掌控到线上 JVM 运行的详细情况，然后针对 JVM 的具体运行情况去针对性地优化。

有的同学可能来自于比较成熟的大公司，已经有可视化的监控工具，会说无忌，为什么我还要背命令去记这么多参数呢？

针对这个问题，我也没说不可以使用可视化工具，但是告诉大家，一个优秀、合格的工程师，他一定是可以非常灵活的运用各种命令行工具，在命令行就搞定一切的。

所以 jstat 作为一个最简单易用、高效实用的命令行 JVM 监控工具，绝对值得大家掌握。因为每个人的公司情况不一样，万一你的公司不提供各种可视化工具呢？

那么我们就必须从最 low 最原始的命令行工具开始，快速上手使用，定位问题。在理解了本文思想之后，你用任何其他工具，都能轻松的把线上 JVM 的运行情况通过工具提供的数据分析清楚。

《Offer收割机》系列持续更新，也会定期分享互联网常用技术栈相关的文章，GitHub 上已经收录 https://github.com/BeKingCoding/JavaKing ，讲解一线大厂面试要求的核心知识点、并有对标阿里P7级别的成长体系脑图，欢迎加入技术交流群，我们一起有点东西。

在这里插入图片描述