JVM--FullGC触发条件总结以及解决策略
前⾔
Full GC相对于Minor GC来说，停⽌⽤户线程的STW（stop the world）时间过长，⾄少慢10倍以上，所以要尽量避免，⾸先说⼀下Full GC 可能产⽣的原因，接着给出排查⽅法以及解决策略。
1、()⽅法的调⽤
在代码中调⽤()⽅法会建议JVM进⾏Full GC，但是注意这只是建议，JVM执⾏不执⾏是另外⼀回事⼉，不过在⼤多数情况下会增加Full GC的次数，导致系统性能下降，⼀般建议不要⼿动进⾏此⽅法的调⽤，可以通过-XX:+ DisableExplicitGC来禁⽌RMI调⽤。
2、⽼年代（Tenured Gen）空间不⾜
在Survivor区域的对象满⾜晋升到⽼年代的条件时，晋升进⼊⽼年代的对象⼤⼩⼤于⽼年代的可⽤内存，这个时候会触发Full GC。
3、Metaspace区内存达到阈值
从JDK8开始，永久代(PermGen)的概念被废弃掉了，取⽽代之的是⼀个称为Metaspace的存储空间。Metaspace使⽤的是本地内存，⽽不是堆内存，也就是说在默认情况下Metaspace的⼤⼩只与本地内存⼤⼩有关。-XX:MetaspaceSize=21810376B（约为20.8MB）超过这个值就会引发Full GC，这个值不是固定的，是会随着JVM的运⾏进⾏动态调整的，与此相关的参数还有多个，详细情况请参考这篇⽂章jdk8 Metaspace 调优
4、统计得到的Minor GC晋升到旧⽣代的平均⼤⼩⼤于⽼年代的剩余空间
Survivor区域对象晋升到⽼年代有两种情况：
⼀种是给每个对象定义⼀个对象计数器，如果对象在Eden区域出⽣，并且经过了第⼀次GC，那么就将他的年龄设置为1，在Survivor区域的对象每熬过⼀次GC，年龄计数器加⼀，等到到达默认值15时，就会被移动到⽼年代中，默认值可以通过-XX:MaxTenuringThreshold来设置。
另外⼀种情况是如果JVM发现Survivor区域中的相同年龄的对象占到所有对象的⼀半以上时，就会将⼤于这个年龄的对象移动到⽼年代，在这批对象在统计后发现可以晋升到⽼年代，但是发现⽼年代没有⾜够的空间来放置这些对象，这就会引起Full GC。
5、堆中产⽣⼤对象超过阈值
这个参数可以通过-XX:PretenureSizeThreshold进⾏设定，⼤对象或者长期存活的对象进⼊⽼年代，典型的⼤对象就是很长的字符串或者数组，它们在被创建后会直接进⼊⽼年代，虽然可能新⽣代中的Eden区域可以放置这个对象，在要放置的时候JVM如果发现⽼年代的空间不⾜时，会触发GC。
jvm调优参数
6、⽼年代连续空间不⾜
JVM如果判断⽼年代没有做⾜够的连续空间来放置⼤对象，那么就会引起Full GC，例如⽼年代可⽤空间⼤⼩为200K，但不是连续的，连续内存只要100K，⽽晋升到⽼年代的对象⼤⼩为120K，由于120＞100的连续空间，所以就会触发Full GC。
7、CMS GC时出现promotion failed和concurrent mode failure
这个原因引发的Full GC可以参考这篇⽂章，下⾯也摘抄⾃这篇⽂章：JVM 调优 —— GC 长时间停顿问题及解决⽅法提升失败（promotion failed），在 Minor GC 过程中，Survivor Unused 可能不⾜以容纳 Eden 和另⼀个 Survivor 中的存活对象，那么多余的将被移到⽼年代，称为过早提升（Premature Promotion）。这会导致⽼年代中短期存活对象的增长，可能会引发严重的性能问题。再进⼀步，如果⽼年代满了， Minor GC 后会进⾏ Full GC，这将导致遍历整个堆，称为提升失败（Promotion Failure）。
在 CMS 启动过程中，新⽣代提升速度过快，⽼年代收集速度赶不上新⽣代提升速度。在 CMS 启动过程中，⽼年代碎⽚化严重，⽆法容纳新⽣代提升上来的⼤对象，这是因为CMS采⽤标记清理，会产⽣连续空间不⾜的情况，这也是CMS的缺点
总结
可以发现其实堆内存的Full GC⼀般都是两个原因引起的，要么是⽼年代内存过⼩，要么是⽼年代连续内存过⼩。⽆⾮是这两点，⽽元数据区Metaspace引发的Full GC可能是阈值引起的，详细原因还是建议参考其他⽂章，我就不误⼈⼦弟了