fullgc过于频繁有可能会造成oom，有可能不会。

首先明确一下，这篇文章的重点是分析后面一种情况，即应用在频繁的fullgc，但并没有出现oom。

我们来想一下为什么会出现fullgc，触发原因有很多种，但归根到底都是因为内存空间不足了（system.gc的情况不考虑）。

系统在频繁的fullgc，但并没有出现oom，说明每次回收的时候，肯定清理了部分内存空间。那这里就有2种情况，gc之后清理的内存空间大不大？

1、如果每次gc之后剩余的空间不大，说明有一部分顽固对象一直没法被回收，导致可用内存变少。这种情况下很容易后续出现oom，比如说一次大对象的申请

2、如果每次gc之后剩余的空间比较大，意味着大部分对象都被清理了，但是系统又在频繁的fullgc，说明很快老年代又会涌入大量对象。这个时候就应该检查下jvm的参数配置，很有可能是新生代设置的太小了，导致很多应该在minor gc阶段就清理出去的对象留到了老年代，这种可能性是最大的

新生代可以分为eden、survivor0、survivor1，正常的对象分配都是在eden完成的，如果eden空间不够了，会触发一次minor gc，存活的对象放在s0或s1中。随着每次minor gc，存活的对象会不断的从s0迁到s1，再从s1迁到s0，这个过程经过几次之后，如果对象还是存活的，就会晋升到老年代。

但如果新生代大小设置的太小，就会导致非常频繁的minor gc，s0->s1来回切换的速度加快，导致本身应该在minor gc就清理出去的对象跑到了老年代。

举个例子，正常情况下如果minor gc是1分钟一次，-XX:MaxTenuringThreshold默认配置是15的话，正常的小对象最长可以在新生代待15分钟左右，如果一个对象o的存活时间是5分钟，那它就可以在minor gc的时候被清理出去；但如果新生代设置过小，minor gc的频率降到10秒一次，那么o只能在新生代待150秒左右，然后就会晋升到老年代，这种对象一多，就会导致频繁的fullgc