FullGC引发的服务宕机问题

现象

测试环境频繁FullGC，导致整个服务停止对外提供服务。
同时使用arthas增强失败，无法attach服务

排查过程

• 调用方/测试反映接口超时，无法正常调用

• 监控发现服务频繁发生fullgc，同时通过jstat命令发现fullgc频率极高，年轻代老年代使用都达到了100%

  jstat -gcutil 1 1000

  

• 利用jmap命令导出堆情况，并使用visualvm查看堆情况。发现char[]占用内存极其之高

  jmap -dump:format=b,file=heapdump 1

  

• 一方面，发现有一个一口气查询了5000多条订单，另一方面发现还有一大堆小对象

• 根据日志与代码，发现了有一个场景下需要去查询用户所有有效的订单，并且会去查询关联的信息（如上图）

• 此时再去查看下当前JVM的基本信息（发现堆特别小）

  / # jinfo -flags 1
  Attaching to process ID 1, please wait...
  Debugger attached successfully.
  Server compiler detected.
  JVM version is 25.291-b10
  Non-default VM flags: -XX:CICompilerCount=2 -XX:InitialHeapSize=33554432 -XX:MaxHeapSize=536870912 -XX:MaxNewSize=178913280 -XX:MinHeapDeltaBytes=196608 -XX:NewSize=11141120 -XX:OldSize=22413312 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps 
  Command line:  -Dfile.encoding=UTF-8 -Dxmiast.ip=xxx.xxx.xxx.xxx -Dxmiast.port=9090 -Dxmiast.token=xxxxxxxx -Dxmiast.projectname=xxxxx -Dxmiast.nodename=xxxxxx -javaagent:/xxxxx.jar

  可以断定：
  当前年轻代无法存下这么多小对象，小对象直接一口气放入了老年代。同时老年代也存不下这么多数据，于是需要进行fullgc。而fullgc是STW的，所以服务直接停止对外提供服务，造成上述问题

  解决思路

• 一方面，因为业务场景原因，一个用户有效订单数理论上不超过20条，当前数据为压测时数据，可忽略。（手动删除非法数据）

• 另一方面，512m的jvm堆内存属实有些小，此处将整个堆内存提高

  后续一些优化的思考

  因为是一个面向C端的系统，假如存在吞吐量问题，可以考虑将年轻代比例调高（C端应用特点：接口时间短但并发高）