1. 对象进入老年代的情况
分配担保规则：新生代GC过后，存活对象太多，Survivor区放不下了，这个时候就需要通过分配担保进入老年代；
达到年龄阈值：对象在新生代熬过了15次（-XX:MaxTenuringThreshold）GC，达到了年龄阈值，会晋升到老年代；（这种对象一般很少，只有在系统中的确需要长期存在的核心组件等，它们一般不能被回收）
动态年龄判断：在新生代Survivor区的对象，如果：年龄1 + 年龄2 + 年龄3 + 年龄N 的对象大小占比大于了Survivor区的50%以上，那年龄N及以上的对象就会晋升到老年代；
大对象直接进入老年代；（-XX:PretenureSizeThreshold）
默认值为0，当不主动设置值时，不管多大的对象都会先在新生代分配内存；
当手动设置了这个值时，如果生成一个大于这个大小的对象（比如一个超大的数组或者其他对象），就会直接在老年代中为这个对象分配内存；
G1收集器中有专门的大对象Region，大对象不存在老年代；
上面的几种情况中，分配担保和动态年龄判断都是很关键的；通常如果新生代的Survivor区内存设置过小，就可能导致这两种情况频繁发生，然后导致大量对象快速进入老年代，在老年代对象过多的时候，就会触发 Full GC。
2. 触发 Full GC 的情况
老年代占用比例参数（-XX:CMSInitiatingOccupancyFaction 默认92%)，老年代使用内存达到这个阈值会触发 Full GC;
执行YGC之前，如果 老年代可用内存大小 < 历次 YGC后升入老年代对象的平均大小，先执行 Full GC；
执行YGC之后，如果 存活对象大小 > 老年代可用内存大小，执行 Full GC；
3. 频繁 Full GC 的情况
JVM内存分配不合理，导致存活对象频繁进入老年代，发生Full GC；（可使用jstat 分析）
JVM内存分配已经很大，然而系统运行时产生大量对象，并且处理很慢，YGC后存活太多对象进入老年代，发生Full GC（或者超过对象年龄阈值）；（使用MAT分析占用大量内存的对象，追踪执行堆栈，优化代码）
系统发生 内存泄漏，大量对象无法回收，老年代中驻留了大量对象，导致一有部分对象进入老年代，就会发生Full GC；（可使用jmap导出内存快照，使用 MAT 分析）（加载了太多静态缓存）
加载类过多，导致元数据空间占用太大，发生Full GC；（可使用 -XX:TraceClassLoading -XX:TraceClassUnloading 进行分析）（反射会导致）
手动频繁执行 System.gc();（可使用 -XX:+DisableExplicitGC 屏蔽显示GC）
4. 如何定位及解决频繁 Full GC
根据频繁Full GC的几种情况，进行一一排查，使用jstat查看JVM运行模型：
如果表现为：每次YGC后，老年代规律性增大，然后几次YGC后就触发FGC：
则可能是：JVM内存分配不合理，查看JVM内存分配，看是否新生代和Survivor区分配太小，导致每次YGC后存活对象Survivor区都放不下，然后进入老年代；
解决方案：合理分配JVM内存模型，扩大新生代和Survivor区大小；
如果表现为：平常时候FGC频率很低，突然在短时间内连续发生FGC：
则可能是：突然系统承受高并发的请求，短时间内创建大量的对象；
解决方案：使用jstat等工具计算出高并发请求下，每秒新生代产生对象的大小，及每次YGC后存活对象大小，合理的对新生代和老年代进行扩容和分配内存模型；
如果查到JVM内存分配已经很大，并且当前系统正常情况下的负载量不会产生这么大对象：（执行时间较长产生的内存泄漏，无法及时回收）
则可能是：代码执行时，存在产生大量对象后，执行耗时时间很长（YGC都会存活）的异常代码；
解决方案：使用jmap导出内存快照，使用 MAT 分析 -> 追踪执行堆栈，定位错误代码；
如果表现为：在系统运行着的时候，每隔一段时间老年代突然增大，然后YGC后偶尔有对象进入老年代触发Full GC：
则可能是：代码执行过程中，每隔一段时间就会产生“大对象”进入老年代；（比如从数据库中不带where条件查出很多对象）（G1收集器大对象不会放在老年代）
解决方案：使用jmap导出内存快照，使用 MAT 分析 -> 找出是什么对象占用内存过大；
如果表现为：老年代内存持续的增大，每次YGC后都有存活对象进入老年代，“且发生FGC后回收掉的对象很少”：（代码本身的内存泄漏，无法回收）
则可能是：发生了内存泄漏，老年代中一直驻留了太多的对象，并且这些对象无法回收；（比如加载了太多静态数据、错误使用JVM静态缓存等）
解决方案：使用jmap导出内存快照，使用 MAT 分析 -> 找出是哪些对象占用内存过大；
如果表现为：老年代内存占用一直都很正常，但是元数据空间呈现规律性的减小增大情况；或者GC日志中显示 [Full GC（Metadata GC Threshold）]：
则可能是：加载类过多，导致元数据空间占用太大，发生Full GC；（错误的使用反射可能会导致）
解决方案：在JVM启动参数中添加：-XX:TraceClassLoading -XX:TraceClassUnloading -> 追踪到是什么类一直在频繁的加载和卸载；
如果以上情况都没有，则可能是在代码中手动执行 System.gc()：
解决方案：使用 -XX:+DisableExplicitGC 屏蔽显示GC；