内存管理机制-内存分配策略

 

 

RoadMap

 

 

对象优先在Eden分配

        大多数状况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。 虚拟机提供了-XX：+PrintGCDetails这个收集器日志参数，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，而且在进程退出的时候输出当前的内存各区域分配状况。在实际应用中，内存回收日志通常是打印到文件后经过日志工具进行分析，不过本实验的日志并很少，直接阅读就能看得很清楚。

        新生代GC（Minor GC）：指发生在新生代的垃圾收集动做，由于Java对象大多都具有朝生夕灭的特性，因此Minor GC很是频繁，通常回收速度也比较快。

        老年代GC（Major GC/Full GC）：指发生在老年代的GC，出现了Major GC，常常会伴随至少一次的Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程）。Major GC的速度通常会比Minor GC慢10倍以上。

 

大对象直接进入老年代

        所谓的大对象是指，须要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组（笔者列出的例子中的byte[]数组就是典型的大对象）。大对象对虚拟机的内存分配来讲就是一个坏消息（替Java虚拟机抱怨一句，比遇到一个大对象更加坏的消息就是遇到一群“朝生夕灭”的“短命大对象”，写程序的时候应当避免），常常出现大对象容易致使内存还有很多空间时就提早触发垃圾收集以获取足够的连续空间来“安置”它们。 虚拟机提供了一个-XX：PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。这样作的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制

 

长期存活的对象将进入老年代

        既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了作到这点，虚拟机给每一个对象定义了一个对象年龄（Age）计数器。若是对象在Eden出生并通过第一次Minor GC后仍然存活，而且能被Survivor容纳的话，将被移动到Survivor空间中，而且对象年龄设为1。对象在Survivor区中每“熬过”一次Minor GC，年龄就增长1岁，当它的年龄增长到必定程度（默认为15岁），就将会被晋升到老年代中。对象晋升老年代的年龄阈值，能够经过参数-XX：MaxTenuringThreshold设置。

动态对象年龄断定

    为了能更好地适应不一样程序的内存情况，虚拟机并非永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，若是在Survivor空间中相同年龄全部对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就能够直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。

 

空间分配担保

 

    在发生Minor GC以前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代全部对象总空间，若是这个条件成立，那么Minor GC能够确保是安全的。若是不成立，则虚拟机会查看HandlePromotionFailure设置值是否容许担保失败。

    若是容许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，若是大于，将尝试着进行一次Minor GC，尽管此次Minor GC是有风险的；若是小于，或者HandlePromotionFailure设置不容许冒险，那这时也要改成进行一次Full GC。

    下面解释一下“冒险”是冒了什么风险，前面提到过，新生代使用复制收集算法，但为了内存利用率，只使用其中一个Survivor空间来做为轮换备份，所以当出现大量对象在Minor GC后仍然存活的状况（最极端的状况就是内存回收后新生代中全部对象都存活），就须要老年代进行分配担保，把Survivor没法容纳的对象直接进入老年代。

    与生活中的贷款担保相似，老年代要进行这样的担保，前提是老年代自己还有容纳这些对象的剩余空间，一共有多少对象会活下来在实际完成内存回收以前是没法明确知道的，因此只好取以前每一次回收晋升到老年代对象容量的平均大小值做为经验值，与老年代的剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多空间。 取平均值进行比较其实仍然是一种动态几率的手段，也就是说，若是某次Minor GC存活后的对象突增，远远高于平均值的话，依然会致使担保失败（Handle Promotion Failure）。若是出现了HandlePromotionFailure失败，那就只好在失败后从新发起一次Full GC。虽然担保失败时绕的圈子是最大的，但大部分状况下都仍是会将HandlePromotionFailure开关打开，避免Full GC过于频繁。