垃圾收集器

Minor GC
当年轻代空间不足时，就会触发Minor GC,这里的年轻代满指的是Eden满，Survivor满不会触发GC。(每次Minor GC 会清理年轻代的内存)
因为Java对象大多都具备朝生熄灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。
Minor GC会引发STW，暂停其他用户的线程，等垃圾回收结束，用户线程才恢复运行。
Major GC
出现major gc经常伴随至少一次的Minor GC(但非绝对的，在Paraller Scavenge 收集器的收集策略中就有直接进行Major GC的策略选择过程)
也就是说在老年代空间不足时，会先尝试触发Minor GC，如果之后空间还不足，会触发Major GC。
Maror GC的速度一般会比Minor GC慢10倍以上，STW的时间更长。
如果Major GC后，内存还不足，就会报OOM.
Full GC
调用System.gc()时。系统建议执行Full GC，但是不必然执行
老年代空间不足
方法区空间不足
通过Minor GC后进入老年代的平均大小大于老年代的可用内存
由Eden区，幸存者0区向幸存者1区复制时，对象大小大于1区可用内存，则把该对象转存到老年代，且老年代的可用内存大小小于该对象大小。
注意：full GC是开发或调优中尽量要避免的，这样STW会短一些

新生代	Serial	ParNew	Parallel Scavenge	G1	Zgc
老年代	Serial Old	Cms	Parallel Old	G1	Zgc

STW-stop the word 当执行垃圾回收的时候会停止所有的业务线程

Serial 是单线程垃圾回收，当中会采取STW机制，如果业务量巨大占用内存过多，则会等待很长时间。采用的复制算法。

Serial Old和Serial是一组，当然他们也可以和ParNew以及Cms交叉使用，也使用的单线程采用的是标记整理算法或者叫标记压缩算法。

ParNew:

如果说Serial GC是年轻代中的单线程垃圾收集器,那么ParNew收集器则是Serial收集器的多线程版本,ParNew收集器除了采用并行回收的方式执行内存回收外,两款垃圾收集器之间几乎没有任何区别

ParNew收集器在年轻代中同样也是采用复制算法,"Stop the World"机制,ParNew是很多JVM运行在Server模式下新生代的默认垃圾收集器

对于新生代,回收次数频繁,使用并行方式高效,对于老年代,回收次数少,使用串行方式节省资源(CPU并行需要切换线程,串行可以省去切换线程的资源)

由于ParNew收集器是基于并行回收,那么是否可以判定ParNew收集器的回收效率在任何场景下都会比Serial收集器更高效?

ParNew收集器运行在多CPU的环境下,由于可以充分利用多CPU,多核心等物理硬件资源优势,可以更快地完成垃圾收集,提升程序的吞吐量

但是在单个CPU的环境下,ParNew收集器,不比Serial收集器更高效,虽然Serial收集器是基于串行回收,但是由于CPU不需要频繁地做任务切换,因此可以有效避免多线程交互过程中产生的一些额外开销
除Serial外,目前只有ParNew GC能与CMS收集器配合工作

通过"-XX:+UseParNewGC"手动指定使用ParNew收集器执行内存回收任务,它表示年轻代使用并行收集器,不影响老年代

通过"-XX:ParallelGCThreads"限制线程数量,默认开启和CPU数据相同的线程数

Parallel Scavenge以及Parallel Old：

HotSpot的年轻代中除了拥有ParNew收集器是基于并行回收的以外,Parallel Scavenge收集器同样也采用了复制算法,并行回收和"Stop the World"机制

和ParNew收集器不同,Parallel Scavenge收集器的目标是达到一个可控制的吞吐量(Throughput),它也被称为吞吐量优先的垃圾收集器

自适应调节策略也是Parallel Scavenge与ParNew一个重要区别

高吞吐量则可以高效率地利用CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务,因此,常见在服务器环境中使用,例如那些执行批量处理,订单处理,工资支付,科学计算的应用程序

Parallel收集器在jdk1.6时提供了用于执行老年代垃圾收集的Parallel Old收集器,用来代替老年代的Serial Old收集器

