开足码力,码动人生,微信搜索【 程序员大帝 】,关注这个一言不合就开车的的代码界老司机
本文 GitHub上已经收录 https://github.com/BeKingCoding/JavaKing , 一线大厂面试核心知识点、我的联系方式和技术交流群,欢迎Star和完善
上一篇文章《重大事故!线上系统频繁卡死,凶手竟然是 Full GC ?》,咱们通过一个现实的故障讲解了如果 JVM 出现问题,如何快速进行定位与排查。
其中提到了 jstat 这样一个工具,它可以很好地帮助我们了解 JVM 运行情况,轻易地实时显示 JVM 内的 Eden、Survivor、老年代的内存使用情况,还有 Young GC 和 Full GC 的执行次数以及耗时。
通过这些指标,我们可以按照之前的分析过程,判断系统的压力和内存分配是否合理。很多小伙伴看完上篇文章,都要求好好讲讲 jstat,接下来我们就来看看如何使用这个小而强大的工具。
默认大家的服务器都是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 的总耗时 |
其实 jstat -gc 命令基本上可以满足对 JVM 的初步分析了,在得到这么多指标之后,我们还需要对信息进一步加工。
为大家讲述一下,其实在了解 JVM 进程时,我们最想要知道的信息有哪些呢?
(1)Eden区、老年代对象的增大速率
(2)Young GC、Full GC 触发的频率和每次的耗时
(3)每次 Young GC 后有多少对象可以存活下来,又有多少进入了老年代
我们可以遵循一个最基本的原则,那就是合理分配内存空间,尽可能让对象留在年轻代不进入老年代,避免发生频繁的FullGC,这就是对 JVM 好的性能优化了!
本文主要是对上几篇内容的补充,希望可以让大家学会 jstat 命令的使用,对我们定位和排查 JVM 相关问题有很大的帮助。
大家完全可以灵活运行 jstat 这个实用的工具,轻而易举的掌控到线上 JVM 运行的详细情况,然后针对 JVM 的具体运行情况去针对性地优化。
有的同学可能来自于比较成熟的大公司,已经有可视化的监控工具,会说无忌,为什么我还要背命令去记这么多参数呢?
针对这个问题,我也没说不可以使用可视化工具,但是告诉大家,一个优秀、合格的工程师,他一定是可以非常灵活的运用各种命令行工具,在命令行就搞定 一切的。
所以 jstat 作为一个最简单易用、高效实用的命令行 JVM 监控工具,绝对值得大家掌握。因为每个人的公司情况不一样,万一你的公司不提供各种可视化工具呢?
那么我们就必须从最 low 最原始的命令行工具开始,快速上手使用,定位问题。在理解了本文思想之后,你用任何其他工具,都能轻松的把线上 JVM 的运行情况通过工具提供的数据分析清楚。
《Offer收割机》系列持续更新,也会定期分享互联网常用技术栈相关的文章,GitHub 上已经收录 https://github.com/BeKingCoding/JavaKing ,讲解一线大厂面试要求的核心知识点、并有对标阿里P7级别的成长体系脑图,欢迎加入技术交流群,我们一起有点东西。
我是一言不合就开车的代码界老司机无忌。创作不易,各位的支持和认可,就是我创作的最大动力,我们下篇文章见!