GC/OOM问题处理思路

1. 原则
   先止损，再分析。如果是灰度阶段，则直接回滚代码，保留一台留作分析；如果是全量阶段个别机器偶发，则禁用该机器。
2. 流程
   保护现场（禁用机器）-> 拉取堆转储文件以及通过流量监控判断可能的问题接口 -> 堆转储文件分析（使用MAT或JProfiler等工具）-> 结合代码确认问题 -> 修复代码或调整jvm配置(-XX:+HeapDumpOnOutOfMemoryError)并上线 -> 观测上线后机器指标（gc-time、gc-count、olggen-used-percent)
3. 问题分类

• GC问题
  • youngGC频繁
    youngGC的正常频率应该是1分钟10次左右。可以考虑增大年轻代的大小
  • fullGC频繁
    fullGC的正常频率应该是一天一次左右。如果发生，一般是存在问题，和oom的处理思路类似。
• OOM问题
  • stackOverFlow
    无限递归调用，观察异常堆栈日志定位方法
  • java heap space
    大对象或短时间大量对象，通过分析堆转储文件定位问题类
  • metaspace
    反射、动态代理等导致动态生成大量类元数据（以反射为例，当同一个反射方法被短时间执行16次，jvm会进行优化，生成对应反射接口的实现类的类元数据并存放到metaspace）。这种问题通过堆转储文件不好定位，因为可能动态生成的类元数据虽然多，但占比不大。一般可以从近期代码变更中是否涉及反射、动态代理进行正向排查。
    解决思路一般是增加反射缓存（比如频繁生成Method的场景，就将Method进行缓存，这样只会生成一次对应的类元数据）、开启类卸载（CMS垃圾回收器）等。
  • GC overhead limit exceeded
    俗称"垃圾回收过头"，即垃圾回收占用了很多CPU时间片，但是回收的内存又很少。一般是内存泄漏（常见类的静态集合属性、threadLocal未执行remove方法），或堆内存较小导致。