以下哪些jvm的垃圾jvm回收算法方式采用的是复制算法jvm回收算法

找好工作,快人一步本部分,我们将关注堆(heap) 中一个主要区域,新生代(young generation)。首先我们会讨论为什么调整新生代的参数会对应用的性能如此重要,接着我们将学习新生代相关的JVM参数。
单纯从JVM的功能考虑,并不需要新生代,完全可以针对整个堆进行操作。新生代存在的唯一理由是优化垃圾回收(GC)的性能。更具体说,把堆划分为新生代和老年代有2个好处:简化了新对象的分配(只在新生代分配内存),可以更有效的清除不再需要的对象(即死对象)(新生代和老年代使用不同的GC算法)
通过广泛研究面向对象实现的应用,发现一个共同特点:很多对象的生存时间都很短。同时研究发现,新生对象很少引用生存时间长的对象。结合这2个特点,很明显 GC 会频繁访问新生对象,例如在堆中一个单独的区域,称之为新生代。在新生代中,GC可以快速标记回收”死对象”,而不需要扫描整个Heap中的存活一段时间的”老对象”。
SUN/Oracle 的HotSpot JVM 又把新生代进一步划分为3个区域:一个相对大点的区域,称为”伊甸园区(Eden)”;两个相对小点的区域称为”From 幸存区(survivor)”和”To 幸存区(survivor)”。按照规定,新对象会首先分配在 Eden 中(如果新对象过大,会直接分配在老年代中)。在GC中,Eden 中的对象会被移动到survivor中,直至对象满足一定的年纪(定义为熬过GC的次数),会被移动到老年代。
基于大多数新生对象都会在GC中被收回的假设。新生代的GC 使用复制算法。在GC前To 幸存区(survivor)保持清空,对象保存在 Eden 和 From 幸存区(survivor)中,GC运行时,Eden中的幸存对象被复制到 To 幸存区(survivor)。针对 From 幸存区(survivor)中的幸存对象,会考虑对象年龄,如果年龄没达到阀值(tenuring threshold),对象会被复制到To 幸存区(survivor)。如果达到阀值对象被复制到老年代。复制阶段完成后,Eden 和From 幸存区中只保存死对象,可以视为清空。如果在复制过程中To 幸存区被填满了,剩余的对象会被复制到老年代中。最后 From 幸存区和 To幸存区会调换下名字,在下次GC时,To 幸存区会成为From 幸存区。
上图演示GC过程,黄色表示死对象,绿色表示剩余空间,红色表示幸存对象
总结一下,对象一般出生在Eden区,年轻代GC过程中,对象在2个幸存区之间移动,如果对象存活到适当的年龄,会被移动到老年代。当对象在老年代死亡时,就需要更高级别的GC,更重量级的GC算法(复制算法不适用于老年代,因为没有多余的空间用于复制)
现在应该能理解为什么新生代大小非常重要了(译者,有另外一种说法:新生代大小并不重要,影响GC的因素主要是幸存对象的数量),如果新生代过小,会导致新生对象很快就晋升到老年代中,在老年代中对象很难被回收。如果新生代过大,会发生过多的复制过程。我们需要找到一个合适大小,不幸的是,要想获得一个合适的大小,只能通过不断的测试调优。这就需要JVM参数了
-XX:NewSize and -XX:MaxNewSize
就像可以通过参数(-Xms and -Xmx) 指定堆大小一样,可以通过参数指定新生代大小。设置 XX:MaxNewSize 参数时,应该考虑到新生代只是整个堆的一部分,新生代设置的越大,老年代区域就会减少。一般不允许新生代比老年代还大,因为要考虑GC时最坏情况,所有对象都晋升到老年代。(译者:会发生OOM错误) -XX:MaxNewSize 最大可以设置为-Xmx/2 .
考虑性能,一般会通过参数 -XX:NewSize 设置新生代初始大小。如果知道新生代初始分配的对象大小(经过监控) ,这样设置会有帮助,可以节省新生代自动扩展的消耗。
-XX:NewRatio
可以设置新生代和老年代的相对大小。这种方式的优点是新生代大小会随着整个堆大小动态扩展。参数 -XX:NewRatio 设置老年代与新生代的比例。例如 -XX:NewRatio=3 指定老年代/新生代为3/1. 老年代占堆大小的 3/4 ,新生代占 1/4 .
如果针对新生代,同时定义绝对值和相对值,绝对值将起作用。下面例子:
$ java -XX:NewSize=32m -XX:MaxNewSize=512m -XX:NewRatio=3 MyApp
以上设置, JVM 会尝试为新生代分配四分之一的堆大小,但不会小于32MB或大于521MB
在设置新生代大小问题上,使用绝对值还是相对值,不存在通用准则 。如果了解应用的内存使用情况,设置固定大小的堆和新生代更有利,当然也可以设置相对值。如果对应用的内存使用一无所知,正确的做法是不要设置任何参数,如果应用运行良好。很好,我们不用做任何额外动作.如果遇到性能或OutOfMemoryErrors, 在调优之前,首先需要进行一系列有目的的监控测试,缩小问题的根源。
-XX:SurvivorRatio
参数 -XX:SurvivorRatio 与 -XX:NewRatio 类似,作用于新生代内部区域。-XX:SurvivorRatio 指定伊甸园区(Eden)与幸存区大小比例. 例如, -XX:SurvivorRatio=10 表示伊甸园区(Eden)是 幸存区To 大小的10倍(也是幸存区From的10倍).所以,伊甸园区(Eden)占新生代大小的10/12, 幸存区From和幸存区To 每个占新生代的1/12 .注意,两个幸存区永远是一样大的..
设定幸存区大小有什么作用? 假设幸存区相对伊甸园区(Eden)太小, 相应新生对象的伊甸园区(Eden)永远很大空间, 我们当然希望,如果这些对象在GC时全部被回收,伊甸园区(Eden)被清空,一切正常.然而,如果有一部分对象在GC中幸存下来, 幸存区只有很少空间容纳这些对象.结果大部分幸存对象在一次GC后,就会被转移到老年代 ,这并不是我们希望的.考虑相反情况, 假设幸存区相对伊甸园区(Eden)太大,当然有足够的空间,容纳GC后的幸存对象. 但是过小的伊甸园区(Eden),意味着空间将越快耗尽,增加新生代GC次数,这是不可接受的。
总之,我们希望最小化短命对象晋升到老年代的数量,同时也希望最小化新生代GC 的次数和持续时间.我们需要找到针对当前应用的折中方案, 寻找适合方案的起点是 了解当前应用中对象的年龄分布情况。
-XX:+PrintTenuringDistribution
参数 -XX:+PrintTenuringDistribution 指定JVM 在每次新生代GC时,输出幸存区中对象的年龄分布。例如:
Desired survivor size
bytes, new threshold 15 (max 15)
- age 2: 79376 bytes,
- age 3: 2904256 bytes,
第一行说明幸存区To大小为 75 MB. 也有关于老年代阀值(tenuring threshold)的信息, 老年代阀值,意思是对象从新生代移动到老年代之前,经过几次GC(即, 对象晋升前的最大年龄). 上例中,老年代阀值为15,最大也是15.
之后行表示,对于小于老年代阀值的每一个对象年龄,本年龄中对象所占字节 (如果当前年龄没有对象,这一行会忽略). 上例中,一次 GC 后幸存对象大约 19 MB, 两次GC 后幸存对象大约79 KB , 三次GC 后幸存对象大约 3 MB .每行结尾,显示直到本年龄全部对象大小.所以,最后一行的 total 表示幸存区To 总共被占用22 MB . 幸存区To 总大小为 75 MB ,当前老年代阀值为15,可以断定在本次GC中,没有对象会移动到老年代。现在假设下一次GC 输出为:
Desired survivor size
bytes, new threshold 2 (max 15)
- age 3: 79376 bytes,
- age 4: 2904256 bytes,
对比前一次老年代分布。明显的,年龄2和年龄3 的对象还保持在幸存区中,因为我们看到年龄3和4的对象大小与前一次年龄2和3的相同。同时发现幸存区中,有一部分对象已经被回收,因为本次年龄2的对象大小为 12MB ,而前一次年龄1的对象大小为 19 MB。最后可以看到最近的GC中,有68 MB 新对象,从伊甸园区移动到幸存区。
注意,本次GC 幸存区占用总大小 84 MB -大于75 MB. 结果,JVM 把老年代阀值从15降低到2,在下次GC时,一部分对象会强制离开幸存区,这些对象可能会被回收(如果他们刚好死亡)或移动到老年代。
-XX:InitialTenuringThreshold, -XX:MaxTenuringThreshold and -XX:TargetSurvivorRatio
参数 -XX:+PrintTenuringDistribution 输出中的部分值可以通过其它参数控制。通过 -XX:InitialTenuringThreshold 和 -XX:MaxTenuringThreshold 可以设定老年代阀值的初始值和最大值。另外,可以通过参数 -XX:TargetSurvivorRatio 设定幸存区的目标使用率.例如 , -XX:MaxTenuringThreshold=10 -XX:TargetSurvivorRatio=90 设定老年代阀值的上限为10,幸存区空间目标使用率为90%。
有多种方式,设置新生代行为,没有通用准则。我们必须清楚以下2中情况:
1 如果从年龄分布中发现,有很多对象的年龄持续增长,在到达老年代阀值之前。这表示 -XX:MaxTenuringThreshold 设置过大
2 如果 -XX:MaxTenuringThreshold 的值大于1,但是很多对象年龄从未大于1.应该看下幸存区的目标使用率。如果幸存区使用率从未到达,这表示对象都被GC回收,这正是我们想要的。 如果幸存区使用率经常达到,有些年龄超过1的对象被移动到老年代中。这种情况,可以尝试调整幸存区大小或目标使用率。
-XX:+NeverTenure and -XX:+AlwaysTenure
最后,我们介绍2个颇为少见的参数,对应2种极端的新生代GC情况.设置参数 -XX:+NeverTenure , 对象永远不会晋升到老年代.当我们确定不需要老年代时,可以这样设置。这样设置风险很大,并且会浪费至少一半的堆内存。相反设置参数 -XX:+AlwaysTenure, 表示没有幸存区,所有对象在第一次GC时,会晋升到老年代。
没有合理的场景使用这个参数。可以在测试环境中,看下这样设置会发生什么有趣的事.但是并不推荐使用这些参数.
适当的配置新生代非常重要,有相当多的参数可以设置新生代。然而,单独调整新生代,而不考虑老年代是不可能优化成功的。当调整堆和GC设置时,我们总是应该同时考虑新生代和老年代。
在本系列的下面2部分,我们将讨论 HotSpot JVM 中老年代 GC 策略,我们会学习“吞吐量GC收集器” 和 “并发低延迟GC收集器”,也会了解收集器的基本准则,算法和调整参数.
相关 [jvm 新生代 垃圾回收] 推荐:
- Java - 编程语言 - ITeye博客
本部分,我们将关注堆(heap) 中一个主要区域,新生代(young generation). 首先我们会讨论为什么调整新生代的参数会对应用的性能如此重要,接着我们将学习新生代相关的JVM参数. 单纯从JVM的功能考虑,并不需要新生代,完全可以针对整个堆进行操作. 新生代存在的唯一理由是优化垃圾回收(GC)的性能.
- Cano - 淘宝共享数据平台 tbdata.org
在jvm中堆空间划分为三个代:年轻代(Young Generation)、年老代(Old Generation)和永久代(Permanent Generation). 年轻代和年老代是存储动态产生的对象. 永久带主要是存储的是java的类信息,包括解析得到的方法、属性、字段等等. 我们这里讨论的垃圾回收主要是针对年轻代和年老代.
- 码蜂笔记
《深入理解Java虚拟机:JVM高级特性与最佳实践》-笔记. 垃圾回收,Garbage Collection,简称GC. 判断对象是否存活一般有两种方式:. 引用计数:每个对象有一个引用计数属性,新增一个引用时计数加1,引用释放时计数减1,计数为0时可以回收. 此方法简单,无法解决对象相互循环引用的问题.
- kill - yiihsia[互联网后端技术]_yiihsia[互联网后端技术]
引用计数(Reference Counting). 原理是此对象有一个引用,即增加一个计数,删除一个引用则减少一个计数. 垃圾回收时,只用收集计数为0的对象. 此算法最致命的是无法处理循环引用的问题. 标记-清除(Mark-Sweep). 第一阶段从引用根节点开始标记所有被引用的对象,第二阶段遍历整个堆,把未标记的对象清除.
- CSDN博客架构设计推荐文章
由于不同对象的生命周期不一样,因此在JVM的垃圾回收策略中有分代这一策略. 本文介绍了分代策略的目标,如何分代,以及垃圾回收的触发因素. 文章总结了JVM垃圾回收策略为什么要分代,如何分代,以及垃圾回收的触发因素. 分代的垃圾回收策略,是基于这样一个事实:不同的对象的生命周期是不一样的. 因此,不同生命周期的对象可以采取不同的收集方式,以便提高回收效率.
- ITeye博客
Java垃圾回收器是Java虚拟机(JVM)的三个重要模块(另外两个是解释器和多线程机制)之一,为应用程序提供内存的
自动分配(Memory Allocation)、自动回收(Garbage Collect)功能,这两个操作都发生在Java堆上(一段内存快). 某一个时点,一个对象如果有一个以上的引用(Rreference)指向它,那么该对象就为活着的(Live),否则死亡(Dead),视为垃圾,可被垃圾回收器回收再利用.
- ITeye博客
在生产环境下,通常都需要对JVM进行参数优化,其中对垃圾回收器的参数优化是一个非常重要的一方面. 下面重点介绍Java的堆内存,垃圾回收算法,常用的垃圾回收器以及Java堆内存的分配策略,这些内容将作为对JVM进行垃圾回收参数优化的重要基础. 然后通过简单示例验证Java的垃圾回收机制.
- 编程语言 - ITeye博客
先看一眼JVM虚拟机运行时的内存模型:. 1.方法区 Perm(永久代、非堆). 3.本地方法栈 (Native方法). 1 首先的问题是:jvm如何知道那些对象需要回收. 两种标识算法、三种回收算法、两种清除算法、三种收集器. 每个对象上都有一个引用计数,对象每被引用一次,引用计数器就+1,对象引用被释放,引用计数器-1,直到对象的引用计数为0,对象就标识可以回收.
- 编程语言 - ITeye博客
在Java中,通常通讯类型的服务器对GC(Garbage Collection)比较敏感. 通常通讯服务器每秒需要处理大量进出的数据包,需要解析,分解成不同的业务逻辑对象并做相关的业务处理,这样会导致大量的临时对象被创建和回收. 同时服务器如果需要同时保存用户状态的话,又会产生很多永久的对象,比如用户session.
- Java译站
前文中对标记删除算法的介绍更多还是偏理论性质的. 实践中,为了更好地满足现实的场景及需求,还需要对算法进行大量的调整. 举个简单的例子,我们来看下JVM需要记录哪些信息才能让我们得以安全地分配对象空间. 碎片及整理(Fragmenting and Compacting). JVM在清除不可达对象之后,还得确保它们所在的空间是可以进行复用的.
坚持分享优质有趣的原创文章,并保留作者信息和版权声明,任何问题请联系:@。1490人阅读
一、对象存活判断
判断对象是否存活一般有两种方式:
1.引用计数:每个对象有一个引用计数属性,新增一个引用时计数加1,引用释放时计数减1,计数为0时可以回收。此方法简单,无法解决对象相互循环引用的问题。
2.可达性分析(Reachability Analysis):从GC Roots开始向下搜索,搜索所走过的路径称为引用链。当一个对象到GC Roots没有任何引用链相连时,则证明此对象是不可用的。不可达对象。
在Java语言中,GC Roots包括:
虚拟机栈中引用的对象。
方法区中类静态属性实体引用的对象。
方法区中常量引用的对象。
本地方法栈中JNI引用的对象。
二、JVM的垃圾回收过程
首先从GC Roots开始进行可达性分析,判断哪些是不可达对象。
对于不可达对象,判断是否需要执行其finalize方法,如果对象没有覆盖finalize方法或已经执行过finalize方法则视为不需要执行,进行回收;如果需要,则把对象加入F-Queue队列。
对于F-Queue队列里的对象,稍后虚拟机会自动建立一个低优先级的线程去触发其finalize方法,但不会等待这个方法返回。
如果在finalize方法的执行过程中,对象重新被引用,那么进行第二次标记时将被移出F-Queue,在finalize方法执行完成后,对象仍然没有被引用,则进行回收。
对于被移出F-Queue的对象,如果它下一次面临回收时,将不会再执行其finalize方法。
finalize方法只执行一次。
三、垃圾收集算法
1、引用计数(reference counting)
& & 原理:此对象有一个引用,则+1;删除一个引用,则-1。只用收集计数为0的对象。
& & 缺点:无法处理循环引用的问题。如:对象A和B分别有字段b、a,令A.b=B和B.a=A,除此之外这2个对象再无任何引用,那实际上这2个对象已经不可能再被访问,但是引用计数算法却无法回收他们。&
2、复制(copying)
& & 原理:把内存空间划分为2个相等的区域,每次只使用一个区域。垃圾回收时,遍历当前使用区域,把正在使用的对象复制到另外一个区域。
& & 优点:不会出现碎片问题。
& & 缺点:1、暂停整个应用。2、需要2倍的内存空间。
3、标记-清扫(Mark-and-sweep)---sun前期版本就是用这个技术。
& & 原理:对于“活”的对象,一定可以追溯到其存活在堆栈、静态存储区之中的引用。这个引用链条可能会穿过数个对象层次。第一阶段:从GC roots开始遍历所有的引用,对有活的对象进行标记。第二阶段:对堆进行遍历,把未标记的对象进行清除。这个解决了循环引用的问题。
& & 缺点:1、暂停整个应用;2、会产生内存碎片。
4、标记-压缩(Mark-Compact)自适应
& & 原理:第一阶段标记活的对象,第二阶段把为标记的对象压缩到堆的其中一块,按顺序放。
& & 优点:1、避免标记扫描的碎片问题;2、避免停止复制的空间问题。
& & 具体使用什么方法GC,Java虚拟机会进行监视,如果所有对象都很稳定,垃圾回收器的效率低的话,就切换到“标记-扫描”方式;同样,Java虚拟机会跟踪“标记-扫描”的效果,要是堆空间碎片出现很多碎片,就会切换回“停止-复制”模式。这就是自适应的技术。
5、分代(generational collecting)-----J2SE1.2以后使用此算法
& & 原理:基于对象生命周期分析得出的垃圾回收算法。把对象分为年轻代、年老代、持久代,对不同的生命周期使用不同的算法(2-3方法中的一个即4自适应)进行回收。
6、自适应算法(Adaptive Collector)
& & 在特定的情况下,一些垃圾收集算法会优于其它算法。基于Adaptive算法的垃圾收集器就是监控当前堆的使用情况,并将选择适当算法的垃圾收集器。
如上图所示:为Java的各代分布图
年轻代(young)
年轻代分三个区。一个Eden区,两个Survivor区。大部分对象在Eden区中生成。当Eden区满时,还存活的对象将被复制到Survivor区(两个中的一个),当这个Survivor区满时,此区的存活对象将被复制到另外一个Survivor区,当第二个Survivor区也满了的时候,从第一个Survivor区复制过来的并且此时还存活的对象,将被复制到tenured generation。需要注意,Survivor的两个区是对称的,没先后关系,所以同一个区中可能同时存在从Eden复制过来对象,和从前一个
Survivor复制过来的对象,而复制到年老区的只有从第一个Survivor去过来的对象。而且,Survivor区总有一个是空的。young generation的gc称为minor gc。经过数次minor gc,依旧存活的对象,将被移出young generation,移到tenured generation。
年老代(tenured)
& &存放从年轻代(young)复制过来的对象。生命周期较长的对象,归入到tenured generation。一般是经过多次minor gc,还依旧存活的对象,将移入到tenured generation。(当然,在minor gc中如果存活的对象的超过survivor的容量,放不下的对象会直接移入到tenured generation)。tenured generation的gc称为major gc,就是通常说的full gc。
& & 采用compaction算法。由于tenured generaion区域比较大,而且通常对象生命周期都比较长,compaction需要一定时间。所以这部分的gc时间比较长。
& & minor gc可能引发full gc。当eden+from space的空间大于tenured generation区的剩余空间时,会引发full gc。这是悲观算法,要确保eden+from space的对象如果都存活,必须有足够的tenured generation空间存放这些对象。
持久代(perm)
& & 用于存放静态文件,如Java类、方法等。持久代对垃圾回收没有显著的影响,但是有些应用可能动态生成或者调用一些class。持久代大小通过-XX:MaxPermSize=N进行设置
该区域比较稳定,主要用于存放classloader信息,比如类信息和method信息。
对于spring hibernate这些需要动态类型支持的框架,这个区域需要足够的空间。(这部分空间应该存在于方法区而不是heap中)。
四、Minor collections和Major collections&
Minor collection当young space被占满时执行。它比major collections快,因为minor collection仅仅检查major collection相应的一个子集对象。minor collection比major collection发生的频率高。
Major collection当tenured space被占满时执行。他会清理tenured和young。
Thinking in java给java gc取了一个罗嗦的称呼:“自适应、分代的、停止-复制、标记-扫描”式的垃圾回收器。
五、导致Gc的情况:
1、tenured被写满
2、perm被写满
3、System.gc()的显式调用。
4、上一次GC之后heap的各域分配策略动态变化。
六、GC运行的三种方式&
在java5和java6中有4中垃圾回收的算法,有一种算法将不再支持,剩余的三种垃圾回收算法是:serial, throughput and concurrent low pause。&
Stop the world(停止所有程序的方式):在这种方式运行的GC,在GC完成前,JVM中的所有程序都不允许运行。Serial collector此时做minor和major收集。Throughput collector此时做major collector。
Incremental(增量运行方式):目前没要Java GC算法支持这种运行方式。GC以这种方式运行时,GC允许程序做一小段时间的工作,然后做垃圾回收工作。
Concurrent(并行运行):Throughput collector此时做minor collect,Concurrent low pause collector此时做minor和major收集。在这种运行方式下,GC和程序并行的运行,因此程序仅仅被短暂的暂停。
七、关于finalize方法的问题&
finalize方法使得GC过程做了更多的事情,增加的GC的负担。
如果某个对象的finalize方法运行时间过长,它会使得其他对象的finalize方法被延迟执行。
finalize方法中如果创建了strong reference引用了其他对象,这会阻止此对象被GC。
finalize方法有可能以不可确定的顺序执行(也就是说要在安全性要求严格的场景中尽量避免使用finalize方法)。
不确保finalize方法会被及时调用,也许程序都退出了,但是finalize方法还没被调用。
八、对象引用的类型&
Reference(or named Strong Reference)( 强引用):普通类型的引用。
SoftReference( 软引用):被这种引用指向的对象,如果此对象没要再被其他Strong Reference引用的话,可能在任何时候被GC。虽然是可能在任何时候被GC,但是通常是在可用内存数比较低的时候,并且在程序抛出OutOfMemoryError之前才发生对此对象的GC。SoftReference通常被用作实现Cache的对象引用,如果这个对象被GC了,那么他可以在任何时候再重新被创建。另外,根据JDK文档中介绍,实际JVM的实现是鼓励不回收最近创建和最近使用的对象。SoftReference 类的一个典型用途就是用于内存敏感的高速缓存。
WeakReference(弱引用):如果一个被WeakReference引用的对象,当没要任何SoftReference和StrongReference引用时,立即会被GC。和SoftReference的区别是:WeakReference对象是被eagerly collected,即一旦没要任何SoftReference和StrongReference引用,立即被清楚;而只被SoftReference引用的对象,不回立即被清楚,只有当内存不够,即将发生OutOfMemoryError时才被清除,而且是先清除不常用的。SoftReference适合实现Cache用。WeakReference
类的一个典型用途就是规范化映射( canonicalized mapping )
PhantomReference(虚引用):当没有StrongReference,SoftReference和WeakReference引用时,随时可被GC。通常和ReferenceQueue联合使用,管理和清除与被引用对象(没有finalize方法)相关的本地资源。
参考文章:
http://coderbee.net/index.php/jvm/
http://blog.chinaunix.net/uid-7374279-id-4489100.html
http://blog.csdn.net/salahg/article/details/5912101
参考知识库
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
访问:806396次
积分:10386
积分:10386
排名:第1086名
原创:245篇
转载:51篇
评论:308条
(2)(1)(2)(1)(1)(1)(3)(6)(3)(2)(4)(1)(5)(19)(6)(1)(14)(8)(82)(79)(9)(8)(4)(15)(10)(3)(1)(2)(3)JVM有关垃圾回收机制的配置
- 解道Jdon
& & & &&& & &
  JVM的垃圾回收机制有下面几种:
