❶ GC垃圾回收(3)- 三色标记算法
CMS过程在上篇文章 GC垃圾回收(2) 中已经写过。
它分为四个阶段:
其中 并发标记 阶段会有漏标的问题,为解决这个问题,采用了 "三色标记凳旦算法"
G1 GC(Garbage First Garbage Collector)是一种服务端应用使用的垃圾收集器,目标是用在 多核、大内存 的机器上,它在大多数情况下可以实现指定的GC暂停时间,同时还能保持较高的吞吐量。它的吞吐量相较PS+PO降低了大概10%~15%,但是大大降低了响应时间,大概200ms的程度
G1内存模型如下:
G1相较之前其它的垃圾回收器,对模型进行了改变,不再进行物理分代,采用逻辑分代。
它不再将连续内存分为Eden区和Old区,而是将内存分为一个个的Region。一块Region(分区)在逻辑上依然分代,分为兆粗指四种:Eden,Old,Survivor,Humongous(大对象,跨多个连续的Region)。
它的每个分区都可能是年轻代也可能是老年代,但是在同一时刻只能属于某个代。
年轻代、幸存区、老年代这些概念还存在,成为了逻辑上的概念,这样方便复用之前分代框架的逻辑。在物理上不需要连续,这带来了额外的好处——有的分区内垃圾对象特别多,有的分区内垃圾对象很少,G1会优先回收垃圾对象特别多的分区,这样可以花费较少的时间来回收这些分区的垃圾,这也就是G1名字的由来,即首先回收垃圾最多的分区。
新生代其实并不适用于这种算法,依然是在新生代满了的时候,对整个新生代进行回收——整个新生代中的对象,要么被回收、要么晋升,至于新生代也采取分区机制的原因,则是因为这样跟老年代的策略统一,方便调整代的大小。
G1还是一种带压缩的收集器,在回收老年代的分区时,是将存活的对象从一个分区拷贝到另一个可用分区,这个拷贝的过程就实现了局部的压缩。每个分区的大小从1M到32M不等,但都是2的幂次方。
特点:
G1与CMS在并发收集时的算法没太大区别,用的是 三色标记 算法。但ZGC和Shenandoah使用的是 颜色指针 Colored Pointers。
主要用于分代模型中帮助垃圾回收。
为什么需要 card table ?
寻找存活对象并不是一件容易的事。从一个GC root对象寻找,可能被Old区对象引用,这个Old区对象又被Eden区对象引用,那么判断Eden区对象是否存活就需要遍历整个Old区存活对象看是否被Old区对象引用。这样的话每进行一次YGC就要扫描整个Old区。
所以JVM内部,将内存区域分为一个个的card,对象存在一个个的card里。当老年代某个card中的对象指向了年轻代,就会将这个card标记为 Dirty 。这么多card具体哪个是 Dirty的,用位图BitMap来代表(如0110010010,1表示Dirty),这就是Card Table。
Card Table :由于做YGC时,需要扫描整个Old区,效率非常低,所以JVM设计了Card Table, 如果一个Old区Card Table中有对象指向Y区,就将它设为Dirty,下次扫描时,只需要扫描Dirty Card。 在结构上,Card Table用BitMap来实现。
RSet会占用一定的空间,所以ZGC又做了改进,不使用RSet,用颜色指针来标记。
Rset与赋值的效率:
5% ~ 60%(新生代)
G1能跟踪STW停顿时间,根族配据停顿时间动态调整新生代(Y区)比例
超过单个region的 50% 就是一个大对象,也可跨越多个region。
注意: G1也是存在FGC的,并且一定会被触发。当对象分配不下是会产生FGC。
回收时不分新生代还是老年代什么的,region满了就回收。
MixedGC过程:
跟CMS非常像,MixedGC最后是筛选回收,多了个筛选步骤。筛选就是找出垃圾最多的region。筛选后将存活对象复制到其他region,再将之前的region清空。
CMS和G1在并发标记时使用的是同一个算法: 三色标记法 ,使用白灰黑三种颜色标记对象。白色是未标记;灰色自身被标记,引用的对象未标记;黑色自身与引用对象都已标记。
在remark过程中,黑色指向了白色,如果不对黑色重新扫描,则会漏标。会把白色D对象当作没有新引用指向从而回收掉。
并发标记过程中,Mutator删除了所有从灰色到白色的引用,会产生漏标。此时白色对象应该被回收
产生漏标问题的条件有两个:
1.黑色对象指向了白色对象
2.灰色对象指向白色对象的引用消失
所以要解决漏标问题,打破两个条件之一即可:
为什么G1采用SATB而不用incremental update?
因为采用incremental update把黑色重新标记为灰色后,之前扫描过的还要再扫描一遍,效率太低。
G1有RSet与SATB相配合。Card Table里记录了RSet,RSet里记录了其他对象指向自己的引用,这样就不需要再扫描其他区域,只要扫描RSet就可以了。
也就是说 灰色-->白色 引用消失时,如果没有 黑色-->白色,引用会被push到堆栈,下次扫描时拿到这个引用,由于有RSet的存在,不需要扫描整个堆去查找指向白色的引用,效率比较高。SATB配合RSet浑然天成。
❷ JVM的垃圾算法有哪几种
一、垃圾收集器概述
如上图所示,垃圾回收算法一共有7个,3个属于年轻代、三个属于年老代,G1属于横跨年轻代和年老代的算法。
JVM会从年轻代和年老代各选出一个算法进行组合,连线表示哪些算法可以组合使用
二、各个垃圾收集器说明
1、Serial(年轻代)
年轻代收集器,可以和Serial Old、CMS组合使用
采用复制算法
使用单线程进行垃圾回收,回收时会导致Stop The World,用户进程停止
client模式年轻代默认算法
GC日志关键字:DefNew(Default New Generation)
图示(Serial+Serial Old)
7、G1
G1收集器由于没有使用过,所以从网上找了一些教程供大家了解
并行与并发
分代收集
空间整合
可预测的停顿
❸ java有哪些垃圾回收算法
常用的垃圾回收算法有:
(1).引用计数算法:
给对象中添加一个引用计数器,每当有一个地方引用它时,计数器值就加1;当引用失效时,计数器值就减1;任何时刻计数器都为0的对象就是不再被使用的,垃圾收集器将回收该对象使用的内存。
引用计数算法实现简单,效率很高,微软的COM技术、ActionScript、Python等都使用了引用计数算法进行内存管理,但是引用计数算法对于对象之间相互循环引用问题难以解决,因此java并没有使用引用计数算法。
(2).根搜索算法:
通过一系列的名为“GC Root”的对象作为起点,从这些节点向下搜索,搜索所走过的路径称为引用链(Reference Chain),当一个对象到GC Root没有任何引用链相连时,则该对象不可达,该对象是不可使用的,垃圾收集器将回收其所占的内存。
主流的商用程序语言C#、java和Lisp都使用根搜素算法进行内存管理。
在java语言中,可作为GC Root的对象包括以下几种对象:
a. java虚拟机栈(栈帧中的本地变量表)中的引用的对象。
b.方法区中的类静态属性引用的对象。
c.方法区中的常量引用的对象。
d.本地方法栈中JNI本地方法的引用对象。
java方法区在Sun HotSpot虚拟机中被称为永久代,很多人认为该部分的内存是不用回收的,java虚拟机规范也没有对该部分内存的垃圾收集做规定,但是方法区中的废弃常量和无用的类还是需要回收以保证永久代不会发生内存溢出。
判断废弃常量的方法:如果常量池中的某个常量没有被任何引用所引用,则该常量是废弃常量。
判断无用的类:
(1).该类的所有实例都已经被回收,即java堆中不存在该类的实例对象。
(2).加载该类的类加载器已经被回收。
(3).该类所对应的java.lang.Class对象没有任何地方被引用,无法在任何地方通过反射机制访问该类的方法。
Java中常用的垃圾收集算法:
(1).标记-清除算法:
最基础的垃圾收集算法,算法分为“标记”和“清除”两个阶段:首先标记出所有需要回收的对象,在标记完成之后统一回收掉所有被标记的对象。
标记-清除算法的缺点有两个:首先,效率问题,标记和清除效率都不高。其次,标记清除之后会产生大量的不连续的内存碎片,空间碎片太多会导致当程序需要为较大对象分配内存时无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
(2).复制算法:
将可用内存按容量分成大小相等的两块,每次只使用其中一块,当这块内存使用完了,就将还存活的对象复制到另一块内存上去,然后把使用过的内存空间一次清理掉。这样使得每次都是对其中一块内存进行回收,内存分配时不用考虑内存碎片等复杂情况,只需要移动堆顶指针,按顺序分配内存即可,实现简单,运行高效。
复制算法的缺点显而易见,可使用的内存降为原来一半。
(3).标记-整理算法:
标记-整理算法在标记-清除算法基础上做了改进,标记阶段是相同的标记出所有需要回收的对象,在标记完成之后不是直接对可回收对象进行清理,而是让所有存活的对象都向一端移动,在移动过程中清理掉可回收的对象,这个过程叫做整理。
标记-整理算法相比标记-清除算法的优点是内存被整理以后不会产生大量不连续内存碎片问题。
复制算法在对象存活率高的情况下就要执行较多的复制操作,效率将会变低,而在对象存活率高的情况下使用标记-整理算法效率会大大提高。
(4).分代收集算法:
根据内存中对象的存活周期不同,将内存划分为几块,java的虚拟机中一般把内存划分为新生代和年老代,当新创建对象时一般在新生代中分配内存空间,当新生代垃圾收集器回收几次之后仍然存活的对象会被移动到年老代内存中,当大对象在新生代中无法找到足够的连续内存时也直接在年老代中创建。
❹ GC是什么意思
常用的GC算法: 1)标记非活动对象 --何为非活动对象,通俗的讲,就是无引用的对象。追踪root对象算法: 深度追踪root对象,将heap中所有被引用到的root做标志,所有未被标志的对象视为非活动对象,所占用的空间视为非活动内存。2)清理非活动对象 Copy算法: 方法:将内存分为两个区域(from space和to space)。所有的对象分配内存都分配到from space。在清理非活动对象阶段,把所有标志为活动的对象,到to space,之后清楚from space空间。然后互换from sapce和to space的身份。既原先的from space变成to sapce,原先的to space变成from space。每次清理,重复上述过程。优点:算法不理会非活动对象,数量仅仅取决为活动对象的数量。并且在的同时,整理了heap空间,即,to space的空间使用始终是连续的,内存使用效率得到提高。缺点:划分from space和to space,内存的使用率是1/2。Compaction算法: 方法:在清理非活动对象阶段,删除非活动对象占用内存,并且把活动对象向heap的底部移动,直到所有的活动对象被移到heap的一侧。优点:无须划分from sapce和to space,提高内存的使用率。并且compaction后的内存空间也是连续分配的。缺点:该算法相对比较复杂。sun jdk gc介绍: 在减少gc之前,先来看看来自IBM的一组统计数据: 98%的java对象,在创建之后不久就变成了非活动对象;只有2%的对象,会在长时间一直处于活动状态。如果能对这两种对象区分对象,那么会提交GC的效率。在sun jdk gc中(具体的说,是在jdk1.4之后的版本),提出了不同生命周期的GC策略。young generation: 生命周期很短的对象,归为young generation。由于生命周期很短,这部分对象在gc的时候,很大部分的对象已经成为非活动对象。因此针对young generation的对象,采用算法,只需要将少量的存活下来的对象到to space。存活的对象数量越少,那么算法的效率越高。young generation的gc称为minor gc。经过数次minor gc,依旧存活的对象,将被移出young generation,移到tenured generation(下面将会介绍) young generation分为: eden:每当对象创建的时候,总是被分配在这个区域 survivor1:算法中的from space survivor2:算法中的to sapce (备注:其中survivor1和survivor2的身份在每次minor gc后被互换) minor gc的时候,会把eden survivor1(2)的对象到survivor2(1)去。tenured generation: 生命周期较常的对象,归入到tenured generation。一般是经过多次minor gc,还 依旧存活的对象,将移入到tenured generation。(当然,在minor gc中如果存活的对象的超过survivor的容量,放不下的对象会直接移入到tenured generation) tenured generation的gc称为major gc,就是通常说的full gc。采用compactiion算法。由于tenured generaion区域比较大,而且通常对象生命周期都比较常,compaction需要一定时间。所以这部分的gc时间比较长。minor gc可能引发full gc。当eden+from space的空间大于tenured generation区的剩余空间时,会引发full gc。这是悲观算法,要确保eden+from space的对象如果都存活,必须有足够的tenured generation空间存放这些对象。Permanet Generation: 该区域比较稳定,主要用于存放classloader信息,比如类信息和method信息。对于spring hibernate这些需要动态类型支持的框架,这个区域需要足够的空间。这部分内容相对比较理论,可以结合jstat,jmap等命令(当然也可以使用jconsole,jprofile,gciewer等工具),观察jdk gc的情
❺ jdk8中,GC用到的的算法有哪些
主要应用Mark-sweepalgorithm(标记消除算法)即从根object(程序直接访问的)开始标记可到达的object算明缺漏法基于有向图,采用深度优先搜索最后推荐你扮型一本书,《java程序设激烂计语言》([美]KenArnold,JamesGosling,DavidHolmes)上面有对
❻ 几种常见GC简介
在springboot-admin当中,大概会有以下几种类型的gc出现,本文我们看看他们分别是什么意思。
本文使用的垃圾收集器是jdk1.8的PS+PO。
顾名思义,就是内存分配失败导致的GC,常见于年轻代当中。
使用JNI临界区的方式操作数组或者字符串时,为了防止GC过程中jarray或者jstring发生位移,而导致数组指针失效,需要保持它们在JVM Heap中的地址在JNI Critical过程中保持不变。于是JVM实现了GC_locker,用于JNI Critical内阻止其他GC的发生。
当GCLocker被激活且需要发生GC的时候(这里是否需要GC是各种GC发生时,调用GCLocker::check_active_before_gc()函数check并设置_needs_gc = true的),就会阻塞其他线程进入JNI临界区;并且在最后一个位于JNI临界区的线程退出临界区时,发起一次CGCause为_gc_locker的GC。这里解释了GCLocker Initiated GC发生的原委。
在JVM中的垃圾收集器中的Ergonomics就是负责自动的调解gc暂停时间和吞吐量之间的平衡,使你的虚拟机性能更好的一种做法。
简单说就是内存在进行分配的时候,会通过一些算法,预估是否会出现无法分配的问题。如果符合无法分配预估值,会提前进行一次gc。
这个gc主要发生的条件是元空间,也就是Metadata的参数设置问题。
通常根据我们学习的JVM只是,元空间使用的是本地内存,所以应该与当前服务器的最大内存有关。
但实际不是这样的,在jdk1.8中,如果不设置元空间的大小,会有一个默认值是 21M 。
所以需要我们启动的时候指定一个元空间大小:
GC日志如下所示:
❼ GC的复制算法和标记整理算法
复制算法
复制算法是将内存划分为两个区间,在任意时间点,所有动态分配的对象都只能分配在其中的一个区间(称为活动区间),而另外一个区间(空闲区间)是空闲的。
当有效内存空间耗尽时,JVM将暂停程序运行,开启复制GC线程。接下来GC线程会将活动区的存活对象,全部复制到空闲区间,且严格按照内存地址依次排列,与此同时,GC线程将更新存活对象的内存引用地址指向新的内存地址。
此时,空闲区间已经与活动区间交换,而垃圾对象现在已经全部留在了原来的活动区间,也就是现在的空闲区间。事实上,在活动区间转换为空闲区间的同时,垃圾对象已经被一次性全部回收了。
开始时:
在被GC线程处理后:
可以看到,1和4号对象被清楚了,而2,3,5,6号对象则是规则的排列在刚才的空闲区间,也就是现在的活动区间之间,此时左半部分已经变成空闲区间,然而,如中在下一次GC之后,左半部分再次变成活动区间。
显然:
复制算法缺点时非常明显的:
1.直接浪费了一般的内存。
2.再就是加入对象存活率非常高,达到了极端的100%,那么我们需要将所有的对象都复制一遍,并将所有引用地址重置一遍。复制这一工作所花费的时间,在对象存活率达到一定的程度时,将会变得不可忽视。
由此可见,复制算法要想使用,最起码对象的存活率要非常低才行,而且最重要的是,我们态悔必须要克服50%内存浪费。
标记整理算法
分为两个阶段:
1.标记:遍历GC roots,然后将存活的对象标记。
2.整理:移动所帆橡正有存活的对象,且按照内存地址次序依次排列,然后将末端内存地址以后的内存全部回收,这个阶段才为整理阶段。
它与GC 前后与复制算法类似,只不过没有了活动区间和空闲区间
倘若此时GC线程开始工作,那么紧接着开始的就是标记阶段了。此阶段与标记/清除算法的标记阶段是一样一样的,我们看标记阶段过后对象的状态,如下图。
接下来,便应该是整理阶段了。我们来看当整理阶段处理完以后,内存的布局是如何的,如下图。
❽ JVM YoungGen(新生代),OldGen(年老代),和PermGen(持久区)
Sun的JVM将整个堆分为三代:YoungGen(新生代),OldGen(年老代),和PermGen(持久区):
Minor GC:通常是指对新生代的回收。
Major GC:通常是指对年老代的回收。
Full GC:Major GC除并发gc外均需对整个堆进行扫描和回收。
复制拷贝算法:要拷贝大量数据,不会产生碎片。
标记算法:从引用根节点开始标记所有被引用的对象,把未被引用的对象清除。要遍雀笑历所有对象,会产生碎片。
young 又分为eden,survivor1(from space ),survivor2(to sapce ).youngGen区里面的对象的生命周期比较短,gc对这些对象进行回收的时候采用复制拷贝算法。
eden 每当一个对象创建的时候分配的这个区域。当eden无法分配时,触发一次Minor gc。gc每次回收的时候都将eden区存活的对象和survivor1中的对象拷贝到survivor2中,eden和survivor1清空;当gc执行下次回收的时候将eden和survivor2中的对象拷贝到surivor1中,清空eden和survivor2。依次这样顷猜含执行;经过数次回收将依然存活的对象复制到OldGen区。
OldGen 当对象从年轻代晋升到老年代之前,会检测老年区的剩余空间是否大于要晋升对象的大小,如果小于则直接进行一次Full GC,以便让老年去腾出更多的空间,然后再进行Minor GC,把年轻代的对象复制到老年代;如果大于,则根据条件(HandlePromotionFailure设置)进行Minor GC 和 Full GC。
老年区采用标记算法,因为老年区对象的生命周期都是比较长的,采用拷贝算法要兆带拷贝大量的数据。采用标记算法每次gc回收都要遍历所有的对象。
PermGen 主要存放加载进来的类信息,包括方法,属性,常量池等,满了之后可能会引起out of memory 错误。
❾ 深入理解GC垃圾回收机制
在我们程序运行中会不断创建新的对象,这些对象会存储在内存中,如果没有一套机制来回收这些内存,那么被占用的内存会越来越多,可用内存会越来越少,直至内存被消耗完。于是就有了一套垃圾回收机制来做这件维持系统平衡的任务。
1.确保被引用对象的内存不被错误的回收
2.回收不再被引用的对象的内存空间
给对象中添加一个引用计数器,每当有一个地方引用它时,计数器值就加1;当引用失效时, 计数器值就减1;任何时刻计数器为0的对象就是不可能再被使用的。
优点:引用计数收集器可以很快地执行,交织在程序的运行之中。
缺点:很难处理循环引用,比如上图中相互引用的两个对象,计数器不为0,则无法释放,但是这样的对象存在是没有意义的,空占内存了。
引用计数法处理不了的相互引用的问题,那么就有了可达性分析来解决了这个问题。
从GC Roots作为起点,向下搜索它们引用的对象,可以生成一棵引用树,树的节点视为可达对象,反之最终不能与GC Roots有引用关系的视为不可达,不可达对象即为垃圾回收对象。
我自己的理解是,皇室家族每过一段时间,会进行皇室成员排查,从皇室第一代开始往下找血缘关系的后代,如果你跟第一代皇室没有关系,那么你就会被剔除皇室家族。
1.虚拟机栈中引用的对象(正在运行的方法使用到的变量、参数等)
2.方法区中类静态属性引用的对象(static关键字声明的字段)
3.方法区中常量引用的对象,(也就是final关键字声明的字段)
4.本地方法栈中引用的对象(native方法)
1.显示地赋予某个对象为null,切断可达性
在main方法中创建objectA、objectB两个局部变量,而且相互引用。相互引用直接调System.gc()是回收不了的。而将两者都置为null,切断相互引用,切断了可达性,与GCRoots无引用,那么这两个对象就会被回收调。
2.将对象的引用指向另一个对象
这里将one的引用也指向了two引用指向的对象,那么one原本指向的对象就失去了GCRoots引用,这里就判断该对象可被回收。
3.局部对象的使用
当方法执行完,局部变量object对象会被判定为可回收对象。
4.只有软、弱、虚引用与之关联
new出来的对象被强引用了,就需要去掉强引用,改为弱引用。被弱引用之后,需要置空来干掉强引用,达到随时可回收的效果。
只被软引用的对象在内存不足的情况,可能会被GC回收掉。
只被弱引用持有的对象,随时都可能被GC回收,该对象就为可回收对象。
是不是被判定为了可回收对象,就一定会被回收了呢。其实Ojbect类中还有一个finalize方法。这个方法是对象在被GC回收之前会被触发的方法。
该方法翻译过来就是:当垃圾回收确定不再有对该对象的引用时,由垃圾回收器在对象上调用。子类重写finalize方法以处置系统资源或执行其他清除。说人话就是对象死前会给你一个回光返照,让你清醒一下,想干什么就干什么,甚至可以把自己救活。我们可以通过重写finalize方法,来让对象复活一下。
示例:
执行的结果:
这里我们重写FinalizeGC类的finalize方法, 使用FinalizeGC.instance = this语句,让对象又有了引用,不再被判定为可回收对象,这里就活了。然后再置空再回收一下,这个对象就死了,没有再被救活了。所以finalize方法只能被执行一次,没有再次被救活的机会。
在JDK1.8版本废弃了永久代,替代的是元空间(MetaSpace),元空间与永久代上类似,都是方法区的实现,他们最大区别是:元空间并不在JVM中,而是使用本地内存。
元空间有注意有两个参数:
MetaspaceSize :初始化元空间大小,控制发生GC阈值
MaxMetaspaceSize : 限制元空间大小上限,防止异常占用过多物理内存
为什么移除永久代?
移除永久代原因:为融合HotSpot JVM与JRockit VM(新JVM技术)而做出的改变,因为JRockit没有永久代。
有了元空间就不再会出现永久代OOM问题了!
1.Generational Collection(分代收集)算法
分代收集算法是GC垃圾回收算法的总纲领。现在主流的Java虚拟机的垃圾收集器都采用分代收集算法。Java 堆区基于分代的概念,分为新生代(Young Generation)和老年代(Tenured Generation),其中新生代再细分为Eden空间、From Survivor空间和To Survivor空间。 (Survivor:幸存者)
分代收集算法会结合不同的收集算法来处理不同的空间,因此在学习分代收集算法之前我们首先要了解Java堆区的空间划分。Java堆区的空间划分在Java虚拟机中,各种对象的生命周期会有着较大的差别。因此,应该对不同生命周期的对象采取不同的收集策略,根据生命周期长短将它们分别放到不同的区域,并在不同的区域采用不同的收集算法,这就是分代的概念。
当执行一次GC Collection时,Eden空间的存活对象会被复制到To Survivor空间,并且之前经过一次GC Collection并在From Survivor空间存活的仍年轻的对象也会复制到To Survivor空间。
对象进入到From和To区之后,对象的GC分代年龄ege的属性,每经过GC回收存活下来,ege就会+1,当ege达到15了,对象就会晋级到老年代。
2.Mark-Sweep(标记-清除)算法
标记清除:标记阶段的任务是标记出所有需要被回收的对象,清除阶段就是回收被标记的对象所占用的空间。标记-清除算法主要是运用在Eden区,该区对象很容易被回收掉,回收率很高。
3.Copying(复制)算法
复制算法的使用在From区和To区,每次只使用其中的一块。当这一块的内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已使用的内存空间一次清理掉,这样一来就不容易出现内存碎片的问题。
缺点:可使用内存缩减为一半大小。
那么复制算法使可使用内存大小会减半,设计上是怎么解决这个问题的呢。就是给From和To区划分尽可能小的区域。经过大数据统计之后,对象在第一次使用过后,绝大多数都会被回收,所以能进入第一次复制算法的对象只占10%。那么设计上,Eden、From、To区的比例是8:1:1,绝大多数对象会分配到Eden区,这样就解决了复制算法缩减可用内存带来的问题。
4.Mark-Compact (标记—整理)算法
在新生代中可以使用复制算法,但是在老年代就不能选择复制算法了,因为老年代的对象存活率会较高,这样会有较多的复制操作,导致效率变低。标记—清除算法可以应用在老年代中,但是它效率不高,在内存回收后容易产生大量内存碎片。因此就出现了一种标记—整理算法,与标记—清除算法不同的是,在标记可回收的对象后将所有存活的对象压缩到内存的一端,使它们紧凑地排列在一起,然后对边界以外的内存进行回收,回收后,已用和未用的内存都各自一边。
垃圾收集算法是内存回收的方法论,那么垃圾收集器就是内存回收的具体实现:
Serial 收集器(复制算法): 新生代单线程收集器,标记和清理都是单线程,
优点是简单高效;
Serial Old 收集器 (标记-整理算法): 老年代单线程收集器,Serial 收集器
的老年代版本;
ParNew 收集器 (复制算法): 新生代收并行集器,实际上是 Serial 收集器
的多线程版本,在多核 CPU 环境下有着比 Serial 更好的表现;
CMS(Concurrent Mark Sweep)收集器(标记-清除算法): 老年代并行
收集器,以获取最短回收停顿时间为目标的收集器,具有高并发、低停顿
的特点,追求最短 GC 回收停顿时间。
❿ JVM 技术详解:常见的 GC 算法(Parallel/CMS/G1)
学习了 GC 算法的相关概念之后,我们将介绍在 JVM 中这些算法的具体实现。首先要记住的是,大多数 JVM 都需要使用两种不同的 GC 算法——一种用来清理年轻代,另一种用来清理老年代。厅行
我们可以选择 JVM 内置的各种算法。如果不通过参数明确指定垃圾收集算法,则会使用相应 JDK 版本的默认实现。本章会详细介绍各种算法的实现原理。
串行 GC 对年轻代使用 mark-(标记—复制)算法,对老年代使用 mark-sweep-compact(标记—清除—整理)算法。
两者都是单线程的垃圾收集器,不能进行并行处理,所以都枣型会触发全线暂停(STW),停止所有的应用线程。
因此这种 GC 算法不能充分利用多核 CPU。不管有多少 CPU 内核,JVM 在垃圾收集时都只能使用单个核心。
要启用此款收集器,只需要指定一个 JVM 启动参数即可,同时对年轻代和老年代生效:
该选项只适合几百 MB 堆内存的 JVM,而且是单核 CPU 时比较有用。
对于服务器端来说,因为一般是多个 CPU 内核,并不推荐使用,除非确实需要限制 JVM 所使用的资源。大多数服务器端应用部署在多核平台上,选择 串行 GC 就意味着人为地限制了系统资源的使用,会导致资源闲置,多余的 CPU 资源也不能用增加业务处理凳伏猜的吞吐量。
关于串行垃圾收集器的日志内容,我们在后面的内容《GC 日志解读与分析》之中进行详细的讲解。
并行垃圾收集器这一类组合,在年轻代使用“标记—复制(mark-)算法”,在老年代使用“标记—清除—整理(mark-sweep-compact)算法”。年轻代和老年代的垃圾回收都会触发 STW 事件,暂停所有的应用线程来执行垃圾收集。两者在执行“标记和复制/整理”阶段时都使用多个线程,因此得名“ Parallel ”。通过并行执行,使得 GC 时间大幅减少。
通过命令行参数 -XX:ParallelGCThreads=NNN 来指定 GC 线程数,其默认值为 CPU 核心数。可以通过下面的任意一组命令行参数来指定并行 GC:
并行垃圾收集器适用于多核服务器,主要目标是增加吞吐量。因为对系统资源的有效使用,能达到更高的吞吐量: