GC/OOM问题处理思路

原则先止损再分析。如果是灰度阶段则直接回滚代码保留一台留作分析如果是全量阶段个别机器偶发则禁用该机器。流程保护现场禁用机器- 拉取堆转储文件以及通过流量监控判断可能的问题接口 - 堆转储文件分析使用MAT或JProfiler等工具- 结合代码确认问题 - 修复代码或调整jvm配置(-XX:HeapDumpOnOutOfMemoryError)并上线 - 观测上线后机器指标gc-time、gc-count、olggen-used-percent)问题分类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方法或堆内存较小导致。实践案例java heap oom现象kds系统在营业高峰出现系统卡顿明显、用户操作响应慢甚至软件闪退的情况。排查思路观测软件日志寻找耗时较长的接口分析卡顿的原因通过gc日志排查是否存在频繁gc、full-gc的情况通过crash日志查看crash的直接原因以及报错堆栈。初步排查结果营业高峰系统频繁gc甚至full-gc导致产生STW现象所以出现系统卡顿和操作响应慢至于闪退主要是因为一些设备性能较差垃圾回收不过来就oom了。所有的初步原因其实都跟内存吃紧有关但是通过日志和对应接口代码走读暂时找不到造成内存吃紧的根因问题归因思路使用性能排查工具JProfiler对系统进程进行问题分析但该工具运行时会极大占用目标机器的性能所以可能会影响商家经营故而决定通过模拟问题商家的经营动作借助UI自动化测试进行压测同时使用JProfiler进行性能分析的策略分析结果通过分析堆转储文件借助JProfiler的类视图工具识别到一个配置类的实例个数和内存占比很大再进一步查看该类的引用链路定位到是一个查询菜品缓存的方法创建了较多该类的实例。再结合代码发现是该方法调用了框架提供的一个缓存查询方法该方法每次从缓存中查询时都会深拷贝一次数据从而导致产生大量缓存配置对象。至于为什么会深拷贝是因为框架提供的查询方法被很多模块调用有些模块查询到配置后会对配置进行修改所以为了不互相影响框架侧采取了深拷贝这种比较粗暴的方式优化方式业务侧自己再维护一个菜品配置缓存读取时不再深拷贝而直接使用该配置对象metaspace oom现象线上告警metaspace oom导致机器挂掉排查思路先止损进行机器禁用避免机器异常信息在注册中心更新不及时导致有新的请求仍然路有到问题机器同时进行扩容针对问题机器拉取自动dump的堆转储文件使用美团的线上分析工具进行分析分析结果堆转储文件中发现大量GeneratedMethodAccessorxxx类xxx是数字超过了30000个背景是java反射获取方法时如果某些方法短时间频繁调用jvm会进行优化不再采用反射的方式获取方法而通过直接生成该方法的代理类即GeneratedMethodAccessorxxx的方式直接调用新生成的代理类的方法来提高调用效率。这个类较多会导致在metaspace中产生较多的类元数据从而引发了metaspace内存占用的增长另外gc为什么没有很好地回收新增的类元数据呢通过查看jvm的启动参数发现metaspaceSize和MaxMetaspaceSize都是256MB这导致每次到达最大值才会进行GC如果该次GC回收效率不高就有可能导致生产的类元数据不够存放而OOM解决方案对反射频繁调用的Method进行缓存避免重复生成GeneratedMethodAccessorxxx类。同时修改jvm参数使得MaxMetaspaceSize大于metaspaceSize给gc预留一些容错空间