JVM实战(26)——SystemGC

作者简介:大家好,我是smart哥,前中兴通讯、美团架构师,现某互联网公司CTO

联系qq:184480602,加我进群,大家一起学习,一起进步,一起对抗互联网寒冬

学习必须往深处挖,挖的越深,基础越扎实!

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

一、案例背景

本章将介绍一个因为程序员同学不懂JVM的GC机制而导致的系统卡死的案例。

首先,这个系统上线之后,平时都还算正常,结果有一次大促活动的时候,系统直接卡死不动了。这个时候,我们首先想到的是可不可能是因为频繁Full GC导致Stop the World,正常工作线程无法执行。

1.1 存在问题

我们通过jstat进行分析,发现JVM中各个区域的内存使用都正常,新生代对象增长也不快,老年代也才使用了10%左右的空间,永久代也就使用了20%。

但是,jstat日志显示,JVM竟然每秒执行一次Full GC,每次都耗时几百毫秒。

既然Java堆内存都正常,为啥会频繁Full GC?这是我们立马想到,是不是有开发人员在代码中写了System.gc()这种代码,结果通过代码走查,发现确实如此。

二、System.gc方法

2.1 优化前

开发同学写System.gc()这行代码的思路是这样的:某段代码会一下子加载了好多数据,处理完成后这批数据就不用了,占用太多内存,所以就干脆显示调用GC方法把它们回收掉吧。

结果在平时没什么问题,因为流量很低。但是大促期间,访问量很高,System.gc()方法被频繁调用,因此频繁触发Full GC,从而导致了上述问题。

2.2 优化后

针对这个问题,解决方案就是 禁止在代码中显式调用System.gc()方法 ,GC完全交由JVM自己去处理,可以通过配置JVM参数-XX:+DisableExplicitGC来强制屏蔽。

三、总结

针对本章案例中的问题,我们平时自己写代码时,不要自己去调用System.gc()方法随便触发GC,一方面可以通过在JVM参数中加入-XX:+DisableExplicitGC显示禁止代码中的GC操作,另一方面也要加强对开发人员的JVM相关知识的培训。

你可能感兴趣的:(jvm专题,jvm)