不可错过的CMS学习笔记

  • 时间:
  • 浏览:2
  • 来源:大发5分6合_大发5分6合官方

-XX:ErrorFile=/home/admin/logs/xelephant/hs_err_pid%p.log

what-is-the-threshold-for-cms-old-gc-to-be-triggered

Introduce to CMS Collector

愿因分析我的应用决定使用CMS采集器,推荐的JVM参数是那先 ?我当事人的应用使用的参数如下,是根据PerfMa的xxfox生成的,朋友也都都里能 使用某些产品调优当事人的JVM参数:

-XX:+CMSClassUnloadingEnabled

CMS和Full gc否有一回事?

我以前 对CMS的理解,以为它是针对老年代的采集器。今天查阅了《Java性能优化权威指南》和《Java性能权威指南》两本书,确认以前 的理解是错误的。

6. 并发清除:用户守护程序运行运行被重新激活,同時 将那先 未被标记为存活的对象标记为不可达;

Java SE的内存管理白皮书

xxfox:PerfMa的参数调优神器

CMS相关的参数总结(前要注意的是,这里我如此考虑太满JDK版本的问题报告 ,JDK1.7和JDK1.8那先 参数的配置,某些默认值愿因分析不一样,具体使用的以前 还前要根据具体的版曾经确认为什么我么我会 设置)

晋升失败:新生代做minor gc的以前 ,前要CMS的担保机制确认老年代否有有足够的空间容纳要晋升的对象,担保机制发现居于问题,则报concurrent mode failure,愿因分析担保机制判断是够的,而是实际上愿因分析碎片问题报告 愿因分析无法分配,就会报晋升失败。

-Xmx4096M-Xms4096M-Xmn1536M

CMS的过程?

增多回收守护程序运行运行的个数 CMS默认的垃圾采集守护程序运行运行数是(CPU个数 + 3)/4,某些公式的含义是:当CPU个数大于一一兩个多多的以前 ,垃圾回收后台守护程序运行运行合适 占用25%的CPU资源。举个例子:愿因分析CPU核数是1~一一兩个多多,如此会有一一兩个多多CPU用于垃圾采集,愿因分析CPU核数是5~8个,如此久会有一一兩个多多CPU用于垃圾采集。

-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses

2. 并发标记:由上一一兩个多多阶段标记过的对象,现在开始了了英文tracing过程,标记所有可达的对象,某些阶段垃圾回收守护程序运行运行和应用守护程序运行运行同時 运行,如上图中的黄色的点。在并发标记过程中,应用守护程序运行运行还在跑,而是会愿因分析某些对象会从新生代晋升到老年代、某些老年代的对象引用会被改变、某些对象会直接分配到老年代,那先 受到影响的老年代对象所在的card会被标记为dirty,用于重新标记阶段扫描。某些阶段过程中,老年代对象的card被标记为dirty的愿因分析愿因分析,而是下图中绿色的线:

CMS采集器对老年代采集的以前 ,不再进行任何压缩和采集的工作,愿因分析老年代随着应用的运行会变得碎片化;碎片太满会影响大对象的分配,并不一定老年代还有很大的剩余空间,而是如此连续的空间来分配大对象,这以前 就会触发Full GC。CMS提供了一一兩个多多参数来解决某些问题报告 :(1)UseCMSCompactAtFullCollection,在要进行Full GC的以前 进行内存碎片采集;(2)CMSFullGCsBeforeCompaction,每隔有几个次不压缩的Full GC后,执行一次带压缩的Full GC。

上端描述的是CMS的并发周期正常完成的情况,而是还有几种CMS并发周期失败的情况:

-XX:+UseConcMarkSweepGC

想最好的土最好的办法增大老年代的空间,增加整个堆的大小,愿因分析减少年轻代的大小

优势

CMS的GC Roots包括那先 对象?

《Java性能权威指南》

