干货，记一次Metaspace导致频繁fgc的问题排查过程

最近线上有一条机器在运行了10几天后出现告警，频繁出现fgc，在切断流量之后，从运维那边拿了应用的heapdump文件。在一开始出现fgc时，我就上了容器平台查看了gc日志，gc日志如下：

 

从日志中可以看出很明显优于metaspace空间不够造成的fgc，而且不断进行fgc，且metaspace空间回收不了。于是查看一下jvm启动参数，参数如下：

 

这里Metaspace和MaxMetaspace都设置成了256M，奇怪了gc日志中Metaspace才使用了165M就出现了fgc，难道是新加载的类90M的空间吗，这个可以肯定不是，如果不是新申请90M的空间这个原因引起的，那么就只有metaspace内存碎片引起的了。于是通过mat分析heapdump，发现 DelegatingClassLoader有1100多个，于是先查看一下 DelegatingClassLoader是个什么东西？其属于sun.reflect包下，代码如下：

classDelegatingClassLoader extendsClassLoader { DelegatingClassLoader(ClassLoader var1) { super(var1); }

证明其确实一个ClassLoader。

那到底是什么对象在引用这些ClassLoader呢，通过mat发现是 GeneratedMethodAccessor在引用这些ClassLoader，继续跟踪发现是mybatis的Reflector应用了这些对象。好办了，于是继续查看了Reflector的代码，代码片段如下：

privateMap<String, Invoker> setMethods= newHashMap&l