原文链接
公司的HBase集群偶尔有个很奇怪的现象：内存占用会逐渐升高，超过堆内堆外内存限制，直到把操作系统内存占满被oom-killer杀死。在内存占用逐步升高的期间，响应延迟越来越高，最终服务宕机也会造成集群抖动，影响SLA。
内存增长过程非常缓慢，大概一两个月宕机一次。之前一直苦恼于没有现场，这次终于抓到了一个稳定复现的集群。
目前还没正式修复，修复验证也要几周时间，所以等我验证后再补充效果。
现象
用户反馈集群的延迟远高于其他集群，之前SRE进行过扩容也没有效果，所以开发介入开始排查。
查看集群监控，发现两台节点的内存占用非常高，接近100%。随后就会被oom-killer杀掉。
我们线上机器128G内存，这个集群HBase配置堆内40G堆外50G，加上其他进程的内存使用，整体内存使用率在80%算是比较合理的。
内存占用高之后，操作系统没有可用内存，会频繁的进行内存回收，如果回收速度跟不上，还会由后台回收变为直接回收，暂停进程的内存申请。在Java进程里也会看到莫名的GC。
可以用sar -B查看内存回收情况。忘记现场留图了，之后有图再补。
现场处理
开始排查时还有两个节点内存异常，请求慢日志数量明显高于其他节点。
用top查看内存使用，RegionServer进程占用在113G左右，远超限制，可以确定是发生内存泄漏了。
其中一台已经没法用arthas进行挂载了，只能先重启。
剩余一台赶紧用arthas挂进去看，发现堆内堆外大小都正常，但metaspace达到12G。当时也没有截图，这里用目前线上的一台机器示意一下，有机会再补图：
这时候猜测是JVM的metaspace发生了内存泄漏，因为metaspace没有大小限制，会一直像操作系统申请内存，直至把内存占满。
赶紧打个heap dump好慢慢查。因为打dump会Full GC，发生长时间的STW，大内存的RS会因为和ZK失联宕机，所以一般线上不轻易打dump。
在我重启了两台节点之后，用户侧的延迟就明显下降了
排查
把heap dump下载到本地之后，用MAT打开。好家伙250多万的Class，这时候可以确定是metaspace出问题了。
这里还有个插曲，在用MAT打开的时候，一直卡在分析unreachable objects的这一步。这个dump只有8G，之前分析30G的dump都没卡住，查了一下把这一步跳过就顺利打开了。
直接通过MAT查看Class的引用关系，并看不出是怎么产生的。后面的DelegatingClassLoader的异常，也是后来发现的，当时没注意到。
网上一通查，找到从一起GC血案谈到反射原理，按步骤可以完整复现。
用sa-jni.jar dump出GeneratedMethodAccessor的字节码：
20: aaload
21: checkcast #14 // class "[B"
24: invokestatic #10 // Method org/apache/hadoop/hbase/filter/FirstKeyOnlyFilter.parseFrom:([B)Lorg/apache/hadoop/hbase/filter/FirstKeyOnlyFilter;
27: areturn
看24这行，这里显示是在执行org.apache.hadoop.hbase.filter.FirstKeyOnlyFilter.parseFrom()方法，这是HBase的Filter功能相关的类。那就直接去找代码，看什么地方会用反射处理Filter的逻辑。
/**
* Convert a protocol buffer Filter to a client Filter
*
* @param proto the protocol buffer Filter to convert
* @return the converted Filter
*/
@SuppressWarnings("unchecked")
public static Filter toFilter(FilterProtos.Filter proto) throws IOException {
String type = proto.getName();
final byte [] value = proto.getSerializedFilter().toByteArray();
String funcName = "parseFrom";
try {
Class c = Class.forName(type, true, ClassLoaderHolder.CLASS_LOADER);
Method parseFrom = c.getMethod(funcName, byte[].class);
if (parseFrom == null) {
throw new IOException("Unable to locate function: " + funcName + " in type: " + type);
}
return (Filter)parseFrom.invoke(c, value);
} catch (Exception e) {
// Either we couldn't instantiate the method object, or "parseFrom" failed.
// In either case, let's not retry.
throw new DoNotRetryIOException(e);
}
}
找到唯一一处：RS从client发来的请求中，用反射的方式解析出Filter。那八成就是这个地方有问题了。
因为这个字节码只能从运行中的进程中去抓，所以分析dump的进程和抓这个
GeneratedMethodAccessor字节码的进程不是同一个，虽然它的GeneratedMethodAccessor数量也明显异常，并且绝大多数都和Filter有关，但不能百分百联系起来，后面我会再抓一次现场确认。
原因
补充个背景，这个集群使用的是ShenandoahGC，是公司内自己编译的包含SGC的JDK8，并不是社区的发行版。之前也出现过兼容问题导致出core dump。而且加了-XX:+ShenandoahAlwaysClearSoftRefs配置，不管其他配置，直接清理软连接。
Unconditionally clear soft references, instead of using any
other cleanup policy. This minimizes footprint at expense of
more soft reference churn in applications.
然后参考从一起GC血案谈到反射原理梳理下原因：
Class里的reflectionData是用SoftReference修饰的，会在GC时回收，而因为有-XX:+ShenandoahAlwaysClearSoftRefs配置，回收软连接会更激进Class获取Method时，可能会因为reflectionData被回收，而需要重新copy产生一个新的MethodMethod.invoke的时候，会通过methodAccessor去执行。因为Method是copy产生的新对象，所以methodAccessor也是新对象。methodAccessor的实现是DelegatingMethodAccessorImpl，这是个包装类，具体逻辑会委派给NativeMethodAccessorImpl和GeneratedMethodAccessorXXX，后面XXX是递增的数字。DelegatingMethodAccessorImpl的前15次执行是NativeMethodAccessorImpl处理，超出后产生一个GeneratedMethodAccessorXXX类进行处理，而这些对于JVM来说是不同的类，即都需要在metaspace里存储自己的元信息。这就是GeneratedMethodAccessorXXX和Class泛滥的原因GeneratedMethodAccessorXXX都有个单独的ClassLoader，就是DelegatingClassLoader，这就是DelegatingClassLoader也有250多万个的原因目前不明确的问题还有为什么GeneratedMethodAccessor和DelegatingClassLoader不会被回收，我理解在metaspace不断扩大的过程中，应该是会触发回收的。不知道是不是和SGC有关。
后续
参考
- 从一起GC血案谈到反射原理
- VM Options Explorer - OpenJDK11 HotSpot
