最古老的垃圾收集器,“Serial”体现在其收集工作是单线程的,并且在进行垃圾收集过程中,会进入臭名昭著的“Stop-The-World”状态(即在收集垃圾的时候会停止整个程序的运行)。当然,其单线程设计也意味着精简的GC实现,无需维护复杂的数据结构,初始化也简单,所以一直是Client模式下JVM的默认选项。
从年代的角度,通常将其老年代实现单独称作Serial Old,它采用了标记-整理(Mark-Compact)算法,区别于新生代的复制算法。
Serial GC的对应JVM参数是: -XX:+UseSerialGC
ParNew GC
新生代GC实现,它实际是Serial GC的多线程版本,最常见的应用场景是配合老年代的CMS GC工作,下面是对应参数 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
CMS(Concurrent Mark Sweep) GC
基于标记-清除(Mark-Sweep)算法,设计目标是尽量减少停顿时间,这一点对于Web等反应时间敏感的应用非常重要,一直到今天,仍然有很多系统使用CMS GC。但是,CMS采用的标记-清除算法,存在着内存碎片化问题,所以难以避免在长时间运行等情况下发生full GC,导致恶劣的停顿。另外,既然强调了并发(Concurrent),CMS会占用更多CPU资源,并和用户线程争抢。
-
标记清除算法流程:
- 初始标记(CMS-initial-mark) :标记 Roots 能直接引用到的对象
- 并发标记(CMS-concurrent-mark):进行 GC Root Tracing
- 重新标记(CMS-remark) :修正并发标记期间由于用户程序运行而导致的变动
- 并发清除(CMS-concurrent-sweep):进行清除工作
Parrallel GC
在早期JDK 8等版本中,它是server模式JVM的默认GC选择,也被称作是吞吐量优先的GC。它的算法和Serial GC比较相似,尽管实现要复杂的多,其特点是新生代和老年代GC都是并行进行的,在常见的服务器环境中更加高效。
开启选项是: -XX:+UseParallelGC
-
另外,Parallel GC引入了开发者友好的配置项,我们可以直接设置暂停时间或吞吐量等目标,JVM会自动进行适应性调整,例如下面参数:
-XX:MaxGCPauseMillis=value
这里GC时间和用户时间比例 = 1 / (N+1) -XX:GCTimeRatio=N
G1 GC
这是一种兼顾吞吐量和停顿时间的GC实现,是Oracle JDK 9以后的默认GC选项。G1可以直观的设定停顿时间的目标,相比于CMS GC,G1未必能做到CMS在最好情况下的延时停顿,但是最差情况要好很多。
- G1 GC仍然存在着年代的概念,但是其内存结构并不是简单的条带式划分,而是类似棋盘的一个个region。Region之间是复制算法,但整体上实际可看作是标记-整理(Mark-Compact)算法,可以有效地避免内存碎片,尤其是当Java堆非常大的时候,G1的优势更加明显。
可预测的停顿时间模型
G1能去建立可预测的停顿时间模型是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。 G1跟踪各个 Region 里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值),在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的Region)。 这种使用Region划分内存空间以及有优先级的区域回收方式,保证了 G1 收集器在有限的时间内可以获取尽可能高的收集效率。
收集流程
- 初始标记(Initial Marking),初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象,这阶段需要停顿线程,但耗时很短。
- 并发标记(Concurrent Marking) ,并发标记阶段是从GC Root开始对堆中对象进行可达性分析,找出存活的对象,这阶段耗时较长,但可与用户程序并发执行。
- 最终标记(Final Marking)最终标记阶段则是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录,这阶段需要停顿线程,但是可并行执行。
- 筛选回收(Live Data Counting and Evacuation)筛选回收阶段首先对各个Region的回收价值和成本进行排序,根据用户所期望的GC停顿时间来制定回收计划,这样既能保证垃圾回收,又能保证停顿时间,而且也不会降低太多的吞吐量。
- G1吞吐量和停顿表现都非常不错,并且仍然在不断地完善,而且CMS已经在JDK 9中被标记为废弃。
最后做一个简要整理
- Serial收集器:串行运行;作用于新生代;复制算法;响应速度优先;适用于单CPU环境下的client模式。
- ParNew收集器:并行运行;作用于新生代;复制算法;响应速度优先;多CPU环境Server模式下与CMS配合使用。
- Parallel Scavenge收集器:并行运行;作用于新生代;复制算法;吞吐量优先;适用于后台运算而不需要太多交互的场景。
- Serial Old收集器:串行运行;作用于老年代;标记-整理算法;响应速度优先;单CPU环境下的Client模式。
- Parallel Old收集器:并行运行;作用于老年代;标记-整理算法;吞吐量优先;适用于后台运算而不需要太多交互的场景。
- CMS收集器:并发运行;作用于老年代;标记-清除算法;响应速度优先;适用于互联网或B/S业务。
- G1收集器:并发运行;可作用于新生代或老年代;标记-整理算法+复制算法;响应速度优先;面向服务端应用。
引用
前面讲到了垃圾收集过程中需要GC去找到Roots,然后顺藤摸瓜找到与Root有各自关联的对象,然后筛选回收垃圾,那么GC是如何找到这些还能存活下来的对象的呢?
首先在java中,可作为GC Roots的对象有:
- 虚拟机栈(栈帧中的本地变量表)中引用的对象;
- 方法区中的类静态属性引用的对象;
- 方法区中常量引用的对象;
- 本地方法栈中JNI(即一般说的Native方法)中引用的对象
不同的引用类型,主要体现的是对象不同的可达性状态和对垃圾收集的影响。
强引用
软引用
弱引用
幻象引用
可达状态 -- Reachable
强可达
软可达
弱可达
幻象可达
不可达
原文
https://juejin.im/post/5d6a0674f265da03b574618c