本文是对《【硬刚大数据之学习路线篇】从零到大数据专家的学习指南(全面升级版)》的JVM部分补充。
3.1.1 概述
1.Serial收集器是最基本、历史最悠久的垃圾收集器了。JDK1.3之前回收新生代唯一的选择。
2.Serial收集器作为Hotspot中Client模式下的默认新生代垃圾收集器。
3.Serial收集器采用复制算法、串行回收和"stop-the-World"机制的方式执行内存回收。
4.除了年轻代之外, Serial收集器还提供用于执行老年代垃圾收集的Serial Old收集器。 Serial Old收集器同样也采用了串行回收和"Stop the World"机制,只不过内存回收算法使用的是标记-压缩算法
5.这个收集器是一个单线程的收集器,但它的"单线程"的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作,更重要的是在它进行垃圾收集时,必须暂停其他所有的工作线程,直到它收集结束(Stop The World)
3.1.2 优势
1.简单而高效(与其他收集器的单线程比),对于限定单个CPU的环境来说, Serial收集器由于没有线程交互的开销,专心做垃圾收集自然可以获得最高的单线程收集效率。
| 运行在C1ient模式下的虚拟机是个不错的选择。
2.在用户的桌面应用场景中,可用内存一般不大(几十MB至一两百MB),可以在较短时间内完成垃圾收集(几十ms至一百多ms),只要不频繁发生使用串行回收器是可以接受的。
3.1.3 如何使用
1.在 Hotspot虚拟机中,使用-X:+ UseserialGC参数可以指定年轻代和老年代都使用串行收集器。
| 等价于新生代用Serial GC,且老年代用Serial Old GC
3.1.4 总结
这种垃圾收集器大家了解,现在已经不用串行的了。而且在限定单核cpuオ可以用。现在都不是单核的了对于交互较强的应用而言,这种垃圾收集器是不能接受的。一般在Javaweb应用程序中是不会采用串行垃圾收集器的
3.2.1 概述
1.如果说Serial GC是年轻代中的单线程垃圾收集器,那么 ParNew收集器则是Serial收集器的多线程版本。
| Par是Parallel的缩写,New:只能处理的是新生代
2.ParNew收集器除了采用并行回收的方式执行内存回收外,两款垃圾收集器之间几乎没有任何区别。 ParNew收集器在年轻代中同样也是采用复制算法、"Stop-the- World"机制
3.ParNew是很多JVM运行在Server模式下新生代的默认垃圾收集器。
4.对于新生代,回收次数频繁,使用并行方式高效。
5.对于老年代,回收次数少,使用串行方式节省资源。(CPU并行需要切换线程,串行可以省去切换线程的资源)
3.2.2 由于 ParNew收集器是基于并行回收,那么是否可以断定ParNew收集器回收效率在任何场景下都会比Sernal收集器更高效?
1.ParNew收集器运行在多CPU的环境下,由于可以充分利用多CPU、多核心等物理硬件资源优势,可以更快速地完成垃圾收集,提升程序的吞吐量。
2.但是在单个CPU的环境下, ParNew收集器不比 Seral收集器更高效。虽然 Seral收集器是基于串行回收,但是由于CPU不需要频繁地做任务切换,因此可以有效避免多线程交互过程中产生的一些额外开销
3.因为除Serial外,目前只有 Parnew GC能与CMS收集器配合工作
3.2.3 参数配置
1.在程序中,开发人员可以通过选项"-XX:+UseParNewGC手动指定使用ParNewl收集器执行内存回收任务。它表示年轻代使用并行收集器,不影响老年代。
2.XX:Parallel GC Threads限制线程数量,默认开启和CPU数据相同的线程数
3.3.1 概述
1.Hotspot的年轻代中除了拥有ParNew收集器是基于并行回收的以外,Parallel Scavenge收集器同样也采用了复制算法、并行回收和"stop-the-World"机制。
2.那么Parallel收集器的出现是否多此一举?
3.高吞吐量则可以高效率地利用CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务。因此,常见在服务器环境中使用。例如,那些执行批量处理、订单处理、工资支付、科学计算的应用程序。
4.Parallel收集器在JDK1.6时提供了用于执行老年代垃圾收集的Parallel Old收集器,用来代替老年代的Serial Old收集器。
5.Parallel Old收集器采用了标记-压缩算法,但同样也是基于并行回收和"stop-the-world"机制
6.在程序吞吐量优先的应用场景中, Parallel收集器和Parallel Old收集器的组合,在Server模式下的内存回收性能很不错。
7.在Java8中,默认是此垃圾收集器。
3.3.2 参数配置:
1.-XX:+ UseParallelGC手动指定年轻代使用Parallel并行收集器执行内存回收任务。
2.-XX:+ UseParallelOldGC手动指定老年代都是使用并行回收收集器。
3.-XX:ParallelGCThreads设置年轻代并行收集器的线程数。一般地,最好与CPU数量相等,以避免过多的线程数影响垃圾收集性能。
4.-XX: MaxGCPauseMilllis设置垃圾收集器最大停顿时间(即STW的时间)。单位是毫秒。
5.-XX: GCTimeRatio。垃圾收集时间占总时间的比例(=1/(N+1))用于衡量吞吐量的大小。
6.-XX:+UseAdaptiveSizePolicy设置Parallel Scavenge收集器具有自适应调节策略
| 在堆空间Eden:S0:S1=8:1:1也提到过自适应,默认是开启的
3.4.1 概述
1.在JDK1.5时期, Hotspot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器:CMS( Concurrent-Mark- Sweep)收集器,这款收集器是Hotspot虚拟机中第一款真正意义上的并发收集器,它第一次实现了让垃圾收集线程与用户线程同时工作。
2.CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短(低延迟)就越适合与用户交互的程序,良好的响应速度能提升用户体验。
3.CMS收集器就非常符合这类应用的需求
4.CMS的垃圾收集算法采用标记-清除算法,并且也会"Stop-the-world"
5.不幸的是,CMS作为老年代的收集器,却无法与JDK1.4.6中已经存在的新生代收集器Parallel Scavenge配合工作,所以在JDK1.5中使用CMS来收集老年代的时候,新生代只能选择ParNew或者Serial收集器中的一个
6.在G1出现之前,CMS使用还是非常广泛的。一直到今天,仍然有很多系统使用CMS GC
3.4.2 工作原理
CMS整个过程比之前的收集器要复杂,整个过程分为4个性要阶段,即初始标记阶段、并发标记阶段、重新标记阶段和并发清除阶段。
1.初始标记( Initial-Mark)阶段:在这个阶段中,程序中所有的工作线程都将会因为"Stop-the-World"机制而出现短暂的暂停,这个阶段的主要任务仅仅只是标记出GC Roots能直接关联到的对象。一旦标记完成之后就会恢复之前被暂停的所有应用线程。由于直接关联对象比较小,所以这里的速度非常快。
2.并发标记(Concurrent-Mark)阶段:从 GC Roots的直接关联对象开始遍历整个对象图的过程,这个过程耗时较长但是不需要停顿用户线程,可以与垃圾收集线程一起并发运行
3.重新标记(Remark)阶段:由于在并发标记阶段中,程序的工作线程会和垃圾收集线程同时运行或者交又运行,因此为了修正并发标记期间,因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间通常会比初始标记阶段稍长一些,但也远比并发标记阶段的时间短。
4.并发清除(Concurrent- Sweep)阶段:此阶段清理删除掉标记阶段判断的已经死亡的对象,释放内存空间。由于不需要移动存活对象,所以这个阶段也是可以与用户线程同时并发的(会存在内存碎片问题)
3.4.3 原理分析
1.尽管CMS收集器采用的是并发回收(非独占式),但是在其初始化标记和再次标记这两个阶段中仍然需要执行"Stop-the-World"机制暂停程序中的工作线程,不过暂停时间并不会太长,因此可以说明目前所有的垃圾收集器都做不到完全不需要"stop-the-World",只是尽可能地缩短暂停时间。
2.由于最耗费时间的并发标记与并发清除阶段都不需要暂停工作,所以整体的回收是低停顿的。
3.另外,由于在垃圾收集阶段用户线程没有中断,所以在CMS回收过程中,还应该确保应用程序用户线程有足够的内存可用。因此,CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集,而是当堆内存使用率达到某一阈值时,便开始进行回收,以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行。要是CMS运行期间预留的内存无法满足程序需要,就会出现一次"Concurrent Mode Failure"失败,这时虚拟机将启动后备预案:临时启用Serial Old收集器来重新进行老年代的垃圾收集,这样停顿时间就很长了。
4.CMS收集器的垃圾收集算法采用的是标记-清除算法,这意味着每次执行完内存回收后,由于被执行内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块,不可避免地将会产生一些内存碎片,那么CMS在为新对象分配内存空间时,将无法使用指针碰撞(Bump the Pointer)技术,而只能够选择空闲列表(Free List)执行内存分配。
5.有人会觉得既然Mark Sweep会造成内存碎片,那么为什么不把算法换成Mark Compact呢?
答案其实很简单,因为当并发清除的时候,用Compact整理内存的话,原来的用户线程使用的内存还怎么用呢?要保证用户线程能继续执行,前提的它运行的资源不受影响嘛。 Mark Compact更适合"Stop-the-World"这种场景下使用
3.4.4 优缺点
1.CMS的优点:
2.CMS的弊端:
3.4.5 CMS收集器可以设置的参数。
1.-XX:+UseConcMarkSweepGC手动指定使用CMS收集器执行内存回收任务
2.-XX:CMSlnitiatingOccupanyFraction设置堆内存使用率的阀值,一旦达到该阈值,便开始进行回收。
3.-XX:+ UseCMSCompactAtFullCollection用于指定在执行完Full GC后对内存空间进行压缩整理,以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行,所带来的问题就是停顿时间变得更长了。
4.-XX: CMSFullGCsBeforeCompaction设置在执行多少次Full GC后对内存空间进行压缩整理。
5.-XX: ParallelCMSThreads设置CMS的线程数量
ParallelGCThreads是年轻代并行收集器的线程数。当CPU资源比较紧张时,受到CMS收集器线程的影响,应用程序的性能在垃圾回收阶段可能会非常糟糕。
3.4.6 小结:
1.Hotspot有这么多的垃圾回收器,那么如果有人问Parallel GC、 Concurrent Mark Sweep、 Serial GC这三个GC有什么不同呢?
请记住以下口令:
如果你想要最小化地使用内存和并行开销,请选Serial GC;
如果你想要最大化应用程序的吞吐量,请选Parallel GC;
如果你想要最小化GC的中断或停顿时间,请选CMS GC。
2.新特性说明
JDK9新特性:CMS被标记为Deprecate了(JEP291)
JDK14新特性:删除CMS垃圾回收器(JEP363)
3.5.1 概述
1.既然我们已经有了前面几个强大的GC,为什么还要发布Garbage First(G1)GC?
2.为什么名字叫做 Garbage First(1)呢?
3.5.2 优缺点
3.5.2.1 G1回收器的特点(优势)
与其他GC收集器相比,G1使用了全新的分区算法,其特点如下所示:
1.并行与并发
2.分代收集
3.空间整合
4.可预测的停顿时间模型(即:软实时soft real-time)
这是G1相对于CMS的另一大优势,G1除了追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为M毫秒的时间片段内,消耗在垃圾收集上的时间不得超过N毫秒。
3.5.2.2 缺点
1.相较于CMS,G1还不具备全方位、压倒性优势。比如在用户程序运行过程中,G1无论是为了垃圾收集产生的内存占用(Footprint)还是程序运行时的额外执行负载(Overload)都要比CMS要高。
2.从经验上来说,在小内存应用上cMS的表现大概率会优于G1,而G1在大内存应用上则发挥其优势。平衡点在6-8GB之间。
3.5.3 G1回收器的参数设置
1.-XX:+UseG1GC手动指定使用G1收集器执行内存回收任务(JDK9以后默认,就不用专门设置)。
2.-XX:G1HeapRegionSize设置每个Region的大小。值是2的幂,范围是1MB到32MB之间,目标是根据最小的Java堆大小划分出约2048个区域。默认是堆内存的1/2000。
3.-XX: MaxGCPauseMillis设置期望达到的最大GC停顿时间指标(JVM会尽力实现,但不保证达到)。默认值是200ms
4.-XX:ParallelGCThread设置STW工作线程数的值。最多设置为8
5.-XX: ConcGCThreads设置并发标记的线程数。将n设置为并行垃圾回收线程数(ParallelGCThreads)的1/4左右。
6.-XX: InitiatingHeapOccupancyPercent设置触发并发GC周期的Java堆占用率阈值。超过此值,就触发GC。默认值是45。
3.5.4 G1回收器的常见操作步骤
1.G1的设计原则就是简化JVM性能调优,开发人员只需要简单的三步即可完成
2.G1中提供了三种垃圾回收模式: Young GC、 Mixed GC和Full GC,在不同的条件下被触发
3.5.5 G1回收器的适用场景
1.面向服务端应用,针对具有大内存、多处理器的机器。(在普通大小的堆里表现并不惊喜)
2.最主要的应用是需要低GC延迟,并具有大堆的应用程序提供解决方案;
3.用来替换掉JDK1.5中的CMS收集器;在下面的情况时,使用G1可能比CMS好:
4.Hotspot垃圾收集器里,除了G1以外,其他的垃圾收集器使用内置的JVM线程执行GC的多线程操作,而G1 GC可以采用应用线程承担后台运行的GC工作,即当JVM的GC线程处理速度慢时,系统会调用应用程序线程帮助加速垃圾回收过程。
3.5.6 Region:化整为零
1.使用G1收集器时,它将整个Java堆划分成约2048个大小相同的独立Region块,每个Region块大小根据堆空间的实际大小而定,整体被控制在1MB到32MB之间,且为2的N次幂,即1MB,2MB,4MB,8MB,16MB,32MB。可以通过-XX:G1HeapRegionSize设定。所有的Region大小相同,且在JVM生命周期内不会被改变。
2.虽然还保留有新生代和老年代的概念,但新生代和老年代不再是物理隔离的了它们都是一部分Region(不需要连续)的集合。通过Region的动态分配方式实现逻辑上的连续
3.一个Region有可能属于Eden, Survivor或者Old/ Tenured内存区域。但是Region只可能属于一个角色图中的E表示该Region属于Eden内存区域,S表示属于Survivor内存区域,O表示属于Old内存区域。图中空白的表示末使用的内存空间。
4.G1垃圾收集器还増加了一种新的内存区域,叫做Humongous(大对象)内存区域,如图中的H块。主要用于存储大对象,如果超过1.5个Region,就放到H。
5.设置H的原因
6.Region
3.5.7 回收过程
G1GC的垃圾回收过程主要包括如下三个环节
1.年轻代GC(Young GC)
2.老年代并发标记过程(Concurrent Marking)
3.混合回收( Mixed GC)
4.如果需要,单线程、独占式、高强度的Full GC还是继续存在的。它针对GC的评估失败提供了一种失败保护机制,即强力回收。——后备方案
| 顺时针, young gc -> young gc + concurrent mark -> Mixed GC顺序,进行垃圾回收
3.5.7.1 回收过程说明
1.应用程序分配内存,当年轻代的Eden区用尽时开始年轻代回收过程;G1的年经代收集阶段是一个并行的独占式收集器。在年轻代回收期,G1GC暂停所有应用程序线程,启动多线程执行年轻代回收。然后从年轻代区间移动存活对象到 Survivor区间或者老年区间,也有可能是两个区间都会涉及。
2.当堆内存使用达到一定值(默认45%)时,开始老年代并发标记过程。
3.标记完成马上开始混合回收过程。对于一个混合回收期,G1 GC从老年区间移动存活对象到空闲区间,这些空闲区间也就成为了老年代的一部分。和年轻代不同,老年代的G1回收器和其他GC不同,G1的老年代回收器不需要整个老年代被回收,一次只需要扫描/回收小部分老年代的Region就可以了。同时,这个老年代Region是和年轻代一起被回收的。
4.举个例子:一个Web服务器,Java进程最大堆内存为4G,每分钟响应1500个请求,每45秒钟会新分配大约2G的内存。G1会每45秒钟进行一次年轻代回收,每31个小时整个堆的使用率会达到45%,会开始老年代并发标记过程,标记完成后开始四到五次的混合回收。
3.5.8 回收细节
3.5.8.1 相关概念
1.Remembered Set
2.解决办法
3.5.8.2 G1回收过程一:年轻代GC
1.概述
2.然后开始如下回收过程:
第一阶段,扫描根
第二阶段,更新RSet。
第三阶段,处理RSet。
第四阶段,复制对象。
第五阶段,处理引用。
3.对于应用零序的引用值语句object field= object,JVM会在之前和之后执行特殊的操以在dirty card queue中入队一个保存了对引用信息的card,在年经代回收的时候,G1会对Dirty Eard Queues中所有的card进行处理,以更新RSet,保证RSet实时准确的反映引用关系
4.那为什么不在引用風值语句处直接更新RSet呢?这是为了性的需要,RSet的理需要程同步,开销会很大,使用队列性会好很多
3.5.8.3 G1回收过程二:并发标记过程
1.初始标记阶段:标记从根节点直接可达的对象。这个阶段是STW的,并且会触发一次年轻代GC。
2.根区域扫描( Root Region Scanning):G1 GC扫描 Survivor区直接可达的老年代区域对象,并标记被引用的对象。这一过程必须在 young GC.之前完成。
3.并发标记( Concurrent Marking):在整个堆中进行并发标记(和应用程序并发执行),此过程可能被 young GC中断。在并发标记阶段,若发现区域对象中的所有对象都是垃圾,那这个区域会被立即回收。同时,并发标记过程中,会计算每个区域的对象活性(区域中存活对象的比例)。
4.再次标记(Remark):由于应用程序持续进行,需要修正上一次的标记结果。是STW的。G1中采用了比CMS更快的初始快照算法: snapshot-at-the- beginning(SATB)。
5.独占清理(cleanup,STW):计算各个区域的存活对象和GCc回收比例,并进行排序,识别可以混合回收的区域。为下阶段做铺垫。是STW的。这个阶段并不会实际上去做垃圾的收集
6.并发清理阶段:识别并清理完全空闲的区域。
3.5.8.4 G1回收过程三:混合回收
1.并发标记结束以后,老年代中百分百为垃圾的内存分段被回收了,部分为垃圾的内存分段被计算了出来。默认情况下,这些老年代的内存分段会分8次(可以通过-XX:G1MixedGCCountTarget设置)被回收。
2.混合回收的回收集(Collection Set)包括八分之一的老年代内存分段,Eden区内存分段, Survivor区内存分段。混合回收的算法和年轻代回收的算法完全一样,只是回收集多了老年代的内存分段。具体过程青参考上面的年轻代回收过程
3.由于老年代中的内存分段默认分8次回收,G1会优先回收垃圾多的内存分段。垃圾占内存分段比例越高的,越会被先回收。并且有一个阈值会决定内存分段是否被回收,-XX:G1MixedGCLiveThresholdPercent,默认为65%,意思是垃圾占内存分段比例要达到65%才会被回收。如果垃圾占比太低,意味着存活的对象占比高,在复制的时候会花费更多的时间。
4.混合回收并不一定要进行8次。有一个阈值-XX:G1 Heapwastepercent,默认值为16%,意思是允许整个堆内存中有16%的空间被浪费,意味着如果发现可以回收的垃圾占堆内存的比例低于16%,则不再进行混合回收。因为GC会花费很多的时间但是回收到的内存却很少
3.5.8.5 可选过程 Full GC
1.G1的初衷就是要避免Full GC的出现。但是如果上述方式不能正常工作,G1会停止应用程序的执行(Stop-The- World),使用单线程的内存回收算法进行垃圾回收,性能会非常差,应用程序停顿时间会很长。
2.要避免FullGC的发生,一旦发生需要进行调整。什么时候会发生Full GC呢?比如堆内存太小,当G1在复制存活对象的时候没有空的内存分段可用,则会回退到full gc,这种情况可以通过増大内存解决。
3.导致G1Full GC的原因可能有两个
3.5.8.6 G1回收过程:补充
从Oracle官方透露出来的信息可获知,回收阶段(Evacuation)其实本也有想过设计成与用户程序一起并发执行,但这件事情做起来比较复杂,考虑到G1只是回收一部分Region,停顿时间是用户可控制的,所以并不迫切去实现,而选择把这个特性放到了G1之后出现的低延迟垃圾收集器(即ZGC)中。另外,还考虑到G1不是仅仅面向低延迟,停顿用户线程能够最大幅度提高垃圾收集效率,为了保证吞吐量所以才选择了完全暂停用户线程的实现方案。
3.5.9 G1回收器优化建议
1.年轻代大小
2.暂停时间目标不要太过严苛
1.7种经典垃圾回收器总结
截止JDK1.8,一共有7款不同的垃圾收集器。每一款不同的垃圾收集器都有不同的特点,在具体使用的时候,需要根据具体的情况选用不同的垃圾收集器。
2.怎么选择垃圾回收器
| Java垃圾收集器的配置对于JVM优化来说是一个很重要的选择,选择合适的垃圾收集器可以让WM的性能有一个很大的提升。
| 官方推荐G1,性能高。现在互联网的项目,基本都是使用G1
3.最后需要明确一个观点:
4.对于垃圾收集,面试官可以循序渐进从理论、实践各种角度深入,也未必是要求面试者什么都懂。但如果你懂得原理,一定会成为面试中的加分项。这里较通用、基础性的部分如下