JVM(四)分代回收机制及垃圾回收算法

垃圾回收机制及算法

垃圾回收基础知识

什么是GC

  Java与C++等语言最大的技术区别:自动化的垃圾回收机制(GC)
  为什么要了解GC和内存分配策略?
1.面试需要
2.GC对应用的性能是有影响的
3.写代码有好处
栈: 栈中的生命周期是跟随线程的,所以一般不需要关注
堆: 堆中的对象是垃圾回收的重点
方法区/元空间: 这一块也会发生垃圾回收,不过这块的效率比较低,一般不是我们需要关注的重点

分代回收理论

  当前商业虚拟机的垃圾回收器,大多数遵循"分代收集"的理论来进行设计,这个理论大体上是这么描述的:

1. 绝大部门的对象都是朝生夕死
2. 熬过越多次垃圾回收的对象,就越是难回收
   根据以上两个理论,朝生夕死的对象放在一个区域,难回收的对象放另外一个区域,这个就构成了新生代和老年代.
   

GC分类

  市面上发生垃圾回收的叫法很多,大体整理一下:

1. 新生代回收(Minor GC/Young GC):指只是进行新生代的回收.
2. 老年代回收(Major GC/Old GC): 指只是进行老年代的回收,目前只有CMS垃圾回收器会有这个单独回收老年代的行为.(Major GC 定义是比较混乱的,有说指是老年代,有的说是整个堆的收集,这个需要你根据别人的场景来定,没有固定的说话)
3. 整堆回收(Full GC): 收集整个java堆和方法区(注意包含方法区)
   
   

垃圾回收算法

  垃圾回收算法的实现涉及到大量的程序细节,并且每一个平台的虚拟机操作内存的方式都有不同,所以不需要去了解算法的实现,我们重点讲解3中算法的思想

复制算法(Copying)

将可用内存按容量划分为大小相等的两块,每次只使用其中的一块.当这一块的内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已使用过的内存空间一次清理掉.这样每次都是对整个半区进行内存回收,内存分配时也就不用考虑内存碎片等复杂情况,只按顺序分配内存即可,实现简单,运行高效,这是这种算法的代价是将内存缩小为了原来的一半
  但是要注意: 内存移动是必须实打实的移动(复制),所以对应的引用(直接指针)需要进行调整.
  复制回收算法适合于新生代,因大部分对象朝生夕死,那么复制过去的对象比较少,效率自然就高,另外一半的一次性清理是很快的

Appel式回收

  一种更加优化的复制回收分代策略: 具体做法是分配一块较大的Eden区和两块较小的Survivor 空间(你可以叫做From或者To,也可以叫做Survivor1 和 Survivor2)
  专门研究表明,新生代中的对象98%是"朝生夕死"的,所以并不需要按照1:1 的比例来划分内存空间,而是将内存分为一块较大的Eden 空间和两块较小的 Survivor 空间,每次使用Eden 和其中一块 Survivor.当回收时,将Eden和Survivor中还存活着的对象一次性地复制到另外一块 Survivor空间上,最后清理掉Eden 和 刚才用过的 Survivor 空间
   HotSpot 虚拟机默认Eden 和 Survivor 的大小比例是8:1:1,也就是每次新生代中可用内存空间为整个新生代容量的90%(80%+10%),只有10%的内存会被"浪费".当然,98%的对象可回收只是一般场景下的数据,我们没有办法保证每次回收都只有不多于10%的对象存活,当Survivor 空间不够用时,需要依赖其他内存(这里指 老年代)进行分配担保(Handle Promotion)

标记-清除算法(Mark-Sweep)

  算法分为"标记"和"清除"两个阶段: 首先扫描所有对象标记出需要回收的对象,在标记完成后扫描回收所有被标记的对象,所以需要扫描两遍.
  收回效率略低,如果大部分对象是朝生夕死,那么回收效率低,因为需要大量标记对象和回收对象,对比复制回收效率要低
  它的主要问题,标记清除之后会产生大量不连续的内存碎片,内存碎片太多可能会导致以后在程序运行过程中需要分配较大对象时,无法找到足够的连续内存而不得不提前触发另一次垃圾回收的动作

