JDK8记FullGC时候Metaspace内存不会被垃圾回收
物理机（与线上配置⼀样）上压测，第⼀次压了20w次，没有出现问题；接着⼜压了20w次，出现了内存溢出问题。
java.lang.OutOfMemoryError: Metaspace
JVM配置
JAVA_OPT_MEM="
-server -Xms4096M -Xmx4096M -Xmn512M -XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M
-XX:+UseParNewGC //新⽣区使⽤CMS（标记清理）算法进⾏垃圾回收
-XX:+UseConcMarkSweepGC //新⽣代使⽤并⾏收集器，⽼年代使⽤ CMS+串⾏收集器
...
...
"
初始化最⼤元空间是512M，
增加两个参数，在Full GC前后分别对内存做⼀个heap dump
jdk怎么使用-XX:+HeapDumpBeforeFullGC
-XX:+HeapDumpAfterFullGC
观察GC⽇志
{Heap before GC invocations=2799 (full 1):
par new generation total 471872K, used 58664K [0x00000006c0000000, 0x00000006e0000000, 0x00000006e0000000)
eden space 419456K, 9% used [0x00000006c0000000, 0x00000006c2679e10, 0x00000006d99a0000)
from space 52416K, 36% used [0x00000006dccd0000, 0x00000006ddfa0218, 0x00000006e000000
0)
to space 52416K, 0% used [0x00000006d99a0000, 0x00000006d99a0000, 0x00000006dccd0000)
concurrent mark-sweep generation total 3670016K, used 131775K [0x00000006e0000000, 0x00000007c0000000, 0x00000007c0000000) Metaspace used 258955K, capacity 262086K, committed 262144K, reserved 1265664K
class space used 45934K, capacity 46565K, committed 46592K, reserved 1048576K
2019-04-02T17:22:31.606+0800: 1359.334: [Full GC (Metadata GC Threshold) 2019-04-02T17:22:31.606+0800: 1359.334: [Heap Dump (before full gc): , 2.0610454 secs]2019-04-02T17:22:33.667+0800: 1361.395: [CMS2019-04-02T17:22:33.812+0800: 1361.540: [CMS-concurrent-mark: 0.163/2.264 secs] [Times: user=2.46 sys=0.25, real=2.26 secs]
(concurrent mode failure): 131775K->104031K(3670016K), 0.7241683 secs]2019-04-02T17:22:34.391+0800: 1362.119: [Heap Dump (after full gc): , 1.9020867 secs] 190439K->104031K(4141888K), [Metaspace: 258955K->258955K(1265664K)], 4.6899705 secs] [Times: user=4.35 sys=0.49, real=4.69 secs]
Heap after GC invocations=2800 (full 2):
par new generation total 471872K, used 0K [0x00000006c0000000, 0x00000006e0000000, 0x00000006e0000000)
eden space 419456K, 0% used [0x00000006c0000000, 0x00000006c0000000, 0x00000006d99a0000)
from space 52416K, 0% used [0x00000006dccd0000, 0x00000006dccd0000, 0x00000006e0000000)
to space 52416K, 0% used [0x00000006d99a0000, 0x00000006d99a0000, 0x00000006dccd0000)
concurrent mark-sweep generation total 3670016K, used 104031K [0x00000006e0000000, 0x00000007c0000000, 0x00000007c0000000) Metaspace used 258416K, capacity 260922K, committed 262144K, reserved 1265664K
class space used 45826K, capacity 46371K, committed 46592K, reserved 1048576K
}
问题
1、FullGC的时候 Metaspace 怎么现在变成了1.2G，设置的不是512M嘛？
[Metaspace: 258955K->258955K(1265664K)]
查看相关资料和官⽅⽂档后，发现Metaspace还有⼀个区间是Klass Metaspace，由参数-XX:CompressedClassSpaceSize进⾏控制，参考你假笨，笨神的博客 JVM源码分析之Metaspace解密；JDK8的时候 Klass Metaspace默认是1G。
2、Metaspace 空间在GC前后为什么根本没有被垃圾回收？
[Metaspace: 258955K->258955K(1265664K)]
从上⾯的GC⽇志分析，我们看到了Full GC前后，Metaspace的使⽤变化是从258955K->258955K，说明GC根本没有进⾏回收垃圾；
Metaspace主要是类的⼀些元数据信息，主要源于类加载器，可以使⽤ jstat -class pid 查看类的加载和写在情况；
还可以使⽤ jmap -histo:live pid  查看ClassLoader对象⽐较多的类型；
Metaspace中类的元数据信息只有在加载它的ClassLoader被释放后才会发⽣写在，如果ClassLoader对象⼀直存活，那么它所加载的类的元数据信息将不会被卸载。
参考笨神的博客 JVM源码分析之JDK8下的僵⼫(⽆法回收)类加载器，摘取重要的信息如下：
类加载器创建过多，带来的⼀个问题是，在类加载器第⼀次加载类的时候，会在Metaspace⾥会给它分配内存块，为了分配⾼效，每个类加载器⽤来存放类信息的内存块都是独⽴的，所以哪怕你这个类加载器只加载⼀个类，也会为之分配⼀块空的内存给这个类加载器，其实是⾄少两个内存块，于是你有可能会发现Metaspace的内存使⽤率⾮常低，但是committed的内存已经达到了阈值，从⽽触发了Full GC，如果这
种只加载很少类的类加载器⾮常多，那造成的后果就是很多碎⽚化的内存。
处理办法
修改代码使⽤反射完成对象之间属性的copy，改为set⽅法进⾏实现，解决了该问题；

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。