.markdown-body{word-break:break-word;line-height:1.75;font-weight:400;font-size:15px;overflow-x:hidden;color:#333}.markdown-body h1,.markdown-body h2,.markdown-body h3,.markdown-body h4,.markdown-body h5,.markdown-body h6{line-height:1.5;margin-top:35px;margin-bottom:10px;padding-bottom:5px}.markdown-body h1{font-size:30px;margin-bottom:5px}.markdown-body h2{padding-bottom:12px;font-size:24px;border-bottom:1px solid #ececec}.markdown-body h3{font-size:18px;padding-bottom:0}.markdown-body h4{font-size:16px}.markdown-body h5{font-size:15px}.markdown-body h6{margin-top:5px}.markdown-body p{line-height:inherit;margin-top:22px;margin-bottom:22px}.markdown-body img{max-width:100%}.markdown-body hr{border:none;border-top:1px solid #ddd;margin-top:32px;margin-bottom:32px}.markdown-body code{word-break:break-word;border-radius:2px;overflow-x:auto;background-color:#fff5f5;color:#ff502c;font-size:.87em;padding:.065em .4em}.markdown-body code,.markdown-body pre{font-family:Menlo,Monaco,Consolas,Courier New,monospace}.markdown-body pre{overflow:auto;position:relative;line-height:1.75}.markdown-body pre>code{font-size:12px;padding:15px 12px;margin:0;word-break:normal;display:block;overflow-x:auto;color:#333;background:#f8f8f8}.markdown-body a{text-decoration:none;color:#0269c8;border-bottom:1px solid #d1e9ff}.markdown-body a:active,.markdown-body a:hover{color:#275b8c}.markdown-body table{display:inline-block!important;font-size:12px;width:auto;max-width:100%;overflow:auto;border:1px solid #f6f6f6}.markdown-body thead{background:#f6f6f6;color:#000;text-align:left}.markdown-body tr:nth-child(2n){background-color:#fcfcfc}.markdown-body td,.markdown-body th{padding:12px 7px;line-height:24px}.markdown-body td{min-width:120px}.markdown-body blockquote{color:#666;padding:1px 23px;margin:22px 0;border-left:4px solid #cbcbcb;background-color:#f8f8f8}.markdown-body blockquote:after{display:block;content:""}.markdown-body blockquote>p{margin:10px 0}.markdown-body ol,.markdown-body ul{padding-left:28px}.markdown-body ol li,.markdown-body ul li{margin-bottom:0;list-style:inherit}.markdown-body ol li .task-list-item,.markdown-body ul li .task-list-item{list-style:none}.markdown-body ol li .task-list-item ol,.markdown-body ol li .task-list-item ul,.markdown-body ul li .task-list-item ol,.markdown-body ul li .task-list-item ul{margin-top:0}.markdown-body ol ol,.markdown-body ol ul,.markdown-body ul ol,.markdown-body ul ul{margin-top:3px}.markdown-body ol li{padding-left:6px}.markdown-body .contains-task-list{padding-left:0}.markdown-body .task-list-item{list-style:none}@media (max-width:720px){.markdown-body h1{font-size:24px}.markdown-body h2{font-size:20px}.markdown-body h3{font-size:18px}}
大家好,我是南橘,从接触java到现在也有差不多两年时间了,两年时间,从一名连java有几种数据结构都不懂超级小白,到现在懂了一点点的进阶小白,学到了不少的东西。知识越分享越值钱,我这段时间总结(包括从别的大佬那边学习,引用)了一些平常学习和面试中的重点(自我认为),希望给大家带来一些帮助
这是之前的两篇,没看过的可以一起看一下
JVM的文章的思路来自于猿人谷大佬,大佬技术非常好,写的文章也很硬,吃起来非常满足。(^_^)
上篇文章讲了JVM的垃圾回收机制,大体上了解了什么样的对象会被回收,什么情况下会被回收。这篇文章我们就着重的介绍几种具体的垃圾收集器。
前文也有提过,根据不同分代的特点,我们所使用的垃圾收集器也有不同。根据之前的分析,适用于新生代的垃圾收集器需要选择效率更高,回收速度更快的。而对于老年代来说,因为回收的次数较少,应该避免使用标记-复制算法之类的应用于新生代的算法。
串行收集器是针对新生代的垃圾收集器,基于标记-复制算法。它采用单线程方式进行收集,且在GC线程工作时,系统不允许应用线程打扰。 因此,进行垃圾回收的时候,应用程序进入暂停状态,即Stop-the-world。对于限定单个CPU的环境来说,Serial收集器没有线程交互(切换)开销,可以获得最高的单线程收集效率。
并行收集器也是针对新生代的垃圾收集器,基于标记-复制算法,可以看成是Serial的多线程版本。它充分利用了多处理器的优势,采用多个GC线程并行收集,在多处理器环境下工作的并行收集器能够极大地缩短Stop-the-world时间。除了多线程外,其余的行为、特点和Serial收集器一样。
同时,目前只有ParNew能与CMS收集器配合工作,因为CMS作为老年代收集器,但却无法与JDK1.4已经存在的新生代收集器Parallel Scavenge配合工作。同时因为因为Parallel Scavenge(以及G1)都没有使用传统的GC收集器代码框架,而另外独立实现,所以对于CMS来说,ParNew是必不可少的。
首先提示一下:吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值,即吞吐量=运行用户代码时间 /(运行用户代码时间 垃圾收集时间)。如虚拟机总运行了100分钟,其中垃圾收集花掉1分钟,那吞吐量就是99%。
Parallel Scanvenge收集器是针对新生代的垃圾收集器,标记-复制算法,和ParNew类似,但更注重吞吐率。它在ParNew的基础上提供了一组参数,用于配置期望的收集时间或吞吐量,然后以此为目标进行收集。
Parallel Scavenge收集器提供两个参数用于精确控制吞吐量:
因为可能导致垃圾收集发生得更频繁;
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。
CMS收集器仅作用于老年代的收集,是基于标记-清除算法的,它的过程分为4个步骤:
初始标记阶段主要做两件事:一是遍历GC Root可直达的老年代对象;二是遍历新生代直达的老年代对象。这里的直达是指直接关联到GC Root的一级对象。初始标记阶段是完全STW的,引用程序会暂停。通过-XX:+CMSParallelInitialMarkEnabled参数可以开启该阶段的并行标记,使用多个线程进行标记,减少暂停时间。
并发标记阶段是与应用程序一起执行的,这个阶段主要做两件事:
因为并发标记阶段与程序同时执行,因此会出现之前A->B->C变成A->C的情况,这种情况下C对象时无法在并发标记阶段被标记的。在标记阶段会使用三色标记算法。 三色标记法把 GC 中的对象划分成三种情况: 白色:还没有搜索过的对象(白色对象会被当成垃圾对象) 灰色:正在搜索的对象 黑色:搜索完成的对象(不会当成垃圾对象,不会被 GC)
(从大佬那边拿一张图) 这就是三色标记法。 我们能看出来,三色标记法是有很大的漏洞的,所以,采用了写入屏障的方法。就是说,如果A已经被标记了(已经是黑色的了),那么用户线程改动 A->C的时候,会自动把 C变成灰色,这样,以后就可以搜索 C了。
但是,如果在并发过程中线程又把已经失效的对象生效了,该怎么办?这时候,就要靠重新标记了。
初始标记、重新标记这两个步骤需要Stop-the-world。重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。例如这个阶段用户线程产生了新的对象,这个对象是白色的,总不能被GC掉吧。这个阶段就是为了让这些对象重新标记。这个阶段的停顿时间一般会比初始阶段稍长一些,但远比并发标记的时间短。
采用标记-清除算法进行清除
CMS收集器优点
并发收集、低停顿。
CMS收集器缺点
CMS收集器对CPU资源非常敏感。
CMS收集器无法处理浮动垃圾(Floating Garbage)。
(浮动垃圾:被标记为不可回收后又突然不用了,不会有很大问题,可以在下次GC中回收)
CMS收集器是基于标记-清除算法,该算法的缺点都有。
G1是一款面向服务端应用的垃圾收集器。G1具备如下特点:
特征 | G1 | CMS |
---|---|---|
并发和分代 | 是 | 是 |
最大化释放堆内存 | 是 | 否 |
低延时 | 是 | 是 |
吞吐量 | 高 | 低 |
压实 | 是 | 否 |
可预测性 | 强 | 弱 |
新生代和老年代的物理隔离 | 否 | 是 |
G1重新定义了堆空间,打破了原有的分代模型,将堆划分为一个个区域
(这张图不少文章里都有,我也就厚颜无耻的借来用了)
G1垃圾收集器在每个分区内部又分成了若干个大小为512 Byte卡片(Card),标识堆内存最小可用粒度所有分区的卡片将会记录在全局卡片表(Global Card Table)中。
JVM中分配的对象会占用物理上连续的若干个卡片,当查找对分区内对象的引用时便可通过记录卡片来查找该引用对象(见RSet)。每次对内存的回收,都是对指定分区的卡片进行处理。
G1同样可以指定堆的大小。
当发生年轻代收集或混合收集时,通过计算GC与应用的耗费时间比,自动调整堆空间大小。如果GC频率太高,则通过增加堆尺寸,来减少GC频率,相应地GC占用的时间也随之降低。
目标参数**-XX:GCTimeRatio**即为GC与应用的耗费时间比,G1默认为9,而CMS默认为99,因为CMS的设计原则是耗费在GC上的时间尽可能的少。另外,当空间不足,如对象空间分配或转移失败时,G1会首先尝试增加堆空间,如果扩容失败,则发起担保的Full GC。
Full GC后,堆尺寸计算结果也会调整堆空间。
G1将内存在逻辑上划分为年轻代和老年代,其中年轻代又划分为Eden空间和Survivor空间。但年轻代空间并不是固定不变的,当现有年轻代分区占满时,JVM会分配新的空闲分区加入到年轻代空间。
G1中新对象始终分配在Eden里面,经过一次垃圾回收的对象就被移动到Survisor区了,经过数次(15次)垃圾回收之后还活着的对象会被移到Old区。
整个年轻代内存会在初始空间**-XX:G1NewSizePercent(默认整堆5%)与最大空间-XX:G1MaxNewSizePercent(默认60%)之间动态变化,且由参数目标暂停时间-XX:MaxGCPauseMillis(默认200ms)**、需要扩缩容的大小以及分区的记忆集合(RSet)计算得到。
这里有个问题,为什么JVM的分代年龄为什么是15?(十五次后从年轻代进入老年代)
我们在前文中提过 (包罗万象——JAVA中的锁),HotSpot的对象头主要包括两部分数据:Mark Word(标记字段)、Klass Pointer(类型指针),而Mark Word中默认存储对象的HashCode,分代年龄和锁标志位信息。在HotSpot中,有4bit用于存储对象分代年龄。
明白了吗,对象的分代年龄占4位,也就是0000,最大值为1111也就是最大为15。
JVM的第一章中,我们提过TLAB。应用线程可以独占一个本地缓冲区(TLAB)来创建的对象,而大部分都会落入Eden区域(巨型对象或分配失败除外),因此TLAB的分区属于Eden空间。
而每次垃圾收集时,每个GC线程同样可以独占一个本地缓冲区(GCLAB)用来转移对象,每次回收会将对象复制到Suvivor空间或老年代空间。对于从Eden/Survivor空间晋升到Survivor/老年代空间的对象,同样有GC独占的本地缓冲区进行操作,该部分称为晋升本地缓冲区(PLAB)。
G1对内存的使用以分区(Region)为单位,而对对象的分配则以卡片(Card)为单位。
有时候,对象太大的话,就不能再TLAB中进行分配(比如超过一个分区)。
分配巨型对象时直接分配到老年代分区,如果一个对象的大小超过一个分区的大小,那么会直接在老年代分配两个连续的分区来存放该巨型对象。巨型分区一定是连续的,分配之后也不会被移动(没有意义啊)。
在JDK8u40之前,巨型对象的回收只能在并发收集周期的清除阶段或FULL GC过程中过程中被回收,在JDK8u40(包括这个版本)之后,一旦没有任何其他对象引用巨型对象,那么巨型对象也可以在年轻代收集中被回收。
G1垃圾收集器为了避免出现STW式的整堆扫描,在每个分区记录了一个已记忆集合(RSet),内部类似一个反向指针,记录引用分区内对象的卡片索引。当要回收该分区时,通过扫描分区的RSet,来确定引用本分区内的对象是否存活,进而确定本分区内的对象存活情况。
但是并非所有的引用都需要记录在RSet中,G1 GC每次都会对年轻代进行整体收集,因此引用源自年轻代的对象,不需要在RSet中记录。只有老年代的分区可能会有RSet记录。同时如果一个分区确定需要扫描,那么无需RSet也可以无遗漏的得到引用关系,引用源自本分区的对象,就不用记录在RSet中。
G1通过维护RSet,得到准确的分区引用信息,而RSet的维护主要来源两个方面:写栅栏(Write Barrier) 和并发优化线程(Concurrence Refinement Threads)。
收集集合(CSet)代表每次GC暂停时回收的一系列目标分区
在任意一次收集暂停中,CSet所有分区都会被释放,内部存活的对象都会被转移到分配的空闲分区中。年轻代收集CSet只容纳年轻代分区,而混合收集会通过启发式算法,在老年代候选回收分区中,筛选出回收收益最高的分区添加到CSet中。
还是问大佬借一张图给大家看看什么是CSet
G1主要有两种GC模式,Young GC和Mix GC,两种都是需要Stop The World(STW)的
流程:
Mix GC中包括了Young GC 和 Old GC
流程:
这个阶段不能发生年轻代收集,如果中途 Eden 区真的满了,也要等待这个阶段结束才能进行 Young GC。
这个阶段是并发执行的,中间可以发生多次 Young GC,Young GC 会中断标记过程
这个阶段会回收完全空闲的区块
除了Young GC 和 Old GC,当G1无法在堆空间中申请新的分区时,G1便会触发担保机制,执行一次STW式的、单线程的Full GC。Full GC会对整堆做标记清除和压缩,最后将只包含纯粹的存活对象。
G1在以下场景中会触发Full GC,同时会在日志中记录to-space-exhausted以及Evacuation Failure:
G1垃圾收集器还有不少的参数设置,这里就一起介绍给大家
-XX:+UseG1GC 使用 G1 收集器
-XX:MaxGCPauseMillis=200 指定目标停顿时间,默认值 200 毫秒。
在设置XX:MaxGCPauseMillis 值的时候,不要指定为平均时间,而应该指定为满足 90% 的停顿在这个时间之内。
记住,停顿时间目标是我们的目标,不是每次都一定能满足的。
-XX:InitiatingHeapOccupancyPercent=45
整堆使用达到这个比例后,触发并发 GC 周期,默认 45%。
如果要降低晋升失败的话,通常可以调整这个数值,使得并发周期提前进行
-XX:NewRatio=n 老年代/年轻代,默认值 2,即 1/3 的年轻代,2/3 的老年代
不要设置年轻代为固定大小,否则:
G1 不再需要满足我们的停顿时间目标
不能再按需扩容或缩容年轻代大小
-XX:SurvivorRatio=n Eden/Survivor,默认值 8,这个和其他分代收集器是一样的
-XX:MaxTenuringThreshold =n 从年轻代晋升到老年代的年龄阈值,也是和其他分代收集器一样的
-XX:G1HeapRegionSize=n
每一个 region 的大小,默认值为根据堆大小计算出来,取值 1MB~32MB,这个我们通常指定整堆大小就好了。
-XX:ConcGCThreads=n 并发标记阶段的垃圾收集线程数
增加这个值可以让并发标记更快完成,如果没有指定这个值,JVM 会通过以下公式计算得到:
ConcGCThreads=(ParallelGCThreads + 2) / 4^3
-XX:ParallelGCThreads=n 并行收集时候的垃圾收集线程数
jdk1.7 默认垃圾收集器Parallel Scavenge(新生代)+Parallel Old(老年代)
jdk1.8 默认垃圾收集器Parallel Scavenge(新生代)+Parallel Old(老年代)
jdk1.9 默认垃圾收集器G1
通过学习JVM的垃圾收集器,不是让我们去真的自己写这些,而是让我们在工作中可以根据不同的情况合理的分配对象的大小、设置合适的参数。通过JVM参数的设置,再加上代码的review,我们每个人都可以写出优质的代码。
JVM最后一章也写完了。写的过程中复习了很多东西,看完这个感觉面试、调优什么的都会有一点点进步。如果大家觉得还看得过去的话,动动小手点个赞什么的就是对我最大的支持了see you! 同时需要思维导图的话,可以联系我,毕竟知识越分享越香!