标记-整理算法(Mark-Compact)

  首先标记出所有需要回收的对象,在标记完成后,后续步骤不是直接可回收对象进行清理,而是让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存.标记整理算法虽然没有内存碎片,但是效率偏低.
  我们看到标记整理与标记清除算法的区别主要在于对象的移动.对象移动不单单会加重系统负担,同时需要全程暂停用户线程才能进行,同时所有引用对象的地方都需要更新(直接指针需要调整)
  所以看到,老年代采用的标记整理算法与标记清除算法,各有优点和缺点

JVM中常见的垃圾回收器

  新生代中,每次垃圾回收都发现有大量对象死去,只有少量存活,那就选用复制算法,只需要付出少量存活对象的复制成本就可以完成回收.
  而老年代中因为对象存活率高,没有额外空间对它进行分配担保,就必须使用"标记-清理"或者"标记-整理"算法来进行回收
请记住下图的垃圾收集器和之间的连线关系
Oracle官方也有对应的英文解释https://docs.oracle.com/en/java/javase/13/gctuning/ergonomics.html#GUID-DB4CAE94-2041-4A16-90EC-6AE3D91EC1F1
(比较难理解,基于java13的)

Serial/Seri Old

  JVM刚诞生就只有这两种,最古老的,单线程,独占式,成熟,适合单CPU,一般用在客户端模式下.
  这种垃圾回收器只适合几十兆到一两百兆的堆空间进行垃圾回收(可以控制停顿时间在100ms左右),但是对于超过这个大小的内存回收速度很慢 ,所以对于现在来说这个垃圾回收器已经是一个鸡肋.
Serial 垃圾回收器工作示意图

参数设置

-XX:+UseSerialGC 新生代和老年代都用串行收集器

Stop The World(STW)

  单线程进行垃圾回收时,必须暂停所有的工作线程,直到它回收结束,这个暂停称之为"Stop The World",但是这种STW带来了恶劣的用户体验,例如:应用每运行一个小时就需要暂停响应5分钟.这个也是早期JVM和Java被C/C++语言诟病性能差的一个重要原因.所以JVM开发团队一直努力消除或降低STW的时间

Parallel Scavenge(Parallel GC)/Parallel Old

  为了提高回收效率,从JDK1.3开始,JVM使用了多线程的垃圾回收机制,关注吞吐量的垃圾收集器,高吞吐量则可以高效率地利用CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务.
  所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值,即吞吐量 = 运行用户代码时间/(运行用户代码时间+垃圾收集时间),虚拟机总共运行了100分钟,其中垃圾收集花掉了1分钟,那吞吐量就是99%
  该垃圾回收器适合回收堆空间 上百兆~几个G

参数设置

开启参数

  JDK1.8 默认就是以下组合
-XX:+UseParallelGC 新生代使用 Parallel Scavenge，老年代使用 Parallel Old
  收集器提供了两个参数用于精确控制吞吐量，分别控制的停顿时间的-XX:MaxGCPauseMillis 参数以及直接设置吞吐量大小的-XX:GCTimeRatio 参数。
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

-XX:MaxGCPauseMillis

  不过大家不要异想天开的认为如果把这个参数的值设置的更小一点就能使得系统的垃圾收集速度变的更快,垃圾收集停顿时间缩短是以牺牲吞吐量和新生代空间为代价换取的:系统吧新生代调的小一点,收集300MB新生代肯定比收集500MB快,但这也直接导致垃圾收集发生得更频繁,原来10秒收集一次,每次停顿100毫秒,现在变成5秒收集一次,每次停顿70毫秒.停顿的时间的确在下降,但吞吐量也降下来了.

