大家好，又见面了，我是你们的朋友全栈君。

前言

这个问题应该是 Java 面试中很经常被问到的一个题目，很多人害怕这个题目。

因为大部分人可能在工作中根本遇不到 FGC 频繁的问题，即使从网上背了点答案，心里也不踏实，因为毕竟不是自己亲自接触和解决过。

今天就和大家聊聊面试过程中遇到这个问题，该如何解答。

与面试官的心理博弈

大多数人面试会有一个情况，把面试官想的很“高大”，感觉面试官应该“上知天文下知地理”，自己只是从网上背了个答案，肯定会被看穿，从而导致心虚。

但是大部分事实是，很多面试官也一样没有遇到过这个问题，因为频繁 FGC 本身就是一个很小概率的场景。即使遇到过，大部分其实都是一些很简单的原因。所以，如果充分准备好之后，其实可以更自信一些。

面试时如何解答

下面以我自身为例，谈谈如果我的服务遇到线上环境 FGC 频繁时，我们是如何解决的。

我们的流程我觉得是比较规范的，可以用来做面试答案，也可以用来实际使用。

1、明确分工

这个步骤应该是在事前就已经明确好的，类似于一个故障处理流程规范，这边需要明确出3个主要角色：

1）总指挥

负责故障处理整体指挥的人，例如快速拉起线上/线下会议、通知到系统核心同学，对各同学工作进行分工等等。

该角色一般由主管来担任，或者主管指定的另一个同学。

2）故障恢复小组

负责故障恢复的同学，该部分同学的任务就是让系统以最快的速度恢复正常。

3）故障定位小组

负责故障定位的同学，该部分同学的任务就是定位出问题的根本原因。

大部分同学的回答可能会集中在故障定位中，但其实另外两个角色也是非常重要的，在线上出现问题时，止损永远是放在第一位，其次才是定位。

2、故障恢复

2.1、线上发布导致

查看故障服务近期是否存在上线操作，如果有的话优先采取回滚解决。

分析：该场景应该是最常见的场景，就是刚上的代码存在bug。

2.2、非线上发布导致

1）小面积故障

如果故障机器只是发布在少量机器，例如：某机台机器、某个机房机器、某个地域的机器、某个泳道的机器等等。

此时优先采取禁用服务器解决，禁用前先评估禁用这批机器后是否存在服务容量问题，如果是则先扩容。

分析：该场景一般是代码存在bug，但是该场景的使用频率很低，所以上线时没暴露出来，只是偶尔会被触发到。也是出现概率比较大的场景。

2）大面积故障

如果故障机器不存在共性，这个概率说实话非常非常小，但是如果碰到了，故障恢复小组能做的事情就比较有限了。

因为这个场景大概率是代码存在bug，同时发布时没有被大量触发，而是到现在才被大量触发，需要定位才能根本解决。

此时，故障恢复小组能做的就是使用扩容、重启、限流等手段，来尽量维持服务的运转，同时给故障定位争取时间。

分析：之所以说该场景概率小是因为，分布在大量机器上的故障通常是使用频率高的场景，这部分场景一般在服务发布时就会暴露出问题，而不是发布很久之后。但是这个场景也是确实存在的，但是会比较少。

3、故障定位

故障定位主要是用于应对故障恢复中的最后一个场景，也是将故障恢复和故障定位分成两个小组并行执行的主要原因。

3.1、FGC 能正常回收到内存

通过监控或GC日志，我们能看到每次FGC后都能正常回收到内存，但是内存很快又被占满，导致又出现FGC，从而出现FGC频繁。

这个场景通常可能由于两个原因导致：

1）Eden 区配置太小，导致大量对象直接进入老年代，从而导致老年代快速被占满。

2）业务量较大，特别是在业务高峰期。而当前的服务器配置已经无法满足当前的业务量。

对于这两个原因，代码本身可能没有大问题，优先采取扩容机器，降低单台服务器压力即可解决。

后续则需要重新评估当前服务器的配置是否满足当前的业务量，JVM参数是否存在优化空间等等。

分析：该场景是由于业务量增大没有及时评估或者JVM参数配置存在问题导致的，整体来说，出现的概率较小。

3.2、FGC 不能正常回收到内存

通过监控或GC日志，我们能看到每次FGC后只能回收到很小的空间，甚至回收不到空间，从而出现FGC频繁。

对于这个场景，二话不说，先dump下内存，使用工具看下当前的内存泄漏情况、内存分布情况等等，查看是哪个对象占用了大量内存。具体工具常见的例如 Eclipse MAT，如果公司内部有封装的工具就更好了。

通常查看完内存占用情况，大概率会看到个别对象占用了大量的内存，结合其引用链定位出在代码中的位置。

接着就是根据代码分析问题的严重程度：

如果是小概率触发的场景，大部分请求其实正常，则可以先禁用问题机器，后续上线修复即可。

如果是大概率触发的场景，则查看是否存在降级开关，如果有则优先降级解决，如果没有则只能修改代码，走紧急修复流程。

总结

整体的解决流程其实还是比较简单的，没有太复杂的东西。大多数情况下，用好扩容、禁用、重启这几个常见手段即可解决大部分问题。

个人经验而言，线上频繁FGC问题90%以上是由于开发同学代码存在问题导致的，例如常见的存在死循环、开无界队列等等。以上的问题在dump后，很容易就能定位到根本原因。

而如果遇到诸如依赖的第三方jar存在bug导致的问题，例如Guava、Log4j，这种场景一般是在极端情况下出才会出现，所以一般只会出现在少数机器，禁用即可临时解决，然后后续再慢慢排查。

最后

我是囧辉，一个坚持分享原创技术干货的程序员，如果觉得本文对你有帮助，记得点赞关注，我们下期再见。

推荐阅读

Java 基础高频面试题（2021年最新版）

Java 集合框架高频面试题（2021年最新版）

面试必问的 Spring，你懂了吗？

面试必问的 MySQL，你懂了吗？