图解 JVM GC 过程
1. Minor GC
(1) Minor GC过程
假设现在Heap内存大小为20M，其中年轻代为10M，老年代为10M，年轻代中Eden区6M，From区2M，To区2M，新创建的对象首先往Eden区分配，当再次分配一个对象，假设大小为1M，此时Eden区已经没有足够空间来给这个对象分配内存，如图所示：
这时候触发一次Minor GC，把Eden区的存活对象转移到From区，非存活对象进行清理，然后给新创建的对象分配空间，存入Eden区
随着分配对象的增多，Eden区的空间又不足了：
这时候再触发一次Minor GC，清理掉Eden区和S1区的死亡对象，把存活对象转移到S2区，然后再给新对象分配内存：
From区和To区是相对的关系，哪个区中有对象，哪个区就是From区，比如，再进行一次Minor GC，会把存活对象转移到S1区，再为转移之前，S2区是From区，S1区是To区，转移后，S2区中没有存活对象，变为To区，而S1区变为From区：
2. 对象进入老年代的4种情况
(1) 假如进行Minor GC时发现，存活的对象在ToSpace区中存不下，那么把存活的对象存入老年代
(2) 大对象直接进入老年代
假设新创建的对象很大，比如为5M(这个值可以通过PretenureSizeThreshold这个参数进行设置，默认3M)，那么即使Eden区有足够的空间来存放，也不会存放在Eden区，而是直接存入老年代
(3) 长期存活的对象将进入老年代
此外，如果对象在Eden出生并且经过1次Minor GC后仍然存活，并且能被To区容纳，那么将被移动到To区，并且把对象的年龄设置为1，对象没"熬过"一次Minor GC(没有被回收，也没有因为To区没有空间而被移动到老年代中)，年龄就增加一岁，当它的年龄增加到一定程度(默认15岁，配置参数-XX:MaxTenuringThreshold)，就会被晋升到老年代中
(4) 动态对象年龄判定
还有一种情况，如果在From空间中，相同年龄所有对象的大小总和大于From和To空间总和的一半，那么年龄大于等于该年龄的对象就会被移动到老年代，而不用等到15岁(默认)：
4. Full GC
如果某个(些)对象(原来在内存中存活的对象或者新创建的对象)由于以上原因需要被移动到老年代中，而老年代中没有足够空间容纳这个(些)对象，那么会触发一次Full GC，Full GC会对整个Heap进行一次GC，如果Full GC后还有无法给新创建的对象分配内存，或者无法移动那些需要进入老年代中的对象，那么JVM抛出OutOfMemoryError
5. 空间分配担保
在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandlerPromotionFailure这个参数设置的值(true或flase)是否允许担保失败(如果这个值为true，代表着JVM说，我允许在这种条件下尝试执行Minor GC，出了事我负责)。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者HandlerPromotionFailure为false，那么这次Minor GC将升级为Full GC
如果老年代最大可用的连续空间大于历次晋升到老年代对象的平均大小，那么在HandlerPromotionFailure为true的情况下，可以尝试进行一次Minor GC，但这是有风险的，如果本次将要晋升到老年代的对象很多，那么Minor GC还是无法执行，此时还得改为Full GC。
HandlerPromotionFailure为true时，如果某次需要转移到老年代中的对象确实很多，老年代无法容纳，那么也会先尝试进行一次Minor GC，Minor GC无法执行时再进行Full GC，这样虽然绕了圈子，但我们还是建议把这个参数设置为true，因为我们要尽量避免Full GC。