jvm-sandbox 内存泄漏的严重 BUG

雨翔河

首页列表关于

2019-12-05 12:14

我们的A应用第一次出现宕机是4号节点,时间在2019-11-24 晚上19点

![](https://cdn.yuxianghe.net/image/blog/69-1.png)

原因是发生了fullGC，根本原因是元数据空间爆了。

```
2019-12-05T09:43:14.678+0800: 126777.294: [GC concurrent-root-region-scan-start]
2019-12-05T09:43:14.680+0800: 126777.297: [Full GC (Metadata GC Threshold) 2019-12-05T09:43:14.684+0800: 126777.300: [GC concurrent-root-region-scan-end, 0.0063095 secs]
2019-12-05T09:43:14.684+0800: 126777.300: [GC concurrent-mark-start]
2019-12-05T09:43:14.684+0800: 126777.300: [Heap Dump (before full gc): , 9.4641419 secs] 1209M->924M(4096M), 12.3670762 secs]
   [Eden: 0.0B(1844.0M)->0.0B(2138.0M) Survivors: 14.0M->0.0B Heap: 1209.7M(4096.0M)->924.3M(4096.0M)], [Metaspace: 375887K->375887K(1495040K)]
2019-12-05T09:43:27.048+0800: 126789.664: [Heap Dump (after full gc): , 9.5793358 secs] [Times: user=20.46 sys=2.10, real=21.94 secs] 
2019-12-05T09:43:36.627+0800: 126799.244: [Full GC (Last ditch collection) 2019-12-05T09:43:36.627+0800: 126799.244: [Heap Dump (before full gc): , 9.7975799 secs] 924M->921M(4096M), 12.5401121 secs]
   [Eden: 0.0B(2138.0M)->0.0B(2140.0M) Survivors: 0.0B->0.0B Heap: 924.3M(4096.0M)->921.7M(4096.0M)], [Metaspace: 375887K->375587K(1495040K)]
2019-12-05T09:43:49.167+0800: 126811.784: [Heap Dump (after full gc): , 10.9204228 secs] [Times: user=21.95 sys=2.30, real=23.46 secs] 
2019-12-05T09:44:00.089+0800: 126822.705: [GC concurrent-mark-abort]
2019-12-05T09:44:00.553+0800: 126823.170: [GC pause (Metadata GC Threshold) (young) (initial-mark), 0.0544386 secs]
```

能导致 metaspace 爆掉的原因大概率会是类对象加载过多，但是因为没有堆信息，没有办法进一步分析，检查了应用代码也没有发现根本原因，我们只能提高了 metaspace 的大小，在A应用的JVM参数上加上了heapdump，在发生fullGC之前和之后导出对象信息，再进行观察 。

```
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+HeapDumpBeforeFullGC -XX:+HeapDumpAfterFullGC
```

之后 2019-12-05 早上9点43分开始又出现了这种情况，A应用7号节点宕机将近20分钟。
![](https://cdn.yuxianghe.net/image/blog/69-2.png)

找到hprof文件，用mat打开一看，震惊了。

![](https://cdn.yuxianghe.net/image/blog/69-3.png)

这居然是 jvm-sanbox 的BUG，这玩意儿居然存在内存泄漏的问题！！！

```
The class "com.alibaba.jvm.sandbox.core.util.matcher.structure.ClassStructureImplByAsm", loaded by "com.alibaba.jvm.sandbox.agent.SandboxClassLoader @ 0x6ca1c88b8", occupies 625,360,152 (65.90%) bytes. The memory is accumulated in one instance of "com.alibaba.jvm.sandbox.core.util.collection.GaLRUCache" loaded by "com.alibaba.jvm.sandbox.agent.SandboxClassLoader @ 0x6ca1c88b8".

Keywords
com.alibaba.jvm.sandbox.core.util.matcher.structure.ClassStructureImplByAsm
com.alibaba.jvm.sandbox.agent.SandboxClassLoader @ 0x6ca1c88b8
com.alibaba.jvm.sandbox.core.util.collection.GaLRUCache

```

我们用jvm-sanbox是因为全链路压测，对打标了的数据进行切入，不进入真实的库，对某些方法也有做mock，但是阿里的这个 jvm-sandbox 是真的好用，没想到这种没有侵入式的东西会有这么严重的BUG，在多线程高并发的情况下，有可能会直接导致应用的元数据空间爆满。

找了下github的jvm-sandbox的issue，发现有人也遇到了类似的问题：

https://github.com/alibaba/jvm-sandbox/issues/194

立马对应用进行了更改，暂时下掉了jvm-sandbox，这种问题有点防不胜防，以后引入第三方组件还是要小心，除非是经过了时间的洗礼和大数据量的磨练，否则还是要谨慎一些的，另外就是这种应用宕机超过20分钟直接挂掉被重新拉起的情况可以说是很严重的问题了，但是很遗憾，开发人员并不知情，要不是偷偷的写了一个小工具机器人监听公司的告警系统，这个事情估计会消失在警告信息的海洋里。

类型：工作标签：jvm,sandbox,bug,内存泄漏