-XX:GCTimeRatio

  -XX:GCTimeRatio参数的值则应当是一个大于0小于100的整数,也就是垃圾收集时间占总时间的比率,相当于吞吐量的倒数
  例如: 把此参数设置为19,那允许的最大垃圾收集时间占用总时间的5%(即1/(1+19)),默认值为99,即运行最大1%(即1/(1+99))的垃圾收集时间
  由于与吞吐量关系密切,parallelScavenge 是"吞吐量优先垃圾回收器"

-XX:+UseAdaptiveSizePolicy

  -XX:+UseAdaptiveSizePolicy （默认开启）。这是一个开关参数， 当这个参数被激活之后，就不需要人工指定新生代的大小(-Xmn)、Eden 与 Survivor 区的 比例(-XX:SurvivorRatio)、 晋升老年代对象大小(-XX:PretenureSizeThreshold)等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调 整这些参数以提供最合适的停顿时间或者最大的吞吐量。

ParNew

  多线程垃圾回收器,与CMS进行配合,对于CMS(CMS只收回老年代),新生代垃圾回收器只有Serial与PerNew可选.ParNew和Serial基本没区别,唯一的区别: 多线程,多CPU的,停顿时间比Serial少(在JDK9以后,把ParNew 合并到了CMS)
大致了解下搭配关系即可,后续版本已经接近淘汰.

Concurrent Mark Sweep(CMS)

  收集器是一种以获取最短回收停顿时间为目标的收集器.目前很大一部分的Java应用集中在互联网或者B/S系统的服务端上,这类应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验.CMS收集器就非常符合这类应用的需求.
  从名字(包含"Mark Sweep")上就可以看出,CMS收集器是基于"标记-清除"算法实现的,它的运作过程相对于前面几种收集器来说更复杂一些,整个过程分为4个步骤,包括:

• 初始标记- 短暂,仅仅 知识标记了一下GC Roots能直接关联到的对象,速度很快
• 并发标记- 和用户的应用程序同时进行,进行GC Roots 追踪的过程,标记从GC Roots开始关联的所有对象开始遍历整个可达分析路径的对象.这个时间较长,所以采用并发处理(垃圾回收器线程和用户线程同时工作)
• 重新标记- 短暂,为了修正并发标记期间因用户线程继续运作而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间一般会比初始标记阶段稍长一些,但远比并发标记的时间短
• 并发清除 由于整个过程耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作,所以,从总体上来说,CMS 收集器的内存回收过程是与用户线程一起并发执行的
  -XX:+UseConcMarkSweepGC ，表示新生代使用 ParNew，老年代的用 CMS

CMS中的问题

cpu敏感: CMS对处理器资源敏感,毕竟采用了并发的收集,当核心处理器不足4个时,CMS对用户的影响较大
浮动垃圾: 由于CMS并发清理阶段用户线程还在运行着,伴随程序运行自然就还会有新的垃圾不断产生,这一部分垃圾出现在标记过程之后,CMS无法在当次收集中处理掉它们,只好留待下一次GC时再清理掉.这一部分垃圾就称为"浮动垃圾".
  由于浮动垃圾的存在,因此需要预留出一部分内存,意味着CMS收集不能像其它收集器那样等待老年代快满的时候再进行回收.
  在1.6的版本中老年代空间使用率阈值(92%)
  如果预留的内存不够存放浮动垃圾,就会出现Concurrent Mode Failure,这时虚拟机将临时启用Serial Old来代替 CMS.
会产生空间碎片: 标记-清除算法会导致产生不连续的空间碎片
  总体来说,CMS是JVM推出的第一款并发垃圾收集器,所以还是非常有代表性
  但是最大的问题是CMS采用了标记清除算法,所以会有内存碎片,当碎片较多时,给大对象的分配带来很大的麻烦,为了解决这个问题,CMS提供一个参数:-XX:+UseCMSCompactAtFullCollection，一般是开启的，如果分配不了大对象，就进行内存碎片的整理过程。
  这个地方一般会使用Serial Old,因为Serial Old是一个单线程,所以如果内存空间很大,且对象较多时,CMS发生这样情况会很卡

