线上GC count突增问题排查及修复记录

一、现象

1、首先是收到系统GC count报警

2、一分钟后，收到系统机器各项指标异常报警：gc count、gc time 、cpu load升高，cpu idle 变低

二、时间线

16:18需求线上操作灰度全量

16:46收到服务GC count突增报警，同时系统GC time/load指标/cpu.idle指标等都出现相应异常

17:08灰度回滚到上一次灰度状态，回滚后观察系统各项指标未恢复

17:12-17:29滚动重启服务，重启后各项指标恢复

三、初步原因分析

3.1 为什么系统收到GC count报警

GC count飚高，导致触发线上 jvm.gc.count 阈值告警

3.2 为什么GC Count会突然增高

怀疑点1：由于需求是异步调用，检查是否由于线程数无限制导致。

结论： RPC 异步配置为默认，netty nio， 默认情况初始连接数为1，最大连接数也为1，采用多路io复用一个连接数即为一个线程，因此不存在线程问题

怀疑点2：由于频繁YGC，但是老年代空间利用率却没有上涨，是否是由于产生了大量的局部变量。

目前已知的可能的大对象就是 TicketPlusModel 对象，同时里面 stockprices 会存储近一年的价格信息。

但是对当时线上 dump 下来的这个对象显示，如果一个 26k，一次调用大概有不到三十个dealId 26k30当时的接口调用qps（30）=22M，不至于YGC

分析发现这个dump文件，在dump之前应该进行过一次full gc， 因此其中局部变量大多都被gc掉了，没有很大的参考价值。需要还原当时场景并dump有价值的堆栈信息

问题复现

通过上述排查未发现根本原因，准备通过捞取当时的请求日志和录制线上流量，压测来复现gc count 报警场景，并dump全量对象进行分析。

现象1：在线程快照中发现所有存活线程的调用链路都在执行一个相同的方法

现象2：在堆栈不可达对象中，发现了大量的SimpleDateFormat，Calendar等日期相关的对象，最终导致GC count增高

通过对比线上dump的文件（左）和复现dump的文件（右）发现

3.3 为什么所有线程都在调用同一段方法&产生大量SimpleDateFormat

代码中存在异常代码逻辑：while 循环跳出逻辑存在漏洞，在特定情况下进入死循环；而在子方法中，创建了 SimpleDateFormat 对象，同时 SimpleDateFormat 对象的创建内部逻辑还会创建 GregorianCalendar 对象等

3.4 为什么进入死循环会导致GC count增高

在死循环逻辑子子方法中，创建了 SimpleDateFormat 对象，同时 SimpleDateFormat 对象的创建内部逻辑还会创建 GregorianCalendar 对象等

因此，由于内存空转速度极快，大量的对象被创建，同时这些对象的生命周期并没有在死循环中，在死循环调用的子方法中。因此每次循环都会产生对应的堆对象同时生命周期结束可以被GC。这也解释了为什么会发生频繁的GC，但是老年代并没有空间占用上涨的趋势，因为这些对象都是瞬间产生，瞬间生命周期就结束掉并被GC。

GC Time 增高是由于 GC Count 增多导致。

结论验证：

对bug代码进行修复：压测开始后（2点30-3点30），并没有继续产生线上同样问题。同时 cpu 和 gc 等指标都在正常的波动范围

3.5 为什么CPU idle变低？

当查询逻辑掉入到死循环逻辑后，由于死循环代码块全为本地内存操作并没有其他rpc等耗时操作，因此cpu空转速度较快，引起cpu load升高和idle的降低。同时频繁的GC 也对cpu性能造成了损耗

3.6 为什么线上回滚后问题没有恢复，需要等到机器重启才恢复正常？

由于某些子线程已经掉入了死循环逻辑，并不会因为回滚发生任何状态的改变，因此上述问题会一直持续到这些线程结束为止也就是重启。

四、问题修复

对线上代码做bug修复，并重新上线

五、经验教训

对于代码中一些循环逻辑如while、for等，需要非常严格的检查跳出逻辑。因为循环逻辑一旦跳出设置存在漏洞很容易发生死循环故障。