HotSpot虚拟机的垃圾收集器
1. Serial收集器
- 单线程，使用一个CPU或者一条收集线程去完成垃圾回收工作；进行垃圾回收时会暂停其他工作线程
- 新生代使用
复制算法，老年代版本使用标记-整理算法 - 由虚拟机自动发起，自动完成
2. ParNew收集器
- 多线程， serial收集器的多线程版本
- 新生代使用
复制算法，老年代版本使用标记-整理算法 - 效率不一定超过Serial收集器，因为线程切换也会造成很大的开销
3. Parallel Scavenge收集器
- 与尽可能的缩短垃圾收集时用户线程等待时间不同，该收集器是为了尽可能的增加
吞吐量(吞吐量 = 运行用户代码时间/（运行用户代码时间+垃圾回收时间）) - 吞吐量优先收集器
- 提供两个参数用于精确控制吞吐量：
-XX:MaxGCPauseMillis和-XX:GCTimeRatio
-XX:MaxGCPauseMillis：大于0的毫秒数，内存回收时间尽量不超过设定值，GC停顿时间是以牺牲吞吐量和新生代空间换取的
-XX:GCTimeRatio: 大于0小于100的整数，垃圾收集时间占总时间的比率，相当于吞吐量的倒数。比如设为19，就是垃圾回收时间：总时间 = 1:19,吞吐量为1/(1+19)，默认是99 - GC 自适应的调整策略（GC Ergonomics）
-XX:+UseAdaptiveSizePolicy:开启之后，不需要手动分配新生代大小-Xmn，eden区和survivor区占比-XX:SurvivorRatio，晋升老年代对象的年龄-XX:PretenureSizeThreshold等细节参数
4. Serial Old收集器
- 单线程，是serial收集器的老年代版本，使用
标记-整理算法 - 主要给client模式下的虚拟机使用
- 在server模式下：
1.在JDK 1.5与之前的版本与Parrallel Scavenge收集器搭配使用
2.作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用
5. parallel old 收集器
- 多线程，是 parallel scavenge收集器的老年代版本，使用
标记-整理算法
-注重吞吐量以及CPU资源的场合，优先考虑Parallel scavenge+Parallel Old
6. CMS收集器（Concurrent Mark Sweep）
- CMS收集器是一种获取最短回收停顿时间为目标的收集器，重视服务器相应速度，希望停顿时间最短。
- 基于
标记--清除算法实现- 初始标记（CMS initial mark）：标记 GC roots能关联到的对象，速度很快, stop the world
- 并发标记（CMS concurrent mark）：进行GC Roots Tracing
- 重新标记（CMS remark）:修正并发标记的过程中，因为用户线程继续运行导致的标记变动，时间比初始标记长，比并发标记短，需要stop the world
- 并发清除（CMS concurrent sweep）
CMS收集器运行示意图
- CMS 缺点：
- 对CPU资源敏感，会占用CPU资源，拖累用户线程
- 无法处理浮动垃圾（Floating Garbage），可能会出现
Concurrent Mode Failure，导致一次Full GC；CMS并发清除垃圾的时候，用户线程没有停顿，这会导致在清除的同时又会产生新的未标记过的垃圾，所以CMS需要在老年代预留一部分空间，保证用户线程产生的浮动垃圾有空间分配，如果空间不足就会出现Concurrent Mode Failure，启动serial old收集器，导致停顿时间变长，可以使用-XX:CMSInitiatingOccupancyFraction控制预留空间百分比 - 采用
标记-清除算法，会导致每次清除完之后存留大量的内存碎片
7. G1收集器
- G1收集器是面向服务端应用的垃圾收集器。
- G1收集器4个主要特点：
-
并行与并发：G1能利用多核和多CPU来缩短
Stop the world的时间，部分其他收集器原本需要停顿java线程执行的GC操作，G1能够通过并发的方式让java程序继续执行 - 分代收集：虽然G1可以不需要其他的收集器配合就能管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和存活了一段时间，熬过多次GC的旧对象以获取更好的收集效果
-
空间整合： G1从整体上看是基于
标记-整理算法实现的，从局部“region”上来看是基于复制算法，都不会产生内存碎片，不会提前触发FullGC - 可预测的停顿： G1除了追求低停顿外，还能建立可预测的停顿，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不超过N毫秒
-
并行与并发：G1能利用多核和多CPU来缩短
- G1收集器将java堆划分为多个大小相等的独立区域（region）,虽然还保留新生代和老年代的概念，但新生代和老年代已不再是物理隔离，他们都是一部分region的集合
- G1跟踪各个Region里面垃圾堆积的价值大小（回收获得空间和所需时间的经验值），在后台维护一张优先表，每次根据允许的收集时间，优先回收价值最大的Region(Garbage-First)，这种方式保证了有限时间内可以获得尽可能高的收集效率
- G1采用
Remembered Set避免全堆扫描- G1把Java堆分为多个Region，就是“化整为零”。但是Region不可能是孤立的，一个对象分配在某个Region中，可以与整个Java堆任意的对象发生引用关系。在做可达性分析确定对象是否存活的时候，需要扫描整个Java堆才能保证准确性，这显然是对GC效率的极大伤害。
- 为了避免全堆扫描的发生，虚拟机为G1中每个Region维护了一个与之对应的
Remembered Set。虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中（在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中。当进行内存回收时，在GC Roots的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。
- G1收集器大致分为以下几个步骤：
- 初始标记（Initial Marking）： 仅仅只是标记一下GC Roots 能直接关联到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建对象，此阶段需要停顿线程，但耗时很短。
- 并发标记（Concurrent Marking）： 从GC Root 开始对堆中对象进行可达性分析，找到存活对象，此阶段耗时较长，但可与用户程序并发执行。
- 最终标记（Final Marking）： 为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程的Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并行执行。
- 筛选回收（Live Data Counting and Evacuation）：首先对各个Region中的回收价值和成本进行排序，根据用户所期望的GC 停顿是时间来制定回收计划。此阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅度提高收集效率。
G1收集器
| 收集器 | 串行/并行/并发 | 新生代/老年代 | 算法 | 目标 | 适用场景 |
|---|---|---|---|---|---|
Serial |
串行 |
新生代 |
复制算法 | 响应速度优先 | 单CPU环境下的Client模式 |
Serial Old |
串行 |
老年代 |
标记-整理 | 响应速度优先 | 单CPU环境下的Client模式、CMS的后备预案 |
ParNew |
并行 |
新生代 |
复制算法 | 响应速度优先 | 多CPU环境时在Server模式下与CMS配合 |
Parallel Scavenge |
并行 |
新生代 |
复制算法 | 吞吐量优先 | 在后台运算而不需要太多交互的任务 |
Parallel Old |
并行 |
老年代 |
标记-整理 | 吞吐量优先 | 在后台运算而不需要太多交互的任务 |
CMS |
并发 |
老年代 |
标记-清除 | 响应速度优先 | 集中在互联网站或B/S系统服务端上的Java应用 |
G1 |
并发 |
堆内存 |
整体标记-整理 region复制算法 |
响应速度优先 | 面向服务端应用，将来替换CMS |
网友评论