CMS总结

  CMS问题比较多,所以现在没有一个版本默认是CMS,只能手工指定.但是它毕竟是第一个并发垃圾回收器,对于了解并发垃圾回收具有一定意义,所以我们必须了解.
  为什么CMS采用标记-清除
在实现并发的垃圾回收时,如果采用标记整理算法,那么还涉及到对象的移动(对象的移动必定涉及到引用的变化,这个需要暂停业务线程来处理栈信息,这样使得并发收集的暂停时间更长),所以使用简单的标记-清除算法才可以降低CMS的STW时间
  该垃圾回收器适合回收堆空间几个G~200G左右.
  在JDK1.8中,配置参数:
-XX:+UseConcMarkSweepGC
  为老年代启用 CMS 垃圾收集器。当吞吐量 ( -XX:+UseParallelGC) 垃圾收集器无法满足应用程序延迟要求时，Oracle 建议您使用 CMS 垃圾收集器。G1 垃圾收集器 ( -XX:+UseG1GC) 是另一种选择。
  默认情况下，此选项处于禁用状态，并根据机器的配置和 JVM 的类型自动选择收集器。当启用该选项时，-XX:+UseParNewGC选项将自动设置，你不应该禁用它，因为下面的选项组合已经在JDK 8被弃用：-XX:+UseConcMarkSweepGC -XX:-UseParNewGC。

Garbage First(G1)

设计思想

  随着JVM中内存的增大,STW的时间称为JVM急迫解决的问题,但是如果按照传统的分代模型,总跳不出STW时间不可预测这点.
  为了实现STW的时间可预测,首先要有一个思想上的改变.G1将堆内存"化整为零",将堆内存划分成多个大小相等独立区域(Region),每一个Region都可以根据需要,扮演新生代的Eden空间,Survivor空间,或者老年代空间.回收器能够对扮演不同角色的Region采用不同的策略去处理,这样无论是新创建的对象还是已经存活了一段时间,熬过多次收集的旧对象都能获取很好的收集效果.

Region

  Region可能是Eden,也有可能是Survivor,也有可能是Old,另外Region中还有一类特殊的Humongous区域,专门用来存储大对象. G1 认为只要大小超过了一个Region 容量一半的对象即可判定为大对象. 每个Region的大小可以通过参数-XX:G1HeapRegionSize 设定,取值范围为 1MB~32MB,且应为2的N次幂.而对于哪些超过了整个Region 容量的超级大对象,将会被存放在 N 个连续的 Humongous Region之中,G1的进行回收大多数情况下都把Humongous Region 作为老年代的一部分来进行看待.

参数设置

开启参数

-XX:+UseG1GC

分区大小

-XX:G1HeapRegionSize

一般建议逐渐增大改值,随着size增加,垃圾的存活时间更长,GC间隔更长,但每次GC的时间也会更长.

最大GC暂停时间

MaxGCPauseMillis

运行过程

G1的运行过程大致可划分为以下四个步骤:
初始标记(Initial Marking)
  仅仅只是标记了一下GC Roots能直接关联到的对象,并且修改TAMS指针的值,让下一阶段用户线程并发执行时,能正确地在可用Region中分配新对象.这个阶段需要停顿线程,但耗时很短,而且是借用进行Minor GC的时候同步完成的,所以G1收集器在这个阶段实际并没有额外的停顿
TAMS是什么?
  要达到GC与用户线程并发运行,必须要解决回收过程中新对象的分配,所以G1为每一个Region区域设计了两个名为 TAMS(Top at Mark Start) 的指针,从Region 区域划出一部分空间 用于记录并发回收过程中的新对象.这样的对象认为它们是存活的,不纳入垃圾回收范围.