年轻态几种垃圾收集方式:
Serial (复制) 是一种stop-the-world(导致应用全部暂停,僵死一会儿), 使用单个GC线程进行复制收集
将幸存对象从
Eden复制到幸存 Survivor空间,并且在幸存Survivor空间之间复制,直到它决定这些对象已经足够长了,在某个点一次性将它们复制到旧生代old generation.
Parallel Scavenge (PS Scavenge)是一种stop-the-world, 使用多个GC线程实现复制收集。如同上面复制收集一样,但是它是并行使用多个线程。
ParNew是一种stop-the-world, 使用多个GC线程实现的复制收集,区别于&Parallel Scavenge&在于它与CMS可搭配使用,它也是并行使用多个线程,内部有一个回调功能允许旧生代操作它收集的对象。
旧生代几种垃圾收集方式:
Serial Old (MarkSweepCompact) 是一种stop-the-world, 使用单个线程进行mark-sweep-compact(标志-清扫-压缩) 收集。
Parallel Old (PS MarkSweep) 是一种使用多个GC线程压缩收集。
ConcurrentMarkSweep (CMS) 是最并行,低暂停的收集器。垃圾回收算法在后台不会暂停应用线程情况下实现大部分垃圾回收工作。
G1 使用 'Garbage First' 算法将堆空间划分为许多小空间。是一种跨年轻态和旧生代的回收。Java 7以后支持。
新生代和旧生代的两种回收机制不是每个都能够搭配在一起工作的,如下图:
上图中黄色区域是年轻态,蓝色框子代表适用的几种垃圾回收方式;下方白色区域代表旧生代,蓝色也是代表在旧生代的回收方式,两种蓝色盒子之间的连线表示它们的搭配配置,比如Serial只能和CMS或Serial Old搭配使用,而ParNew只能和CMS或Serial Old使用,而Parallel Scavenge只能和Serail Old和Parallel Old使用,不能和CMS搭配使用。
在JVM中是+XX配置实现的搭配组合:
UseSerialGC 表示 &Serial& + &Serial Old&组合
UseParNewGC 表示 &ParNew& + &Serial Old&
UseConcMarkSweepGC 表示 &ParNew& + &CMS& + &Serial Old&. 组合,&CMS& 是针对旧生代使用最多的,而&Serial Old&是在并行模式失败情况下使用。注意不推荐使用XX:+CMSIncrementalMode,理由见
UseParallelGC 表示 &Parallel Scavenge& + &Serial Old&组合
UseParallelOldGC 表示 &Parallel Scavenge& + &Parallel Old&组合
在实践中使用UseConcMarkSweepGC 表示 &ParNew& + &CMS& 的组合是经常使用的,那么这种组合与Java 7最新的G1回收机制相比如何?上图中?问号代表G1垃圾回收机制。
来自LinkedIn的工程师对ParNew/CMS和G1两种回收进行了对比,文章见:
上面两张图分别是CPU负载和吞吐量的对比图,第一张ParNew/CMS代表的红色比较平坦,而G1上下波动;下面一张,ParNew/CMS代表的吞吐量要超过G1。
因此,他们推荐还是使用ParNew/CMS组合配置。
| 网站地图 | 设为首页}

我要回帖

更多关于 jvm 垃圾回收机制 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信