Parallel Old收集器采用了标记-压缩算法,同样也是基于并行回收和"Stop the World"机制
"-XX:+UseParallelGC"手动指定年轻代使用Parallel并行收集器执行内存回收任务
"-XX:+UseParallelOldGC"手动指定老年代使用并行回收收集器
上面两个参数分别适用于新生代和老年代,jdk8默认是开启的.上面两个参数,默认开启一个,另一个也会被开启(互相激活)
"-XX:ParallelGCThreads"设置年轻代并行收集器的线程数,最好与CPU数量相等,以避免过多的线程数影响垃圾收集性能,在默认情况下,CPU数量小于8,ParallelGCThreads的值等于CPU数量,当CPU数量大于8,ParallelGCThreads的值等于3+(5*CPU_COUNT/8)
"-XX:MaxGCPauseMillis"设置垃圾收集器最大停顿时间(即STW的时间)单位是毫秒(该参数使用需谨慎)
为了尽可能地把停顿时间控制在MaxGCPauseMillis以内,收集器在工作时会调整Java堆大小或者其他一些参数
对于用户来讲,停顿时间越短体验越好,但是在服务器端,我们注重高并发,整体的吞吐量,所以服务器端适合Parallel,进行控制
"-XX:GCTimeRatio"垃圾收集时间占总时间的比例(=1/(N+1)),用于衡量吞吐量的大小
取值范围(0,100),默认99,也就是垃圾回收时间不超过1%
与前一个-XX:MaxGCPauseMillis参数有一定矛盾性,暂停时间越长,Radio参数就越容易超过设定的比例
"-XX:+UseAdaptiveSizePolicy"设置Parallel Scavenge收集器具有自适应调节策略
在这种模式下,年轻代的大小,Eden和Survivor的比例,晋升老年代的对象年龄等参数会被自动调整,已到达在堆大小,吞吐量和停顿时间之间的平衡点
在手动调优比较困难的场合,可以直接使用这种自适应的方式,仅指定虚拟机的最大堆,目标的吞吐量和停顿时间,让虚拟机自己完成调优工作

Cms：低延时（三色标记算法可以异步执行，从而可以以中断时间极少的代价或者完全没有中断来进行整个 GC。三色标记白色标记未被扫描标记到的对象，灰色表示被扫描标记的对象，其子节点还没有来得及扫描标记，黑色表示自己被扫描标记的同时，子节点也被扫描标记了）

在jdk1.5时期,HotSpot推出了一款在强交互应用中几乎认为有划时代意义的垃圾收集器,CMS(Concurrent-Mark-Sweep)收集器,这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器,它第一次实现了让垃圾收集器线程与用户线程同时工作

CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间,停顿时间越短(低延迟)就越适合与用户交互的程序,良好的响应速度能提升用户体验.目前很大一部分的Java应用集中在web网站或者B/S系统的服务端上,这类应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验,CMS收集器就非常符合这类应用的需求

CMS的垃圾收集算法采用标记-清除算法,并且也会"Stop the World "

CMS作为老年代的收集器,却无法与jdk1.4中已经存在的新生代收集器Parallel Scavenge配合工作,所以在jdk1.5中使用CMS来收集老年代的时候,新生代只能选择ParNew或者Serial收集器中的一个

在G1出现之前,CMS使用还是非常广泛的,一直到今天,仍然有很多系统使用CMS GC

CMS整个过程比之前的收集器都要复杂,整个过程分为4个阶段：

1.初始标记阶段

2.并发标记阶段

3.重新标记阶段

4.并发清除阶段

初始标记阶段(Initial-Mark):（STW）

在这个阶段中,程序中所有的工作线程都将会因为"Stop the World"机制而出现短暂的暂停,这个阶段主要任务仅仅只是标记出GC Roots能直接关联到的对象,一旦标记完成之后就会恢复之前被暂停的所有应用线程,由于直接关联对象比较少,所以这里速度非常快

补充：Gc Roots的对象包括：

1.栈中引用的对象

2.方法区中静态变量引用的对象

3.方法区中常量引用的对象

4.本地方法栈中JNI引用的对象

并发标记阶段(Concurrent-Mark): （一开始所有的对象都是白色的，三色标记算法将GC roots标记为灰色接着如果扫描到灰色对象下有引用对象，会把原先灰色的对象置为黑色，然后把原先灰色对象指向的变量都置为灰色，以此类推。）

此阶段不需要 Stop The World，用户线程和 GC 线程可以一起执行

可能出现两个问题：

1.浮动垃圾（下一次扫描的时候会把这个对象当作垃圾来及回收，问题不大）

2.漏标

