JVM内存分配担保机制，如果想要理解透彻，需要先知道，Java GC是什么时候发生的？
Java GC When Happend？
Java 虚拟机一般采用的是分代回收策略，即把对象分为两代，新生代和老年代，新生代又分为Eden区和两个Survivor区，比例为8:1:1。
1）新建的对象(除了大数据对象)会首先分配在Eden区，如果Eden区空间不够时，就会发生一次Minor GC
2）当新生代的对象进入老年代时，如果老年代的空间不够时，就会发生一次Full GC，大对象一般会直接进入老年代，为了防止在Eden、Survivor区中copy带来的性能消耗
3）每次发生Minor GC时，Java虚拟机会检测老年代的剩余空间是否大于新生代的总空间，如果大于，则直接发生MinorGC，而且操作是安全的。如果小于，那么此时就引入了内存担保的概念
JVM内存分配担保机制
谁承担了这个角色
从上面GC发生的时刻来说，需要内存分配担保的时候，我们知道老年代存当了担保的角色。
如何承担的？
从上面第三点MinorGC发生的时候，检测到老年代剩余空间小于新生代的总空间，也就说，这次如果恰好新生代里面的对象都到了晋升年龄，那么都要进入老年代，此时老年代的空间不够了。怎么办？
此时Java虚拟机会去查看HandlePromotionFailure设置值是否允许担保失败。如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；如果小于或者HandlePromotionFailure=false，则改为进行一次Full GC。
为什么需要内存分配担保呢？
是因为新生代采用复制收集算法，假如大量对象在Minor GC后仍然存活（最极端情况为内存回收后新生代中所有对象均存活），而Survivor空间是比较小的，这时就需要老年代进行分配担保，把Survivor无法容纳的对象放到老年代。老年代要进行空间分配担保，前提是老年代得有足够空间来容纳这些对象，但一共有多少对象在内存回收后存活下来是不可预知的，因此只好取之前每次垃圾回收后晋升到老年代的对象大小的平均值作为参考。使用这个平均值与老年代剩余空间进行比较，来决定是否进行Full GC来让老年代腾出更多空间。
