问题描述：

系统上线发生FullGC

定位过程：

1、查看zabbix监控找到FullGC时间点；
2、根据时间点搜索GC日志，找出GC原因（gc case）；
-Xloggc:/dev/shm/gc20190226084714.log 该启动参数指定了gc日志存储位置
3、根据GC原因发现是Metaspace持续增长导致FullGC；

2019-02-26T08:24:09.252+0800: 391942.779: [Full GC (Metadata GC Threshold) 2019-02-26T08:24:09.252+0800: 391942.779: [CMS: 361366K->361612K(10485760K), 1.1662525 secs] 609428K->361612K(16148096K), [Metaspace: 187649K->187649K(1572864K)], 1.1694997 secs] [Times: user=1.24 sys=0.00, real=1.17 secs]
2019-02-26T08:24:10.421+0800: 391943.948: [Full GC (Last ditch collection) 2019-02-26T08:24:10.422+0800: 391943.948: [CMS: 361612K->361518K(10485760K), 1.1508390 secs] 361612K->361518K(16148096K), [Metaspace: 187608K->187608K(1572864K)], 1.1540049 secs] [Times: user=1.16 sys=0.00, real=1.15 secs]
2019-02-26T08:24:11.576+0800: 391945.103: Total time for which application threads were stopped: 2.3287421 seconds, Stopping threads took: 0.0001573 seconds

4、添加JVM参数打印类加载情况

# 在catalina.sh脚本中增加参数并重启，重启后在tomcat/logs/catalina.out文件日志中查看类加载情况

JAVA_OPTS="$JAVA_OPTS -XX:+TraceClassLoading -XX:+TraceClassUnloading"

查看catalina.out日志发现大量重复反射类加载：

[Loaded sun.reflect.GeneratedConstructorAccessor72 from __JVM_DefineClass__]
[Loaded sun.reflect.GeneratedConstructorAccessor73 from __JVM_DefineClass__]
[Loaded sun.reflect.GeneratedConstructorAccessor74 from __JVM_DefineClass__]
[Loaded sun.reflect.GeneratedConstructorAccessor75 from __JVM_DefineClass__]
[Loaded sun.reflect.GeneratedConstructorAccessor76 from __JVM_DefineClass__]
[Loaded sun.reflect.GeneratedConstructorAccessor77 from __JVM_DefineClass__]
[Loaded sun.reflect.GeneratedConstructorAccessor78 from __JVM_DefineClass__]
[Loaded sun.reflect.GeneratedConstructorAccessor79 from __JVM_DefineClass__]

5、这里由于用了Spring框架的动态代理，加载的类为反射类，并不能确定类存在重复加载，需要查看具体动态代理的那些类或方法；

6、手动编写ClassFilter来Dump元空间中已加载的类文件；
1）编写方法访问过滤器：

import sun.jvm.hotspot.oops.InstanceKlass;
import sun.jvm.hotspot.tools.jcore.ClassFilter;

public class MethodAccessorFilter implements ClassFilter {

    @Override
    public boolean canInclude(InstanceKlass instanceKlass) {
        String klassName = instanceKlass.getName().asString();
        
        // sun/reflect/DelegatingClassLoader 可替换为需要Dump的包路径或类
        return klassName.startsWith("sun/reflect/DelegatingClassLoader");
    }
}

2）编译方法访问过滤器：

$ javac -classpath $JAVA_HOME/lib/sa-jdi.jar  MethodAccessorFilter.java

3）dump 指定的类或包：

$ java -classpath ".:$JAVA_HOME/lib/sa-jdi.jar" -Dsun.jvm.hotspot.tools.jcore.filter=MethodAccessorFilter sun.jvm.hotspot.tools.jcore.ClassDump 269932
# 注意：dump输出的文件保存在当前目录下，比如：./sun/reflect/DelegatingClassLoaderXX.class 

4）找出大量重复的类（多大量才是异常情况需要结合自身项目情况和经验来判断），反编译该类的class文件

$ javap -verbose GeneratedMethodAccessor99.class

# 找出invokevirtual准确位置

5）查找反射调用的类构造或方法（以下以反射的方法为例）：

find ./ -name "GeneratedMethodAccessor*" | xargs javap -verbose | grep "invokevirtual #10" | grep "com.pjbest" >> /tmp/invokevirtual.txt

7、查看实际代理的方法或类，结合代码进一步分析引起Metaspace持续增长的根本原因；

以下是该事故定位出来的原因：

事故由 MapperFactory使用不当引起，使用到MapperFactory的地方需要保持单例或直接采用静态方式：

存在Metaspace泄漏隐患的代码：

image

正确的代码：

image

总结

引起Metaspace溢出的原因有多种，该文章以spring框架为例进行分析，需要能够理解类加载的原理和spring动态代理的机制，再利用工具进行分析，最终结合代码找出问题根源。

分析问题参考了以下文章：
1. 假笨说-从一起GC血案谈到反射原理
2. 大量DelegatingClassLoader类加载器，导致Perm区溢出
3. 警惕动态代理导致的Metaspace内存泄漏问题
4. 什么是Java的永久代（PermGen）内存泄漏
5. Java永久代去哪儿了
6. 从java进程里dump出类的class文件的小工具--dumpclass
7. sun.reflect.DelegatingClassLoader

撰写时间：2018-9-6