浮动垃圾解释： 由于标记为灰色的下一个节点还没来得及扫描标记，本来是需要来扫描的，但是随着用户线程的执行，这个对象的引用断了，因此没有标记还是白色的，变成了浮动垃圾，下一次扫描的时候会被当作成垃圾进行回收。

漏标解释: 首先需要知道一个概念，就是黑色标记的对象下一次扫描就不需要扫描他的孩子节点了，因为孩子是灰色的他能被标记为黑。同样的还是灰色的对象上原本挂了一个还未来得及扫描并标记的对象，随着用户线程的执行，此时这个孩子对象和原来的灰色的引用断开了导致无法扫描，但是此时又被黑色对象所引用，但是此时黑色对象的孩子节点是不会再扫描的。所以就导致了这个节点无法被扫描标记，产生了漏标。

解决漏标问题---写屏障+增量更新方式
在并发标记阶段当我们黑色对象引用关联白色对象则记录下黑色对象。

在重新标记阶段（所有用户线程暂停），将黑色对象变为灰色对象将整个引用链全部扫描。

缺点：遍历整个链的效率非常低，有可能会导致用户线程等待的时间非常长。

从GC Roots的直接关联对象开始遍历整个对象链的过程,这个过程耗时较长,但是不需要停顿用户线程,可以与垃圾收集线程一起并发运行（由于线程的并发执行，这个阶段可能出现已经标记过的对象后面没有引用指向它了，或者未被标记的对象又被重新引用了）

重新标记阶段(Remark): （STW）

由于在并发标记阶段中,程序工作线程会和垃圾收集线程同时运行或交叉运行,因此为了修正并发标记期间,因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间通常会比初始标记阶段稍长一些,但也远比并发标记阶段的时间短（必须要STW一下，如果用户线程一直和垃圾回收线程并发运行，永远无法正确标记）

并发清除阶段(Concurrent-Sweep):

此阶段清理删除掉标记阶段判定的已经死亡的对象,释放内存空间,由于不需要移动存活对象,所以这个阶段也是可以与用户线程同时并发的

由于最耗费时间的并发标记与并发清除阶段都是不需要暂停用户线程的,所以整体的回收是低延迟的

尽管CMS收集器采用的是并发回收(非独占式),但是在其初始化标记和再次标记这两个阶段中仍然需要执行"Stop the world"机制暂停程序中的工作线程,不过暂停时间并不会太长,因此可以说明目前所有的垃圾收集器都做不到完全不需要"Stop the World",只是尽可能地缩短暂停时间

另外,由于在垃圾收集阶段用户线程没有中断,所以在CMS回收过程中,还应该确保应用程序用户线程有足够的内存可用,因此,CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集,而是当堆内存使用率达到某一阈值时,便开始进行回收,以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行.要是CMS运行期间预留的内存无法满足程序需要,就会出现一次"Concurrent Mode Failure"失败,这时虚拟机将启动后备预案: 临时启动Serial Old收集器来重新进行老年代的垃圾收集,这样停顿时间就很长了

CMS收集器的垃圾收集算法采用的是标记-清除算法,这意味着每次执行完内存回收后,由于被执行内存回收的无用对象占用的内存空间极有可能是不连续的内存块,不可避免地将会产生一些内存碎片,那么CMS在为新对象分配内存空间时,将无法使用指针碰撞技术,而只能够选择空闲列表执行内存分配

CMS的优点:并发收集,低延迟

CMS的弊端

会产生内存碎片,导致并发清除后,用户线程可用的空间不足,在无法分配大对象的情况下,不得不提前触发Full GC
CMS收集器对CPU资源非常敏感,在并发阶段,它虽然不会导致用户停顿,但是会因为占用了一部分线程而导致应用程序变慢,总吞吐量降低

CMS收集器无法处理浮动垃圾,可能出现"Concurrent Mode Failure"失败而导致另一次Full GC的产生,在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或交叉运行的,那么在并发阶段如果产生新的垃圾对象,CMS将无法对这些垃圾对象进行标记,最终会导致这些新产生的垃圾对象没有被及时回收,从而只能在下一次执行GC时释放这些之前未被回收的内存空间

在通常意义上人们口中说的Full GC为一次特殊GC行为的描述，这次GC会回收整个堆的内存，包含老年代，新生代，metaspace等，这个是最常见的一种认知，很多人也就了解到这个程度，因此在遇到一些特殊场景的时候就会发现实际情况和自己的认知会发生冲突

