20180829系统超时问题回顾

背景：

8月29日，凌晨4点左右，某服务告警，其中一个节点直接down掉，收到告警的同事让运维重启。

9点左右，内存监控上发现内存异常，堆内存涨速很快，即便GC也没有什么效果，频繁GC。

9点38，服务各种超时，影响整个app使用。

处理方式：

当时由于很想要堆栈数据，所以没有让运维立即新起服务，切换ip，而是先dump后再重启服务，因为这个，对其他服务造成了更大的影响。

场景模拟：

由于已没有当时dump文件，这里用的模拟的dump文件，需要的同学可根据后面链接中的代码生成，

使用Memory Analyzer分析dump文件，使用介绍：https://blog.csdn.net/Jin_Kwok/article/details/80326088 ，https://www.jianshu.com/p/759e02c1feee

从上图1，图2来看，初步怀疑是ThreadGroupContext有问题，有太多的元素,而这个增长只通过java.beans.ThreadGroupContext#putBeanInfo方法触发。

网上搜索ThreadGroupContext，介绍很少，再往上找是Introspector，怀疑是：Introspector持有BeanInfo的引用，无法回收，导致内存泄漏。见：https://www.jianshu.com/p/b167716f9c0c

但这里有个疑问是ThreadGroupContext中的是weakHashMap，当GC的时候应该是会被回收的。

从第三张图（按Retained Heap倒序）来看，就明显感觉有问题了，加载了过多的类，没有得到释放，从classLoader来看，应该是groovy动态加载类导致的，网上搜索groovy 内存泄漏，一大片。。见：

https://blog.csdn.net/jinzhencs/article/details/74562973，由于动态加载类无法释放，将会挤用老年代内存，导致老年代可用内存持续减少，虽然一直GC但是效果甚微。

（盗图，java8没有Perm区，而是MetaSpace区）

总结：

1. 以上是针对不容易复现线上问题的情况，如果方便复现，可以通过jconsole观察，很直观。

2. 或许线上应该指定-XX:MaxMetaspaceSize，提前报OOM: Metaspace，快速失败，把对外服务的影响降小。

3. 如果再遇到类似问题，正确的处理方式，应该是立马让运维新起节点，随时准备切换。在提前知道，且自己无法处理的情况下，告知上级或者同事一起解决。

模拟代码：

maven配置
<dependency>
 <groupId>org.codehaus.groovy</groupId>
 <artifactId>groovy-all</artifactId>
 <version>2.4.7</version>
</dependency>
   
模拟代码：
public static void main(String[] args) {
      for (int i = 0; i < 1000000; i++) {
            new GroovyShell().evaluate("\"${0..9}-${0..9}\"");
      }
}
   
jvm参数：
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=OOM.hprof
-Dfile.encoding=UTF-8
-Xms200M
-Xmx200M
-Xmn40M
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:MetaspaceSize=30m
   
   
这里没有设置-XX:MaxMetaspaceSize ，如果设置了，会提前报java.lang.OutOfMemoryError: Metaspace
等执行到5分钟左右就可以自己手动dump了，jmap -dump:format=b,file=fileName pid

参考：

https://juejin.im/post/5b85ea54e51d4538dd08f601 （≈ 深入理解Java虚拟机：JVM高级特性与最佳实践（第二版》）

20180829系统超时问题回顾

相关文章