HotSpot 垃圾回收算法实现

标签: java JVM 垃圾回收 | 发表时间:2013-11-05 15:25 | 作者:coderbee
出处:http://coderbee.net

《深入理解Java虚拟机:JVM高级特性与最佳实践》-笔记

垃圾回收算法

枚举根结点

一致性

在可达性分析期间整个系统看起来就像被冻结在某个时间点上,不可以出现分析过程中对象引用关系还在不断变化的情况。

一致性要求导致GC进行时必须停顿所有Java执行线程。(Stop The World)
即使在号称不会发生停顿的CMS收集器中,枚举根节点时也是必须停顿的。

HotSpot使用的是准确式GC,当执行系统停顿下来后,并不需要一个不漏地检查完所有执行上下文和全局的引用位置,这是通过一组称为OopMap的数据结构来达到的。

在类加载完成后,HotSpot就把对象内什么偏移量上是什么类型的数据计算出来;在JIT编译过程中,也会在特定的位置记录下栈和寄存器中哪些位置是引用。

安全点(Safe Point)

程序只有在到达安全点时才能暂停。安全点的选定标准是“是否具有让程序长时间执行的特征”。“长时间执行”的最明显特征就是指令序列的复用,如方法调用、循环跳转等,具有这些功能的指令才会产生安全点。

让程序暂停的两种方式

  • 抢先式中断(Preemptive Suspension):在GC发生时,主动中断所有线程,不需要线程执行的代码主动配合。几乎不被采用。

  • 主动式中断(Voluntary Suspension):设一个标志,各个线程主动去轮询这个标志,遇到中断则暂停。轮询地方与安全点重合。

安全区域(Safe Region)

指在一段代码片段中,引用关系不会发生变化。在这个区域的任意地方开始GC都是安全的。

线程执行到安全区域中的代码时,首先标识自己进入了安全区域;在离开安全区域时,要检查系统是否已经完成了枚举根节点(或整个GC过程),完成了就继续执行,否则必须等待直到收到可以安全离开Safe Region的信号。

安全区域是为了解决线程Sleep或Blocked状态的。

垃圾收集器

前面的垃圾收集算法是理论,垃圾收集器则是具体的实现。

下图是HotSpot里的收集器,中间的横线表示分代,有连线表示可以组合使用。

Serial 收集器

是一个单线程的收集器,只能使用一个CPU或一条线程去完成垃圾收集;在进行垃圾收集时,必须暂停所有其他工作线程,直到收集完成。

Serial/Serial Old 收集器运行示意图:
Serial_gc_runtime

缺点:Stop-The-World。

优势:简单。对于但CPU的情况,由于没有多线程交互开销,反而可以更高效。

是Client模式下默认的新生代收集器。

ParNew 收集器

是Serial收集器的多线程版本。

ParNew/Serial Old 收集器运行示意图:
ParNew_gc_runtime

垃圾收集语境下的并发与并行概念

  • 并行(Parallel):指多条垃圾收集线程并行工作,用户线程仍然处于等待状态。
  • 并发(Concurrent):用户线程与垃圾收集线程同时执行。

Parallel Scavenge 收集器

新生代收集器,使用复制算法、并行的多线程收集器。

Parallel Scavenge 收集器的目标是达到一个可控制的吞吐量(Throughput)。这里的吞吐量是指CPU用于运行用户代码的时间与CPU总消耗时间的比值。主要适合在后台运算而不需要太多交互的任务。

Parallel Scavenge 收集器允许采用GC自适应的调节策略,也就是让虚拟机根据收集到的运行时数据自行决定各个分代的大小等与垃圾回收有关的配置。

Serial Old 收集器

用于老年代的Serial收集器,单线程,使用“标记-整理”算法。

SerialOld_gc_runtime

主要在Client模式下使用。

Parallel Old 收集器

Parallel Scavenge的老年代版本,多线程,使用“标记-整理”算法。

ParallelOld_gc_runtime

CMS 收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。基于“标记-清除”算法。

CMS_gc_runtime

运作过程分为4个阶段:

  • 初始标记(CMS initial mark):值标记GC Roots能直接关联到的对象。
  • 并发标记(CMS concurrent mark):进行GC RootsTracing的过程。
  • 重新标记(CMS remark):修正并发标记期间因用户程序继续运行而导致标记发生改变的那一部分对象的标记。
  • 并发清除(CMS concurrent sweep):

其中标记和重新标记两个阶段仍然需要Stop-The-World,整个过程中耗时最长的并发标记和并发清除过程中收集器都可以和用户线程一起工作。

CMS收集器对CPU资源非常敏感。

