垃圾收集器
文章目录
- 垃圾收集器
- 一、serial收集器
- 二、parnew收集器
- [三、parallel scavenge收集器](#三、parallel scavenge收集器)
- [四、serial old收集器](#四、serial old收集器)
- [五、parallel old收集器](#五、parallel old收集器)
- 六、CMS收集器
- [七、Garbage First收集器](#七、Garbage First收集器)
- 八、收集器的权衡
一、serial收集器
新生代收集器，最基础的收集器，单线程。进行垃圾收集时必须暂停其他所有工作线程，stop the world
二、parnew收集器
新生代收集器，实质上是serial收集器的多线程版本。除了serial，只有它能和CMS收集器(老年代收集器)配合工作。随着处理器核心数越来越多，parnew比serial有着更好的性能。(但如果是单核心处理器，parnew一定不会比serial有更好的性能)
三、parallel scavenge收集器
新生代收集器，基于标记复制算法实现，并行收集，Parallel Scavenge的诸多特性从表面上看和ParNew非常相似。Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。
高吞吐量意味着最高效率的运行计算机资源，尽快完成计算任务，主要用在后台运算而不需要太多交互的分析任务。
四、serial old收集器
Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记-整理算法。和serial一样，它的主要作用也是曾经供客户端模式下hotspot虚拟机使用。在服务端，它可以和Parallel Scavenge配合使用，也可以作为CMS失败的备选方案。
五、parallel old收集器
Parallel Old是Parallel Scavenge收集器的老年代版本，支持多线程并发收集，基于标记-整理算法实现。在它 出现之前Parallel Scavenge不能与CMS搭配使用，所以只能与serial old搭配使用，这样的吞吐量不一定有parallel new 搭配CMS高。但是当parallel old出现之后，在注重 吞吐量或者处理器资源较为稀缺的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器这个组合。
六、CMS收集器
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。CMS非常适合互联网网站或者基于浏览器的B/S系统，因为可以使响应时间尽可能短，提供给用户良好的交互体验。CMS是基于标记-整理算法实现的，它的过程有四个步骤：初始标记-并发标记-重新标记-并发清除
在初始标记和重新标记的过程都发生了"stop the world"。
初始标记时间很短，就是标记一下GC roots能直接关联到的对象。
并发标记时间比较长，是从GC roots直接关联到的对象开始遍历整个对象图。这个过程是和用户进程并发进行的。
重新标记是为了修正并发标记过程中因用户程序继续运行而导致标记发生变动的那一部分对象标记记录。这个过程会比初始标记长一点，但也远比并发标记时间短。
并发清除阶段就是清理删除掉标记阶段判断已经死亡的对象，由于不需要移动存活的对象，所以也可以和用户进程并发进行。CMS收集器是 HotSpot虚拟机追求低停顿的第一次成功尝试，但它还是有三个明显的缺点的：1、对处理器资源非常敏感。在并发阶段会占用一些性能，导致应用程序变慢。CMS默认启动的回收线程数是（处理器核心数量 +3）/4，当处理器的核心数小于4个时，CMS对用户程序的影响就会变得很大。为了应对这种情况，虚拟机提供了一种称为"增量式并发收集器"（Incremental Concurrent Mark Sweep/i-CMS）的CMS收集器变种，这会使垃圾收集的过程变长，用户程序受到的影响小一点。
2、然后，由于CMS收集器无法处理"浮动垃圾"（Floating Garbage），有可能出现"Con-current Mode Failure"失败进而导致另一次完全"Stop The World"的Full GC的产生。(浮动垃圾：在进行并发标记和并发清理时，用户程序产生的垃圾，但它们是出现在标记过程结束后，只能留到下一次垃圾收集再被清理。) 同样也是由于在垃圾收集阶段用户线程还需要持续运行，那就还需要预留足够内存空间提供给用户线程使用，因此CMS收集器不能像其他收集器那样等待到老年代几乎完全被填满了再进行收集，必须预留一部分空间供并发收集时的程序运作使用。在JDK 5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，到了JDK6这个值被提升到了92%，这可以降低回收的频率。但面对的风险是：如果CMS运行期间预留的内存不够用户程序运行，则会并发失败，虚拟机不得不停止用户程序，使用serial old进行老年代的垃圾回收。
3、CMS是一款基于"标记-清除"算法实现的收集器，这会导致内存中有大量的碎片空间。这就会出现往往老年代还有很多剩余空间，但却无法找到足够大的连续空间来分配当前对象，而不得不触发一次full GC。CMS收集器提供了一个-XX：+UseCMS-CompactAtFullCollection开关参数，来使CMS收集器不得不进行Full GC时开启内存碎片的合并整理过程，不过整理内存会移动存活对象不能进行并发，这又使用户停顿时间变长。因此虚拟机设计者们还提供了另外一个参数-XX：CMSFullGCsBefore- Compaction，这个参数是在CMS经历过若干次不用整理内存的full GC后，下次full GC前进行内存整理。
七、Garbage First收集器
Garbage First（简称G1）收集器是垃圾收集器技术发展历史上的里程碑式的成果，它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式。G1收集器是把Java堆划分为多个大小相等独立区域(region)，每个region都可以根据需要去扮演新生代的survivor、eden或者老年代，收集器也根据它们扮演的不同角色采取不同的策略。
对于大小超过Region容量一半的对象，都被认为是大对象，它们都被放在特定的Humongous区域，一般把这个区域当成老年代来看待。
Region是单次回收的最小单位，后台维护一个优先级队列，存储着每个Region回收的价值，每次根据最大停顿时间去优先回收那些价值更高的Region。
G1收集器存在的一些技术难题：
1、将Java堆分成了多个Region，里面存在跨Region引用对象。可以使用记忆集避免全堆作为GC Roots扫描，不过每个Region都要维护自己的记忆集。
2、在并发标记阶段保证收集线程与用户线程互不干扰。CMS采用的是增量更新算法实现，G1 收集器则是通过原始快照（SATB）算法来实现的。G1收集器设计了两个名为TAMS（Top at Mark Start）的指针，在并发回收时新分配的对象都要在这两个指针之上，这也就不会标记到新分配的对象。当回收速度小于分配速度导致没有空间分配给新对象时，也会导致full GC
3、建立一个可靠的停顿预测模型。G1收集器是以衰减平均值来实现停顿预测模型的。衰减平均值更意味着最近的平均值，也就是越新的统计状态权重越高。
G1收集器的回收过程大致分为四个阶段：初始标记、并发标记、最终标记、筛选回收。
初始标记：标记一下GC Roots能直接关联到的对象，并修改TAMS指针的值
并发标记：递归扫描整个堆里的对象，找出需要进行回收的对象，这个过程耗时较长，但是可以和用户线程并发进行。还要重新处理SATB记录下在并发阶段有变动的对象引用。
最终标记：处理并发标记结束后仍遗留下来的少量SATB记录。
筛选回收：对各个Region的回收价值和成本进行分析，根据用户预期停顿时间制作回收计划。把决定回收的Region的存活对象复制到其他空的Region中，然后再把决定回收的Region全部清理。
一般来讲，小内存的应用CMS性能会优于G1，大内存的应用反之，这个Java堆容量堆平衡点大概在6-8GB之间。
八、收集器的权衡
一般进行收集器的选择时，主要考虑三方面：应用程序所注重的点是什么，运行应用的硬件情况，使用的JDK版本
比如是面向用户的B/S系统，那么低延迟就比较重要。如果有预算但没有调优经验，就适合商业技术支持的专有解决方案，可以使用C4收集器；如果没有足够预算就可以试试ZGC。
如果接手的是遗留系统，JDK版本比较低，就可以根据堆内存大小选择收集器，在4-6GB可以选择CMS，更大内存就可以选择G1。