JVM虚拟机发生GC时对象在堆内存移动的判断机制

**

对象动态年龄判断机制

**
动态年龄判断是eden园区内存满了的情况也就是发生minor gc/yong gc时，然后判断survivor中的一块区域，其中一块就肯定时空的（使用标记复制算法，一块是空的），
另一块是存放eden园区，发生minor gc之后存活的对象。

当前放对象的Survivor区域里(其中一块区域，放对象的那块s区)，一批对象的总大小大于这块Survivor区域内存大小的 50%(-XX:TargetSurvivorRatio可以指定)，那么此时大于等于这批对象年龄最大值的对象，就可以直接进入老年代了， 例如Survivor区域里现在有一批对象，年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区域的50%，此时就会 把年龄n(含)以上的对象都放入老年代。这个规则其实是希望那些可能是长期存活的对象，尽早进入老年代。对象动态年 龄判断机制一般是在minor gc之后触发的
例如From和To区内存大小为100M，minor GC后有60M对象要挪进来，根据动态年龄判断机制，这60M对象直接会被移到老年代，同时to区如果存在对象分代年龄大于等于1的对象都会移到老年代,然后回收To区和eden区垃圾对象。

老年代空间分配担保机制

年轻代每次minor gc之前JVM都会计算下老年代剩余可用空间 如果这个可用空间小于年轻代里现有的所有对象大小之和(包括垃圾对象) 就会看一个“-XX:-HandlePromotionFailure”(jdk1.8默认就设置了)的参数是否设置了 如果有这个参数，就会看看老年代的可用内存大小，是否大于之前每一次minor gc后进入老年代的对象的平均大小。 如果上一步结果是小于或者之前说的参数没有设置，那么就会触发一次Full gc，对老年代和年轻代一起回收一次垃圾， 如果回收完还是没有足够空间存放新的对象就会发生"OOM" 当然，如果minor gc之后剩余存活的需要挪动到老年代的对象大小还是大于老年代可用空间，那么也会触发full gc，full gc完之后如果还是没有空间放minor gc之后的存活对象，则也会发生“OOM”