从GC日志上
在gc.log中会发现在部分gc日志头中也有Full GC这样的字眼，这里表示的含义是在这次GC的全过程中，都是Stop The world的状态，也就是说在这次GC的全过程中所有用户线程都是处于暂停的状态，那么在这里要喷一下中文jvm神书《深入理解JVM》了，在第二版第89页有这么一段话：

“-XX:+UseConcMarkSweepGC” 手动指定使用CMS收集器执行内存回任务

-XX:+UseParNewGC打开,即ParNew(Young区)+CMS(Old区)+Serial Old组合

“-XX:CMSlnitiatingOccupanyFraction” 设置堆内存使用率的阈值,一旦达到该阈值,便开始回收

jdk5及以前版本的默认值为68,即当老年代的空间使用率达到68%时,会执行一次CMS回收,jdk6及以后版本默认值为92%

如果内存增长缓慢,则可以设置一个稍大的值,大的阈值可以有效降低CMS的触发频率,减少老年代回收的次数可以较为明显地改善应用程序性能,反之,如果应用程序内存使用率增长很快,则应该降低这个阈值,以避免频繁触发老年代串行收集器,因此通过该选项便可以有效降低Full GC的执行次数

“-XX:+UseCMSCompactAtFullCollection” 用于指定在执行完Full GC后对内存空间进行压缩整理,以此避免内存碎片的产生,不过由于内存压缩整理过程无法并发执行,所带来的问题就是停顿时间变得更长了

“-XX:CMSFullGCsBeforeCompaction” 设置在执行多少次Full GC后对内存空间进行压缩整理

“-XX:ParallelCMSThreads” 设置CMS的线程数量

CMS默认启动的线程数是(ParallelGCThreads+3)/4,ParallelGCThreads是年起代并行收集器的线程数,当CPU资源比较紧张时,收到CMS收集器线程数的影响,应用程序的性能在垃圾回收阶段可能会非常糟糕

G1：

G1(Garbage-First)回收器是在JDK1.7中正式使用的全新垃圾回收器，G1拥有独特的垃圾回收策略，从分代上看，G1依然属于分代垃圾回收器，它会区分年代和老年代，依然有eden和survivor区，但从堆的结构上看，它并不要求整个eden区、年清代或者老年代都连续。它使用了全新的分区算法。

其特点如下：

• 并行性：G1在回收期间，可以由多个GC线程同时工作，有效利用多核计算能力。
• 并发性：G1拥有与应用程序交替执行的能力，因此一般来说，不会在整个回收期间完全阻塞应用程序。
• 分代GC：与之前回收器不同，其他回收器，它们要么工作在年轻代要么工作在老年代。G1可以同时兼顾年轻代与老年代。
• 空间整理：G1在回收过程中，会进行适当的对象移动，不像CMS，只是简单的标记清除，在若干次GC后CMS必须进行一次碎片整理，G1在每次回收时都会有效的复制对象，减少空间碎片。
• 可预见性：由于分区的原因，G1可以只选取部分区域进行内存回收，这样缩小了回收范围，因此对于全局停顿也能得到更好的控制。

一、G1的内存划分和主要收集过程

G1收集回收器将堆进行分区，划分为一个个的区域，每次收集的时候，只收集其中几个区域，以此来控制垃圾回收产生一次停顿时间。

G1的收集过程可能有4个阶段：

• 新生代GC
• 并发标记周期
• 混合收集
• （如果需要）进行Full GC。

二、G1的新生代GC

新生代GC的主要工作是回收eden区和survivor区。

一旦eden区被占满，新生代GC就会启动。新生代GC收集前后的堆数据如下图所示，其中E表示eden区，S表示survivor区，O表示老年代。

可以看到，新生代GC只处理eden和survivor区，回收后，所有的eden区都应该被清空，而survivor区会被收集一部分数据，但是应该至少仍然存在一个survivor区，类比其他的新生代收集器，这一点似乎并没有太大变化。另一个重要的变化是老年代的区域增多，因为部分survivor区或者eden区的对象可能会晋升到老年代。

三、G1并发标记周期（针对老年代）

G1的并发阶段和CMS有些类似，它们都是为了降低一次停顿时间，而将可以和应用程序并发执行的部分单独提取出来执行。

并发标记周期可分为以下几步：

