1. 弱分代假说(Weak Generational Hypothesis):绝大多数对象都是朝生夕灭的
2. 强分代假说(Strong Generational Hypothesis):熬过越多次垃圾收集过程的对象就越难以消亡
3. 跨代引用假说(Intergenerational Reference Hypothesis):跨代引用相对于同代引用来说仅占极少数
收集器应该将Java堆划分出不同的区域,然后将回收对象依据其年龄(年龄即对象熬过垃圾收集过程的次数)分配到不同的区域之中存储。
显而易见,如果一个区域中大多数对象都是朝生夕灭,难以熬过垃圾收集过程的话,那么把它们集中放在一起,每次回收时只关注如何保留少量存活而不是去标记那些大量将要被回收的对象(解释1),就能以较低代价回收到大量的空间;如果剩下的都是难以消亡的对象,那把它们集中放在一块,虚拟机便可以使用较低的频率来回收这个区域,这就同时兼顾了垃圾收集的时间开销和内存的空间有效利用(解释2)。
时间开销 ——> 支取扫描1%,比扫描99%快得多;
内存空间有效利用 ——> 1%移动时不会直接移动,而是复制一份,将复制移动过去,成功后,删除原有的。
新生代 —— 存放朝生夕死的对象
老年代 —— 存放新生代回收后还存活的对象,不容易死的对象
在新生代中,每次垃圾收集时都发现有大批对象死去,而每次回收后存活的少量对象,将会逐步晋升(解释3)到老年代中存放。
当年龄达到13时,就进入老年代
分代收集有一个问题:跨代引用
比如说新生代中有一个对象A引用老年代的一个对象 B,只要老年代的对象不回收,新生代的这个对象也不会被回收。每次新生代回收时还是要去扫(判断A是否需要回收,此时也需要去判断A引用的B是否被回收),也不能直接将A放入老年代,因为可能在A的年龄为12时,对象B就被回收了。
存在互相引用关系的两个对象,是应该倾向于同时生存或者同时消亡的。
举个例子,如果某个新生代对象存在跨代引用,由于老年代对象难以消亡,该引用会使得新生代对象在收集时同样得以存活,进而在年龄增长之后晋升到老年代中,这时跨代引用也随即被消除了。
虽然这种方法需要在对象改变引用关系(如将自己或者某个属性赋值)时维护记录数据的正确性,会增加一些运行时的开销,但比起收集时扫描整个老年代来说仍然是划算的。
标记:哪些对象可以存活或者哪些对象可以回收
它的主要缺点有两个:
第一个是执行效率不稳定。
如果Java堆中包含大量对象,而且其中大部分是需要被回收的,这时必须进行大量标记和清除的动作,导致标记和清除两个过程的执行效率都随对象数量增长而降低;
第二个是内存空间的碎片化问题。
标记、清除之后会产生大量不连续的内存碎片,空间碎片太多可能会导致当以后在程序运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
基本不使用
根据IBM研究,新生代中的对象有98%熬不过第一轮收集(普通场景下,无法保证每次都是这样),因此不需要按照1:1的比例来划分新生代的内存空间,而是使用了8:1:1分配内存空间。
每次进行收集时,将前8:1空间的存活对象一次性复制到另外的1比例,然后清理掉前8:1空间的朝生夕死的对象。
内存的分配担保好比我们去银行借款,如果我们信誉很好,在98%的情况下都能按时偿还,于是银行可能会默认我们下一次也能按时按量地偿还贷款,只需要有一个担保人能保证如果我不能还款时,可以从他的账户扣钱,那银行就认为没有什么风险了。
标记-复制算法虽然弥补了标记-清除算法的缺点,但标记-复制算法还是有自己的缺点:
首先就是在对象存活率较高时要进行较多的复制操作,效率将会降低;
还有一种情况,就是在十分之九的的对象里超过十分之一存活,那么复制到右边区域时空间大小就不够了。
为了解决这些,出现了标记-整理算法。
标记过程仍与标记-清除算法相同,但后续让所有存活的对象都向内存空间一端移动,然后直接清理掉边界以外的内存。
弊端:
像在老年代这种每次回收都有大量对象存活区域,移动存活对象并更新所有引用这些对象的地方将会是一种极为负重的操作,而且这种对象移动操作必须全程暂停用户应用程序(解释4)才能进行 ——> 宕机 stop the world
但不移动的话,碎片化问题严重,得不到解决也会导致性能、存储量降低。
如果不暂停的话,刚标记的时候只占据一块,标记完以后整理时可能就变成了占据了两块。
通常标记-清除算法也是需要停顿用户线程来标记、清理可回收对象的,只是停顿时间相对而言要来的短而已。
于是混合式出现了,让虚拟机平时多数时间都采用标记-清除算法,暂时容忍内存碎片的存在,直到内存空间的碎片化程度已经大到影响对象分配时,再采用标记-整理算法收集一次,以获得规整的内存空间。