7. 并发重置:CMS内控 重置回收器情况,准备进入下一一兩个多多并发回收周期。

劣势

以更高的频率执行后台的回收守护程序运行运行,即提高CMS并发周期居于的频率。设置UseCMSInitiatingOccupancyOnly和CMSInitiatingOccupancyFraction参数,调低CMSInitiatingOccupancyFraction的值,而是而是能调得太低,太低了会愿因分析太满的无效的并发周期,会愿因分析消耗CPU时间和更多的无效的停顿。通常来讲,某些过程前要有几个迭代,而是还是有一定的套路,参见《Java性能权威指南》中给出的建议,摘抄如下:

Eden的使用空间大于“CMSScheduleRemarkEdenSizeThreshold”,某些参数的默认值是2M;

Oracle的GC调优手册

CMS一直再次出现的初衷、背景和目的?

为那先 ParNew都都里能 和CMS配合使用,而Parallel Scanvenge不到否?

愿因分析不满足上端一一兩个多多条件,则进入可中断的预清理,可中断预清理愿因分析会执行多次,如此退出某些阶段的出口有一一兩个多多(源码参见下图):

-XX:CMSInitiatingOccupancyFraction=70

CMS的适用场景?

1. 针对停顿时间过长的调优 首先前要判断是哪个阶段的停顿愿因分析的,而是再针对具体的愿因分析进行调优。使用CMS采集器的JVM愿因分析引发停顿的情况有:(1)Minor gc的停顿;(2)并发周期里初始标记的停顿;(3)并发周期里重新标记的停顿;(4)Serial-Old采集老年代的停顿;(5)Full GC的停顿。其中并发模式失败会愿因分析第(4)种情况,晋升失败和永久代空间耗尽会愿因分析第(5)种情况。

针对永久代的调优 愿因分析永久代前要垃圾回收(或元空间扩容),就会触发Full GC。默认情况下,CMS不不解决永久代中的垃圾,都都里能 通过开启CMSPermGenSweepingEnabled配置来开启永久代中的垃圾回收,开启否有有一组后台守护程序运行运行针对永久代做采集,前要注意的是,触发永久代进行垃圾采集的指标跟触发老年代进行垃圾采集的指标是独立的,老年代的阈值都都里能 通过CMSInitiatingPermOccupancyFraction参数设置,某些参数的默认值是150%。开启对永久代的垃圾采集而是其中的一步,还前要开启曾经参数——CMSClassUnloadingEnabled,使得在垃圾采集的以前 都都里能 卸载不不的类。

CMS的并发采集周期会扫描那先 对象?会回收那先 对象? 答:CMS的并发周期只会回收老年代的对象,而是在标记老年代的存活对象时,愿因分析某些对象会被年轻代的对象引用,而是前要扫描整个堆的对象。

ParNew和PSYoungGen和DefNew是一一兩个多多东西么?

CMS的gc roots包括那先 对象? 答:首先,在JVM垃圾采集中Gc Roots的概念怎么都里能理解(参见R大对GC roots的概念的解释);第二,CMS的并发采集周期中,怎么都里能判断老年代的对象是活着?朋友前面提到了,在CMS的并发周期中,仅仅扫描Gc Roots直达的对象会有遗漏,还前要扫描新生代的对象。如下图中的暗蓝色字体所示,CMS中的年轻代和老年代是分别采集的,而是在判断年轻代的对象存活的以前 ,前要把老年代当作当事人的GcRoots,这以前 并不一定前要扫描老年代的删剪对象,而是使用了card table数据价值形式,愿因分析一一兩个多多老年代对象引用了年轻代的对象,则card中的值会被设置为特殊的数值;反过来判断老年代对象存活的以前 ,也前要把年轻代当作当事人的Gc Roots,某些过程朋友在第三节愿因分析论述过了。

愿因分析是愿因分析某些愿因分析退出,gc日志打印如下:

CMS会回收哪个区域的对象?

-Xloggc:/home/admin/logs/xelephant/gc.log