• 初始标记：标记从根节点直接可达的对象。这个阶段会伴随一次新生代GC，它是会产生全局停顿的，应用程序在这个阶段必须停止执行。（STW）
• 根区域扫描：由于初始标记必然会伴随一次新生代GC，所以在初始化标记后，eden被清空，并且存活对象被移到survivor区。在这个阶段，将扫描由survivor区直接可达的老年代区域，并标记这些直接可达的对象。这个过程是可以和应用程序并发执行的。但是根区域扫描不能和新生代GC同时发生（因为根区域扫描依赖survivor区的对象，而新生代GC会修改这个区域），故如果恰巧此时需要新生代GC，GC就需要等待根区域扫描结束后才能进行，如果发生这种情况，这次新生代GC的时间就会延长。
• 并发标记：和CMS类似，并发标记将会扫描并查找整个堆的存活对象，并做好标记。这是一个并发过程，并且这个过程可以被一次新生代GC打断。
• 重新标记：和CMS一样，重新标记也是会使应用程序停顿，由于在并发标记过程中，应用程序依然运行，因此标记结果可能需要修正，所以在此阶段对上一次标记进行补充。在G1中，这个过程使用SATB（Snapshot-At-The-Begining）算法完成，即G1会在标记之初为存活对象创建一个快照，这个快照有助于加速重新标记的速度。
• 独占清理：顾名思义，这个阶段会引起停顿。它将计算各个区域的存活对象和GC回收比例并进行排序，识别可供混合回收的区域。在这个阶段，还会更新记忆集。该阶段给出了需要被混合回收的区域并进行了标记，在混合回收阶段，需要这些信息。
• 并发清理阶段：识别并清理完全空闲的区域。它是并发的清理，不会引起停顿。

SATB全称是Snapshot-At-The-Beginning，由字面理解，是GC开始时活着的对象的一个快照。它是通过Root Tracing得到的，作用是维持并发GC的正确性。那么它是怎么维持并发GC的正确性的呢？根据三色标记算法，我们知道对象存在三种状态：白：对象没有被标记到，标记阶段结束后，会被当做垃圾回收掉。灰：对象被标记了，但是它的field还没有被标记或标记完。黑：对象被标记了，且它的所有field也被标记完了。

SATB 利用 write barrier 将所有即将被删除的引用关系的旧引用记录下来，最后以这些旧引用为根 Stop The World 地重新扫描一遍即可避免漏标问题。 因此G1 Remark阶段 Stop The World 与 CMS了的remark有一个本质上的区别，那就是这个暂停只需要扫描有 write barrier 所选中对象为根的对象， 而 CMS 的remark 需要重新扫描整个根集合，因而CMS remark有可能会非常慢。

四、混合回收

在并发标记周期中，虽有部分对象被回收，但是回收的比例是非常低的。但是在并发标记周期后，G1已经明确知道哪些区域含有比较多的垃圾对象，在混合回收阶段，就可以专门针对这些区域进行回收。当然G1会优先回收垃圾比例较高的区域（回收这些区域的性价比高），这正是G1名字的由来（Garbage First Garbage Collector：译为垃圾优先的垃圾回收器），这里的垃圾优先（Garbage First）指的是回收时优先选取垃圾比例最高的区域。

这个阶段叫做混合回收，是因为在这个阶段，即会执行正常的年轻代GC,又会选取一些被标记的老年代区域进行回收，同时处理了新生代和老年代。

混合回收会被执行多次，直到回收了足够多的内存空间，然后，它会触发一次新生代GC。新生代GC后，又可能会发生一次并发标记周期的处理，最后又会引起混合回收，因此整个过程可能是如下图：

五、必要时的Full GC

和CMS类似，并发收集让应用程序和GC线程交替工作，因此在特别繁忙的情况下无可避免的会发生回收过程中内存不足的情况，当遇到这种情况，G1会转入一个Full GC 进行回收。

以下4种情况会触发这类的Full GC：

1、并发模式失效

G1启动标记周期，但在Mix GC之前，老年代就被填满，这时候G1会放弃标记周期。这种情形下，需要增加堆大小，或者调整周期（例如增加线程数-XX:ConcGCThreads等）。

解决办法：发生这种失败意味着堆的大小应该增加了，或者G1收集器的后台处理应该更早开始，或者需要调整周期，让它运行得更快（如，增加后台处理的线程数）。

2、晋升失败

（to-space exhausted或者to-space overflow）

