最近在排查服务JVM的FullGC超过1s的问题。查证后发现并不是Old Gen空间不足时导致的GC，而是其他情况导致的FullGC。可能导致FullGC的原因有以下几种。
- 老年代空间不足。
- 永生代或者元数据空间不足。
- System.gc()方法调用。
- CMS GC时出现promotion failed和concurrent mode failure
- YoungGC时晋升老年代的内存平均值大于老年代剩余空间
- 有连续的大对象需要分配
老年代空间不足条件已经被排除，代码中没有System.gc()方法的调用，且老年代空间充足，每次YoungGC晋升老年代的内存并不多，也没有大对象需要分配。排查了一轮之后，发现只可能是永生代或元数据空间不足引起的FullGC。由于我的项目中使用的是1.8，所以Jvm中类信息、常量、静态数据等存放在元数据空间中（MetaSapce）。观察我的MetaSpace已经达到200MB，超过了我设置的离我设置的-XX:MetaspaceSize=128m的大小,距离设置的最大最数据空间大小-XX:MaxMetaspaceSize=256m也已经很接近了。
MetaSpace与Perm不同，在创建之初只分配一个很小的内存，当类不断加载时才会持续扩容，当MetaSpace较大时，可能导致频繁的FullGC，且当MetaSpace超出预设的最大值时，有可能导致OOM。
由于MetaSpace区域存放的是Jvm中类信息等，在正常情况下不会有这样大量的增长。定位问题之后发现，是下面的一段bean的配置引起的：
<bean id="testMetaSpaceOOM" class="TransactionManager"
scope="request" factory-method="createProxy">
<constructor-arg name="target" type="Class" value="test.TestMetaSpaceOOM"/>
</bean>
这个配置是为了使类中的方法可以实现事务，createProxy方法如下：
public Object createProxy(Object target) {
this.obj = target;
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(this.obj.getClass());
enhancer.setCallback(this);
enhancer.setClassLoader(target.getClass().getClassLoader());
return enhancer.create();
}
而这个对象的scope是request，也就是说每个请求进来，都会重新通过Enhancer动态创建了给定类型的子类，所以随着请求的不断进入，这个动态类的类文件就越来越多，导致频繁的FullGC。查询VisualVM可以发现，服务中这个类的动态生成类不计其数：
问题及时发现，将scope修改为singleton或者修改构造函数避免动态类的不断生成即可，可以示具体情况选择方案。
但是当真的当MetaSpace超过指定的最大值时，是立即发生OOM，还是先执行一次FullGC，再发生OOM，于是我在本地测试了一次。垃圾回收器是ParNew+CMS。测试结果是当MetaSpace超过预先设置的最大值时，会触发FullGC，FullGC之后可能会有几条新的请求可以被执行，但是依然无法避免之后发生OOM，OOM会迟到，但是不会缺席。