浮动垃圾(Floating Garbage):由于CMS并发清理阶段用户线程还在运行着,自然会有新的垃圾产生,而这些垃圾是在标记过程之后,CMS只能在下次GC时回收它们,这些垃圾就称为浮动垃圾。

CMS收集器无法处理浮动垃圾,可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。

在垃圾收集阶段用户线程还在运行,因此需要预留足够的内存给用户线程使用。如果预留内存不能满足用户线程,会出现“Concurrent Mode Failure”,这时虚拟机将启动临时后备预案:临时启用Serial Old收集器来重新进行老年代的垃圾收集。

由于CMS使用的是清除算法,会导致内存碎片问题,因此提供了参数用于控制是否在进行FullGC后进行内存整理,还提供了参数用于控制在多少次FullGC时才进行内存整理。内存整理是不能并发的,也就是要暂停所有用户线程。

G1 收集器

G1(Garbage First):是一款面向服务端应用的垃圾收集器,用于替换CMS收集器。

G1_gc_runtime

G1将整个Java堆划分为大小相等的独立区域(Region);新生代和老年代不再是物理隔离的,都由一组不连续的Region组成。

G1的特点:

  • 并行与并发:充分利用多CPU缩短Stop-The-World停顿时间,在收集过程中用并发的方式让Java线程继续执行。
  • 分代收集:仍然有分代的概念,不需要其他收集器配合,独立管理整个GC堆。
  • 空间整合:从整体看,是基于“标记-整理”算法实现的,从局部(两个Region之间)看是基于“复制”算法的。在运行期间不会产生内存碎片。
  • 可预测的停顿:G1跟踪各个Region里垃圾堆积值的价值大小,维护一个优先级队列,每次根据允许的时间,优先回收价值最大的Region。(这也是Garbage First的由来)

Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用,虚拟机都是使用Remembered Set来避免全堆扫描的。

G1中每个Region都有一个与之对应的Remembered Set,虚拟机发现程序对引用类型的数据进行写操作时,会产生一个Write Barrier暂时中断写操作,检查引用的对象是否处于不同的Region中(在其他收集器中就是检查是否老年代中的对象引用了新生代中对象),如果是,通过CardTable把相关引用信息记录到 被引用对象所属的Region的Remembered Set中。进行内存回收时,在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

G1垃圾回收主要有4个阶段:

  • 初始标记:只标记GC Roots能直接关联到的对象,并且修改TAMS(Next Top at Mark Start)值,让下一阶段用户程序并发运行时,能在正确可用的Region中创建新对象。此阶段需要暂停用户线程。
  • 并发标记:从GC Roots开始对堆中对象进行可达性分析,找出存活对象;耗时较长,可与用户线程并发执行。
  • 最终标记:修正在并发标记期间有变动的标记记录。
  • 刷选回收:对各个Region的回收价值和成本进行排序,根据用户期望的GC停顿时间制定回收计划,进行垃圾回收。

内存分配与回收规则

内存分配与回收规则由垃圾回收器和内存有关参数决定,不是固定的。

两个概念:

  • MinorGC,次收集:在新生代发生的垃圾收集,速度快,发生频繁。
  • FullGC,MajorGC,主收集:发生在年老代的垃圾收集。一般伴随一次MinorGC。

一般的规则:

  • 对象优先在Eden分配。当Eden没有足够的空间时,虚拟机将发起一次MinorGC。

  • 大对象直接进入老年代。大对象是指需要连续内存空间的Java对象。目的是避免在Eden区及两个Survivor区之间大量的内存复制(新生代采用复制算法收集内存)。

  • 长期存活对象将进入老年代。虚拟机给每个对象定义一个对象年龄计数器,如果对象在Eden出生并经过一次Minor GC后仍然存活,并且能够被Survivor容纳,将被移动到Survivor空间,并且对象年龄设为1。对象在Survivor区中每“熬过”一次MinorGC,年龄就加1,达到某个阀值就晋升到年老代。

  • 空间分配担保。在发生Minor GC之前,虚拟机会先检查年老代最大可用的连续空间算法大于新生代所有对象总空间,如果是,那么Minor GC可以确保是安全的。如果否,虚拟机会查看HandlePromotionFailure设置是否允许担保失败。如果允许继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小,如果大于,将尝试进行一次Minor GC,这是有风险的(存活对象占用的内存大于平均大小,将导致HandlePromotionFailure失败,重新发起一次Full GC);如果小于或者HandlePromotionFailure设置不允许冒险,将改为Full GC。

相关 [hotspot 垃圾回收 算法] 推荐:

HotSpot 垃圾回收算法实现