G1收集器完成了标记阶段，开始启动混合式垃圾回收，清理老年代的分区，不过，老年代空间在垃圾回收释放出足够内存之前就会被耗尽。（G1在进行GC的时候没有足够的内存供存活对象或晋升对象使用），由此触发了Full GC。

这种失败通常意味着混合式收集需要更迅速的完成垃圾收集：每次新生代垃圾收集需要处理更多老年代的分区。

解决这种问题的方式是：

• 增加 -XX:G1ReservePercent选项的值（并相应增加总的堆大小），为“目标空间”增加预留内存量。
• 通过减少 -XX:InitiatingHeapOccupancyPercent 提前启动标记周期。
• 也可以通过增加 -XX:ConcGCThreads 选项的值来增加并行标记线程的数目。

3、疏散失败

（to-space exhausted或者to-space overflow）

进行新生代垃圾收集是，Survivor空间和老年代中没有足够的空间容纳所有的幸存对象。这种情形在GC日志中通常是：

这条日志表明堆已经几乎完全用尽或者碎片化了。G1收集器会尝试修复这一失败，但可以预期，结果会更加恶化：G1收集器会转而使用Full GC。

解决这种问题的方式是：

• 增加 -XX:G1ReservePercent选项的值（并相应增加总的堆大小），为“目标空间”增加预留内存量。
• 通过减少 -XX:InitiatingHeapOccupancyPercent 提前启动标记周期。
• 也可以通过增加 -XX:ConcGCThreads 选项的值来增加并行标记线程的数目。

4、Humongous Object 分配失败

当Humongous Object 找不到合适的空间进行分配时，就会启动Full GC，来释放空间。这种情况下，应该避免分配大量的巨型对象，增加内存或者增大-XX:G1HeapRegionSize，使巨型对象不再是巨型对象。

对于Humongous Object 的处理还有一种方式就是切换GC算法到ZGC，因为ZGC中对于Humongous Object 的回收不会特殊处理（比如不会延迟收集）。

六、巨型对象

Humongous Object：巨型对象 Humongous regions：巨型区域

对于G1而言，只要超过regin大小的一半，就被认为是巨型对象。巨型对象直接被分配到老年代中的“巨型区域”。这些巨型区域是一个连续的区域集。StartsHumongous 标记该连续集的开始，ContinuesHumongous 标记它的延续。

在分配巨型对象之前先检查是否超过 initiating heap occupancy percent和the marking threshold, 如果超过的话，就启动global concurrent marking，目的是提早回收，防止 evacuation failures 和 Full GC。

对于巨型对象，有以下几个点需要注意：

• 没有被引用的巨型对象会在标记清理阶段或者Full GC时被释放掉。
• 为了减少拷贝负载，只有在Full GC的时候，才会压缩大对象region。
• 每一个region中都只有一个巨型对象，该region剩余的部分得不到利用，会导致堆碎片化。
• 如果看到由于大对象分配导致频繁的并发回收，需要把大对象变为普通的对象，建议增大Region size。（或者切换到ZGC）

对于增大Region size有一个负面影响就是：减少了可用region的数量。因此，对于这种情况，你需要进行相应的测试，以查看是否实际提高了应用程序的吞吐量或延迟。

七、常见调优参数

1、-XX:MaxGCPauseMillis=N

默认200毫秒

前面介绍过使用GC的最基本的参数：

-XX:+UseG1GC -Xmx32g -XX:MaxGCPauseMillis=200

前面2个参数都好理解，后面这个MaxGCPauseMillis参数该怎么配置呢？这个参数从字面的意思上看，就是允许的GC最大的暂停时间。G1尽量确保每次GC暂停的时间都在设置的MaxGCPauseMillis范围内。那G1是如何做到最大暂停时间的呢？这涉及到另一个概念，CSet(collection set)。它的意思是在一次垃圾收集器中被收集的区域集合。

• Young GC：选定所有新生代里的region。通过控制新生代的region个数来控制young GC的开销。
• Mixed GC：选定所有新生代里的region，外加根据global concurrent marking统计得出收集收益高的若干老年代region。在用户指定的开销目标范围内尽可能选择收益高的老年代region。

在理解了这些后，我们再设置最大暂停时间就有了方向。首先，我们能容忍的最大暂停时间是有一个限度的，我们需要在这个限度范围内设置。但是应该设置的值是多少呢？我们需要在吞吐量跟MaxGCPauseMillis之间做一个平衡。如果MaxGCPauseMillis设置的过小，那么GC就会频繁，吞吐量就会下降。如果MaxGCPauseMillis设置的过大，应用程序暂停时间就会变长。G1的默认暂停时间是200毫秒，我们可以从这里入手，调整合适的时间。

