Java虚拟机主流的垃圾收集器：cms、G1 。未来的趋势是基于大内存回收的ZGC,ZGC也是Jdk11版本的默认垃圾收集器。
以jdk1.8为例，讲讲触发Full GC的条件：
图中展示了7种不同分代的收集器：Serial、ParNew、Parallel Scavenge、Serial Old、Parallel Old、CMS、G1；
新生代收集器：Serial、ParNew、Parallel Scavenge；
老年代收集器：Serial Old、Parallel Old、CMS；
整堆收集器：G1；
触发Full GC的条件
1、老年代空间不足
旧生代空间只有在新生代对象转入及创建为大对象、大数组时才会出现不足的现象，当执行Full GC后空间仍然不足，则抛出如下错误： java.lang.OutOfMemoryError: Java heap space 为避免以上两种状况引起的FullGC，调优时应尽量做到让对象在Minor GC阶段被回收、让对象在新生代多存活一段时间及不要创建过大的对象及数组。
2、方法区空间不足
JVM规范中运行时数据区域中的方法区，在HotSpot虚拟机中又被习惯称为永生代或者永生区，Permanet Generation中存放的为一些class的信息、常量、静态变量等数据，当系统中要加载的类、反射的类和调用的方法较多时，Permanet Generation可能会被占满，在未配置为采用CMS GC的情况下也会执行Full GC。如果经过Full GC仍然回收不了，那么JVM会抛出如下错误信息：
java.lang.OutOfMemoryError: PermGen space为避免Perm Gen占满造成Full GC现象，可采用的方法为增大Perm Gen空间或转为使用CMS GC。
3、通过Minor GC后进入老年代的平均大小大于老年代的可用内存
如果发现统计数据说之前Minor GC的平均晋升大小比目前old gen剩余的空间大，则不会触发Minor GC而是转为触发full GC
4、由Eden区、From Space区向To Space区复制时，对象大小大于To Space可用内存，则把该对象转存到老年代，且老年代的可用内存小于该对象大小
5、System.gc()方法的调用
此方法的调用是建议JVM进行Full GC,虽然只是建议而非一定,但很多情况下它会触发 Full GC,从而增加Full GC的频率,也即增加了间歇性停顿的次数。强烈影响系建议能不使用此方法就别使用，让虚拟机自己去管理它的内存，可通过通过-XX:+ DisableExplicitGC来禁止RMI（Java远程方法调用）调用System.gc。
6、concurrent mode failure
CMS垃圾收集器特有的错误，CMS的垃圾清理和引用线程是并行进行的，如果在并行清理的过程中老年代的空间不足以容纳应用产生的垃圾，则会抛出“concurrent mode failure”。
concurrent mode failure影响
老年代的垃圾收集器从CMS退化为Serial Old，所有应用线程被暂停，停顿时间变长。
可能原因及方案
原因1：CMS触发太晚
方案：将-XX:CMSInitiatingOccupancyFraction=N调小；
原因2：空间碎片太多
方案：开启空间碎片整理，并将空间碎片整理周期设置在合理范围；
-XX:+UseCMSCompactAtFullCollection （空间碎片整理）
-XX:CMSFullGCsBeforeCompaction=n
原因3：垃圾产生速度超过清理速度
晋升阈值过小；
Survivor空间过小，导致溢出；
Eden区过小，导致晋升速率提高；
存在大对象；