CMS的推荐参数设置?

3. 预清理:预清理,也是用于标记老年代存活的对象,目的是为了让重新标记阶段的STW尽愿因分析短。某些阶段的目标是在并发标记阶段被应用守护程序运行运行影响到的老年代对象,包括:(1)老年代中card为dirty的对象;(2)幸存区(from和to)中引用的老年代对象。而是,某些阶段也前要扫描新生代+老年代。【PS:会不不扫描Eden区的对象,我看源代码猜测是如此,还前要继续求证】

CMS扫描那先 对象?

《深入理解Java虚拟机》

永久代空间(或Java8的元空间)耗尽,默认情况下,CMS不不对永久代进行采集,一旦永久代空间耗尽,就回触发Full GC。

动态检查机制:JVM会根据最近的回收历史,估算下一次老年代被耗尽的时间,快到某些时间的以前 就启动一一兩个多多并发周期。设置UseCMSInitiatingOccupancyOnly某些参数都都里能 将某些价值形式关闭。

R大对GC roots的概念的解释

Frequently Asked Questions about Garbage Collection in the Hotspot Java VirtualMachine

阈值检查机制:老年代的使用空间达到某个阈值,JVM的默认值是92%(jdk1.5以前 是68%,jdk1.6以前 是92%),愿因分析都都里能 通过CMSInitiatingOccupancyFraction和UseCMSInitiatingOccupancyOnly一一兩个多多参数来设置;某些参数的设置前要看应用场景,设置得太小,会愿因分析CMS频繁居于,设置得太满,会愿因分析太满的并发模式失败。这类

CMS中minor gc和major gc是顺序居于的吗? 答:否有的,都都里能 交叉居于,即在并发周期执行过程中,是都都里能 居于Minor gc的,某些找个gc日志就都都里能 观察到。

Java SE HotSpot at a Glance

低延迟的采集器:几乎如此长时间的停顿,应用守护程序运行运行只在Minor gc以及后台守护程序运行运行扫描老年代的以前 居于极其短暂的停顿。

并发模式失败(Concurrent mode failure):CMS的目标而是在回收老年代对象的以前 并不一定停止删剪应用守护程序运行运行,在并发周期执行期间,用户的守护程序运行运行依然在运行,愿因分析这以前 愿因分析应用守护程序运行运行向老年代请求分配的空间超过预留的空间(担保失败),就回触发concurrent mode failure,而是CMS的并发周期就会被一次Full GC代替——停止删剪应用进行垃圾采集,并进行空间压缩。愿因分析朋友设置了UseCMSInitiatingOccupancyOnly和CMSInitiatingOccupancyFraction参数,其中CMSInitiatingOccupancyFraction的值是70,那预留空间而是老年代的150%。

更高的CPU使用:前要有足够的CPU资源用于运行后台的垃圾采集守护程序运行运行,在应用守护程序运行运行守护程序运行运行运行的同時 扫描堆的使用情况。【PS:现在服务器的CPU资源基本否有问题报告 ,某些点都都里能 忽略】

带着问题报告 去学习一一兩个多多东西,才会有目标感,我先把一直以来当事人对CMS的某些疑惑罗列了下,希望这篇学习笔记能解决掉那先 疑惑,希望不不 对你有所帮助。

设置了CMSMaxAbortablePrecleanLoops,而是执行的次数超过了某些值,某些参数的默认值是0;

图解CMS垃圾回收机制,你值得拥有

理解CMS垃圾回收日志

从实际案例聊聊Java应用的GC优化

为那先 CMS并不一定是老年代的gc,但仍要扫描新生代的?

-XX:+CMSScavengeBeforeRemark

CMS的调优怎么都里能做?

在预清理步骤后,愿因分析满足下面一一兩个多多条件,就不不开启可中断的预清理,直接进入重新标记阶段:

CMS的并发采集周期合适 触发? 由下图都都里能 看出,CMS 并发周期触发的条件有一一兩个多多:

Eden的使用率大于等于“CMSScheduleRemarkEdenPenetration”,某些参数的默认值是150%。

-XX:+ParallelRefProcEnabled

详解CMS垃圾回收机制

CMSMaxAbortablePrecleanTime,执行可中断预清理的时间超过了某些值,某些参数的默认值是11500毫秒。

有愿因分析可中断预清理过程中一直没等到Minor gc,这以前 进入重新标记阶段语录,新生代还有而是活着的对象,就回愿因分析STW变长,而是CMS还提供了CMSScavengeBeforeRemark参数,都都里能 在进入重新标记以前 强制进行依次Minor gc。

对特定的应用守护程序运行运行,该标志的更优值都都里能 根据 GC 日志中 CMS 周期首次启动失败时的值得到。具体最好的土最好的办法是,在垃圾回收日志中寻找并发模式失效,找到后再反向查找 CMS 周期最近的启动记录,而是根据日志来计算这以前 的老年代空间占用值,而是设置一一兩个多多比该值更小的值。

5.(STW)重新标记:重新扫描堆中的对象,进行可达性分析,标记活着的对象。某些阶段扫描的目标是:新生代的对象 + Gc Roots + 前面被标记为dirty的card对应的老年代对象。愿因分析预清理的工作没做好,某些步扫描新生代的以前 就会花而是时间,愿因分析某些阶段的停顿时间过长。某些过程是多守护程序运行运行的。

-XX:+UseCMSInitiatingOccupancyOnly

为那先 ParNew都都里能 和CMS配合使用,而Parallel Scanvenge不到否? 答:某些跟Hotspot VM的历史有关,Parallel Scanvenge是不在 “分代框架”下开发的,而ParNew、CMS否有在分代框架下开发的。

CMS的适用场景:愿因分析你的应用前要更慢的响应,不希望有长时间的停顿,同時 你的CPU资源也比较充沛,就适合适 用CMS采集器。

这里朋友首先看下CMS并发采集周期正常完成的有几个情况。

-XX:+PrintGCDetails

CMS的trade-off是那先 ?优势、劣势和代价

4. 可中断的预清理:某些阶段的目标跟“预清理”阶段相同,也是为了减轻重新标记阶段的工作量。可中断预清理的价值:在进入重新标记阶段以前 尽量等到一一兩个多多Minor GC,尽量缩短重新标记阶段的停顿时间。另外可中断预清理会在Eden达到150%的以前 现在开始了了英文,这以前 离下一次minor gc还有半程的时间,某些还有曾经意义,即解决短时间内连着的一一兩个多多停顿,如下图资料所示:

CMS的日志怎么都里能分析?

CMS哪天触发?

1.(STW)初始标记:某些阶段是标记从GcRoots直接可达的老年代对象、新生代引用的老年代对象,而是下图中灰色的点。某些过程是单守护程序运行运行的。

-XX:+HeapDumpOnOutOfMemoryError

-XX:+PrintGCDateStamps

CMS的初衷和目的:为了消除Throught采集器和Serial采集器在Full GC周期中的长时间停顿。

-XX:HeapDumpPath=/home/admin/logs/xelephant

2. 针对并发模式失败的调优

CMS和CMS collector的区别?

-XX:MaxMetaspaceSize=512M-XX:MetaspaceSize=512M

会一直再次出现浮动垃圾;在并发清理阶段,用户守护程序运行运行仍然在运行,前要预留出空间给用户守护程序运行运行使用,而是CMS比某些回收器前要更大的堆空间。

CMS采集器:Mostly-Concurrent采集器,也称并发标记清除采集器(Concurrent Mark-Sweep GC,CMS采集器),它管理新生代的最好的土最好的办法与Parallel采集器和Serial采集器相同,而在老年代则是尽愿因分析得并发执行,每个垃圾采集器周期不到2次短停顿。