并发标记(Concurrent Marking)
  从GC Root 开始对堆中对象进行可达性分析,递归扫描整个堆里的对象图,找出要回收的对象,这阶段耗时较长,但可与用户程序并发执行.当对象图扫描完成以后,并发时有引用变动的对象,这些对象会漏标(后续再讲三色标记的时候回细讲这个问题),漏标的对象会被一个叫做SATB(snapshot-at-the-beginning)算法来解决(这个下一节会细讲)
最终标记(final Marking)
  对用户线程做另一个短暂的暂停,用于处理并发阶段结后仍遗留下来的最后那少量的SATB记录(漏标对象).
筛选回收(Live Data Counting and Evacuation)
  负责更新Region的统计数据,对各个Region的回收价值和成本进行排序,根据用户所期望的停顿时间来指定回收计划,可以自由选择任意多个Region构成回手集,然后把决定回收的那一部分Region的存活对象复制到空的Region中,在清理掉整个旧Region的全部空间.这里的操作涉及存活对象的移动,是必须暂停用户线程,由多条收集器线程并行完成的.

特点

并行与并发: G1能充分利用多CPU,多核环境下的硬件优势,使用多个CPU(CPU或者CPU核心)来缩短Stop-The-World停顿的时间,部分其他收集器原本需要停顿Java线程执行的GC动作,G1收集器仍然可以通过并发的方式让Java程序继续执行
分代收集: 与其他收集器一样,分代概念在G1中依然得以保留.虽然G1可以不需要其他收集器配合就能独立管理整个GC堆,但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间,熬过多次GC的旧对象以获取更好的收集效果.
空间整合: 与CMS的"标记-清理"算法不同,G1从整体来看是基于"标记整理"算法实现的收集器,从局部(两个Region之间)上来看是基于"复制"算法来实现的,但无论如何,这两种算法都意味着G1运作期间不会产生内存空间碎片,收集后能提供规整的可用内存.这种特性有利于程序长时间运行,分配大对象时不会因为无法找到连续内存空间而提取触发下一次GC.
追求停顿时间:
-XX:MaxGCPauseMillis 指定目标的最大停顿时间，G1 尝试调整新生代和老年代的比例，堆大小，晋升年龄来达到这个目标时间。
怎么玩?
该垃圾回收器适合回收堆空间上百 G。一般在 G1 和 CMS 中间选择的话平衡点在 6~8G，只有内存比较大 G1 才能发挥优势。

垃圾回收器整理

收集器	收集对象	算法	收集器类型	说明	适用场景
serial	新生代	复制算法	单线程		简单高效 适用内存不大的情况
ParNew	新生代	复制算法	并行的多线程收集器		搭配CMS垃圾回收器的首选
Parallel Scavenge	新生代	复制算法	并行的多线程收集器	类似ParNew,更加关注吞吐量,达到一个可控制的吞吐量	本身是Server级别 多CPU机器上的默认GC方式,主要适合后台运算不需要太多交互的任务
serial Old	老年代	标记整理算法	单线程		Client模式下oxia虚拟机使用
Parallel Old	老年代	标记整理算法	并行的多线程收集器	Parallel Scavenge 收集器的老年代版本,为了配合Parallel Scavenge的面向吞吐量的特性而开发的对应组合	在注重吞吐量以及CPU资源敏感的场合采用
CMS	老年代	标记清除算法	并行与并发收集器	尽可能的缩短垃圾收集时用户线程停止时间;缺点在于: 1.内存碎片 2.需要更多cpu资源 3.浮动垃圾问题,需要更大的堆空间	重视服务的响应速度,系统停顿时间和用户体验的互联网网站或者B/S系统.互联网后端目前cms是主流的垃圾回收器;
G1	跨新生代和老年代;	标记整理+化整为零	并行与并发收集器	JDK1.7才正式引入,采用分区回收的思维,基本不牺牲吞吐量的前提下完成低停顿的内存回收;可预测的停顿是其最大的优势	面向服务端应用的垃圾回收器,目标为取代CMS