2、-XX:G1HeapRegionSize=n

设置的 G1 区域的大小。值是 2 的幂，范围是 1 MB 到 32 MB 之间。目标是根据最小的 Java 堆大小划分出约 2048 个区域。

• -XX:ParallelGCThreads=n（调整G1垃圾收集的后台线程数）

设置 STW 工作线程数的值。将 n 的值设置为逻辑处理器的数量。n 的值与逻辑处理器的数量相同，最多为 8。

如果逻辑处理器不止八个，则将 n 的值设置为逻辑处理器数的 5/8 左右。这适用于大多数情况，除非是较大的 SPARC 系统，其中 n 的值可以是逻辑处理器数的 5/16 左右。

-XX:ConcGCThreads=n（调整G1垃圾收集的后台线程数）

设置并行标记的线程数。将 n 设置为并行垃圾回收线程数 (ParallelGCThreads) 的 1/4 左右。

3、 -XX:InitiatingHeapOccupancyPercent=45（调整G1垃圾收集运行频率）

设置触发标记周期的 Java 堆占用率阈值。默认占用率是整个 Java 堆的 45%。

该值设置太高：会陷入Full GC泥潭之中，因为并发阶段没有足够的时间在剩下的堆空间被填满之前完成垃圾收集。

如果该值设置太小：应用程序又会以超过实际需要的节奏进行大量的后台处理。

避免使用以下参数：避免使用 -Xmn 选项或 -XX:NewRatio 等其他相关选项显式设置年轻代大小。固定年轻代的大小会覆盖暂停时间目标。

八、细节

1、G1 mixed GC时机？

mixed gc中也有一个阈值参数 -XX:InitiatingHeapOccupancyPercent，当老年代大小占整个堆大小百分比达到该阈值时，会触发一次mixed gc.

在分配humongous object之前先检查是否超过 initiating heap occupancy percent, 如果超过的话，就启动global concurrent marking，为的是提早回收，防止 evacuation failures 和 Full GC。

为了减少连续H-objs分配对GC的影响，需要把大对象变为普通的对象，建议增大Region size。

一个Region的大小可以通过参数-XX:G1HeapRegionSize设定，取值范围从1M到32M，且是2的指数。

2、XX：G1 HeapRegionSize 默认值？

默认把堆内存按照2048份均分，最后得到一个合理的大小。

3、直接内存配置

Q: 什么时候用直接内存？

A: 读写频繁的场合，出于性能考虑，可以考虑使用直接内存。

直接内存也是 Java 程序中非常重要的组成部分，特别是 NIO 被广泛使用之后，直接内存可以跳过 Java 堆，使 Java 程序可以直接访问原生堆空间。因此可以在一定程度上加快内存的访问速度。直接内存可以用 -XX:MaxDirectMemorySize 设置，默认值为最大堆空间，也就是 -Xmx。当直接内存达到最大值的时候，也会触发垃圾回收，如果垃圾回收不能有效释放空间，直接内存溢出依然会引起系统的 OOM。

一般而言直接内存在访问读写上直接内存有较大优势（速度较快），但是在内存空间申请的时候，直接内存毫无优势而言。

4、RSet

全称是Remembered Set，是辅助GC过程的一种结构，典型的空间换时间工具，和Card Table有些类似。G1的RSet是在Card Table的基础上实现的：每个Region会记录下别的Region有指向自己的指针，并标记这些指针分别在哪些Card的范围内。这个RSet其实是一个Hash Table，Key是别的Region的起始地址，Value是一个集合，里面的元素是Card Table的Index。

RSet究竟是怎么辅助GC的呢？

在做YGC的时候，只需要选定young generation region的RSet作为根集，这些RSet记录了old->young的跨代引用，避免了扫描整个old generation。而mixed gc的时候，old generation中记录了old->old的RSet，young->old的引用由扫描全部young generation region得到，这样也不用扫描全部old generation region。所以RSet的引入大大减少了GC的工作量。

__EOF__

本文作者：liuliu的小家
本文链接：https://www.cnblogs.com/liu-jin/p/17398126.html
关于博主：hello~好久不见，喜欢的话点个赞吧
版权声明：本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！
声援博主：如果您觉得文章对您有帮助，可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力！