- - 码蜂笔记
《深入理解Java虚拟机:JVM高级特性与最佳实践》-笔记. 在可达性分析期间整个系统看起来就像被冻结在某个时间点上,不可以出现分析过程中对象引用关系还在不断变化的情况. 一致性要求导致GC进行时必须停顿所有Java执行线程. 即使在号称不会发生停顿的CMS收集器中,枚举根节点时也是必须停顿的. HotSpot使用的是准确式GC,当执行系统停顿下来后,并不需要一个不漏地检查完所有执行上下文和全局的引用位置,这是通过一组称为OopMap的数据结构来达到的.

JVM 垃圾回收算法

- - 码蜂笔记
《深入理解Java虚拟机:JVM高级特性与最佳实践》-笔记. 垃圾回收,Garbage Collection,简称GC. 判断对象是否存活一般有两种方式:. 引用计数:每个对象有一个引用计数属性,新增一个引用时计数加1,引用释放时计数减1,计数为0时可以回收. 此方法简单,无法解决对象相互循环引用的问题.

Java/JVM垃圾回收机制和算法总结

- - ITeye博客
Java垃圾回收器是Java虚拟机(JVM)的三个重要模块(另外两个是解释器和多线程机制)之一,为应用程序提供内存的 自动分配(Memory Allocation)、自动回收(Garbage Collect)功能,这两个操作都发生在Java堆上(一段内存快). 某一个时点,一个对象如果有一个以上的引用(Rreference)指向它,那么该对象就为活着的(Live),否则死亡(Dead),视为垃圾,可被垃圾回收器回收再利用.

推荐!可视化垃圾回收算法

- - 博客园_知识库
  英文原文: http://spin.atomicobject.com/2014/09/03/visualizing-garbage-collection-algorithms/.   大部分开发者都认为自动垃圾回收器是理所当然的. 实际上,这只是语言运行时提供的一项实用功能,旨在简化我们的开发工作.

JVM垃圾回收算法 总结及汇总

- - 编程语言 - ITeye博客
先看一眼JVM虚拟机运行时的内存模型:. 1.方法区 Perm(永久代、非堆). 3.本地方法栈 (Native方法). 1 首先的问题是:jvm如何知道那些对象需要回收. 两种标识算法、三种回收算法、两种清除算法、三种收集器. 每个对象上都有一个引用计数,对象每被引用一次,引用计数器就+1,对象引用被释放,引用计数器-1,直到对象的引用计数为0,对象就标识可以回收.

jvm垃圾回收

- Cano - 淘宝共享数据平台 tbdata.org
在jvm中堆空间划分为三个代:年轻代(Young Generation)、年老代(Old Generation)和永久代(Permanent Generation). 年轻代和年老代是存储动态产生的对象. 永久带主要是存储的是java的类信息,包括解析得到的方法、属性、字段等等. 我们这里讨论的垃圾回收主要是针对年轻代和年老代.

Java中的垃圾回收

- - Java译站
前文中对标记删除算法的介绍更多还是偏理论性质的. 实践中,为了更好地满足现实的场景及需求,还需要对算法进行大量的调整. 举个简单的例子,我们来看下JVM需要记录哪些信息才能让我们得以安全地分配对象空间. 碎片及整理(Fragmenting and Compacting). JVM在清除不可达对象之后,还得确保它们所在的空间是可以进行复用的.

Java垃圾回收调优

- - 编程语言 - ITeye博客
在Java中,通常通讯类型的服务器对GC(Garbage Collection)比较敏感. 通常通讯服务器每秒需要处理大量进出的数据包,需要解析,分解成不同的业务逻辑对象并做相关的业务处理,这样会导致大量的临时对象被创建和回收. 同时服务器如果需要同时保存用户状态的话,又会产生很多永久的对象,比如用户session.

谈谈ActionScript垃圾回收(下)

- Tomyail - Kevin Cao's Blog
前文我们介绍了GC的工作机制和帮助GC更好工作的最佳实践. 其实只要我们遵守谁创建谁清理的原则来管理对象,就能基本上避免回收失败,也就是我们通常说的内存泄漏问题. 但是在实际项目中我们还会看到各种原因引起的内存泄漏,接下来就让我们一起来找出病因. 首先我们需要观察症状,也就是内存的使用曲线. 排查的方法是反复执行一些创建和删除对象的方法、反复加载和卸载子文件.

谈谈ActionScript垃圾回收(上)

- Jia - Kevin Cao's Blog
在《给AS程序员的一点建议一文》中我提到了释放资源的重要性. 最近在一些项目过程中我又对这方面有了更多的理解,在此希望能够分享给大家. 首先让我们来回顾一下关于垃圾回收(Garbage Collection,下文简称GC)的一些知识. 要阅读本文,你需要对GC机制有些基本认识. 在ActionScript中,我们没有API可以直接删除一个对象,也不能控制Player进行GC.