1.1 分代收集理论
- 弱分代假说:绝大多数对象都是朝生夕灭的
- 强分代假说:熬过越多次垃圾收集过程的对象就是越难以消亡
这两个假说共同奠定了收集器的一致原则:收集器应该将Java堆划分出不同的区域,将不同年龄的对象分配到不同区域。显而易见,如果一个区域中大多数对象都是朝生夕灭,难以熬过垃圾收集过程的话,那么把它们集中放在一起,每次回收时只关注如何保留少量存活而不是去标记那些大量将要被回收的对 象,就能以较低代价回收到大量的空间;如果剩下的都是难以消亡的对象,那把它们集中放在一块, 虚拟机便可以使用较低的频率来回收这个区域,这就同时兼顾了垃圾收集的时间开销和内存的空间有效利用。
假如要现在进行一次只局限于新生代区域内的收集(Minor GC),但新生代中的对象是完全有可 能被老年代所引用的,为了找出该区域中的存活对象,不得不在固定的GC Roots之外,再额外遍历整个老年代中所有对象来确保可达性分析结果的正确性,反过来也是一样。遍历整个老年代所有对象的方案虽然理论上可行,但无疑会为内存回收带来很大的性能负担。为了解决这个问题,就需要对分代收集理论添加第三条经验法则:
- 跨代引用假说:跨代引用相对于同代引用来说仅占绝小部分
依据这条假说,我们就不应再为了少量的跨代引用去扫描整个老年代,也不必浪费空间专门记录 每一个对象是否存在及存在哪些跨代引用,只需在新生代上建立一个全局的数据结构(该结构被称 为“记忆集”,Remembered Set),这个结构把老年代划分成若干小块,标识出老年代的哪一块内存会 存在跨代引用。此后当发生Minor GC时,只有包含了跨代引用的小块内存里的对象才会被加入到GC Roots进行扫描。虽然这种方法需要在对象改变引用关系(如将自己或者某个属性赋值)时维护记录数 据的正确性,会增加一些运行时的开销,但比起收集时扫描整个老年代来说仍然是划算的。
1.2 标记-清除算法
算法分为“标记”和“清除”两个阶段:他会标记处所有需要回收的对象,在标记完成后,统一进行回收。
缺点:
1.执行效率不稳定:如果Java堆中包含大量对象,而且其中大部分对象是要被回收的,这时必须进行大量的标记与清除
2.内存空间碎片化问题:标记清除会导致堆中产生大量不连续的碎片,当下次需要存放较大文件时,会因无法找到合适的位置而提前触发一次垃圾收集。
1.3 标记-复制算法
将可用内存分为两块,每次只使用其中的一块,当这一块的内存用完时,就将存活的对象复制到另一块上,然后把使用的这一块全部清除。
缺点:内存缩小成了原来的一半
1.4 标记-整理算法
对存活对象进行标记,标记完成后,将存活对象移到一端,然后将边界以外的对象进行清除。
缺点:移动存活对象并更新所有引用这些对象的地方无疑是一件极为负重的操作。
2.1 Serial收集器
Serial收集器采用标志复制算法,新生代收集器。
它是一个单线程的收集器,这里的单线程的意义不仅仅是只会用一个处理器或一条收集线程去完成垃圾收集,更重要的是在收集时,必须暂停其他所有工作线程,直到它收集结束为止。
2.2 ParNew收集器
ParNew收集器采用标志复制算法,新生代收集器。
它是Serial收集器的多线程版本,但它工作时,也会暂停其他所有工作线程。
2.3 Parallel Scavenge收集器
Parallel Scavenge收集器采用标记复制的算法,新生代收集器。
它也是多线程收集器,只是关注点与其他收集器不同。CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间,而Parallel Scavenge收集器的目标是达成一个可控制的吞吐量。即运行用户代码时间/(运行用户代码时间+运行垃圾收集时间)。如果虚拟机完成某个任务,用户代码加上垃圾收集总共耗费了100分钟,其中垃圾收集花掉1分钟,那吞吐量就是99%。
2.4 Serial Old收集器
Serial Old收集器采用标记整理算法,老年代收集器。
它是Serial收集器的老年代版本,也是一个单线程收集器。
2.5Parallel Old收集器
Parallel Old收集器采用标记整理算法,老年代收集器。
它是Parallel Scavenge收集器的老年代版本,支持多线程。
2.6 CMS收集器
CMS(Concurrent Mark Sweep)收集器是一种以获取最短护手时间为目的的收集器。它在运行时包含四个部分:
- 初始标记
- 并发标记
- 重新标记
- 并发清除
1.标记清除:标记GC Roots能直接关联到的对象。时间短,需要停顿用户线程。
2.并发标记:从GC Roots能直接关联到的对象开始遍历,将所有能关联到的对象进行标记。时间长但可以并发运行。
3.重新标记:这个过程是为了修正并发标记期间,因用户继续运作而导致的标记变动的那一部分对象的标记记录。需要停顿用户线程。
4.并发清除:清理掉在标记期间判断为死亡的对象。并发运行。
优点:并发收集、低停顿
缺点:标记清除算法,所以会产生碎片
2.7 Garbage First收集器
G1收集器是一款主要面向服务端应用的垃圾收集器。它虽然也是遵循分代收集理论设计的,但它不在坚持以固定大小和固定数量来进行分代的区域划分,而是把Java堆分成多个大小相等的独立区域(Region),每一个Region都可以根据需要来扮演新生代的Eden空间、Survivor空间、或者老年代空间。Region中还有一类特殊的Humongous区域,专门用来存储大对象。
它运行时包含四个部分:
- 初始标记:仅仅只是标记一下GC Roots能直接关联到的对象,并且修改TAMS 指针的值,让下一阶段用户线程并发运行时,能正确地在可用的Region中分配新对象。这个阶段需要 停顿线程,但耗时很短。
- 并发标记:从GC Root开始对堆中对象进行可达性分析,递归扫描整个堆 里的对象图,找出要回收的对象,这阶段耗时较长,但可与用户程序并发执行。当对象图扫描完成以 后,还要重新处理SATB记录下的在并发时有引用变动的对象。
- 最终标记::对用户线程做另一个短暂的暂停,用于处理并发阶段结束后仍遗留 下来的最后那少量的SATB记录。
- 筛选回收:负责更新Region的统计数据,对各个Region的回 收价值和成本进行排序,根据用户所期望的停顿时间来制定回收计划,可以自由选择任意多个Region 构成回收集,然后把决定回收的那一部分Region的存活对象复制到空的Region中,再清理掉整个旧 Region的全部空间。这里的操作涉及存活对象的移动,是必须暂停用户线程,由多条收集器线程并行 完成的。