采用CMS时候,新生代必须使用Serial GC或者ParNew GC两种。CMS共有七个步骤,只有Initial Marking和Final Marking两个阶段是stop-the-world的,其他步骤均和应用并行进行。持久代的GC也采用CMS,通过-XX:CMSPermGenSweepingEnabled -XX:CMSClassUnloadingEnabled来制定。在采用cms gc的情况下,ygc变慢的原因通常是由于old gen出现了大量的碎片。
为啥CMS会有内存碎片,如何避免?
由于在CMS的回收步骤中,没有对内存进行压缩,所以会有内存碎片出现,CMS提供了一个整理碎片的功能,通过-XX:UseCompactAtFullCollection来启动此功能,启动这个功能后,默认每次执行Full GC的时候会进行整理(也可以通过-XX:CMSFullGCsBeforeCompaction=n来制定多少次Full GC之后来执行整理),整理碎片会stop-the-world.
啥时候会触发CMS GC?
1、旧生代或者持久代已经使用的空间达到设定的百分比时(CMSInitiatingOccupancyFraction这个设置old区,perm区也可以设置);
2、JVM自动触发(JVM的动态策略,也就是悲观策略)(基于之前GC的频率以及旧生代的增长趋势来评估决定什么时候开始执行),如果不希望JVM自行决定,可以通过-XX:UseCMSInitiatingOccupancyOnly=true来制定;
3、设置了 -XX:CMSClassUnloadingE考虑nabled 这个则考虑Perm区;
啥时候会触发Full GC?
一、旧生代空间不足:java.lang.outOfMemoryError:java heap space;
二、Perm空间满:java.lang.outOfMemoryError:PermGen space;
三、CMS GC时出现promotion failed 和concurrent mode failure(Concurrent mode failure发生的原因一般是CMS正在进行,但是由于old区内存不足,需要尽快回收old区里面的死的java对象,这个时候foreground gc需要被触发,停止所有的java线程,同时终止CMS,直接进行MSC。);
四、统计得到的minor GC晋升到旧生代的平均大小大于旧生代的剩余空间;
五、主动触发Full GC(执行jmap -histo:live [pid])来避免碎片问题;
为啥heap小于3g不建议使用CMS GC这种方式?
http://hellojava.info/?p=142 毕大师的这篇文章讲的很清楚。
1、触发比例不好设置,设置大了,那么剩余的空间就少了很多,设置小了,那old区还没放置多少东西,就要进行回收了;
2、CMS进行的时候,是并行的,也就意味着如果过于频繁的话,会和应用的强占CPU;
3、CMS会有内存 碎片问题;
4、YGC的速率变慢(由于CMS GC的实现原理,导致对象从新生代晋升到旧生代时,寻找哪里能放下的这个步骤比ParallelOld GC是慢一些的,因此就导致了YGC速度会有一定程度的下降。);
JVM的悲观策略是啥?
所谓的悲观策略( http://tmalltesting.com/archives/663 我们性能测试团队一个同学分析的案例),就是JVM不按照JVM指定的参数来进行CMS GC,而是根据内存情况以及之前回收的方式动态调整,自行进行GC。旧生代剩余的空间(available)大于新生代中使用的空间(max_promotion_in_bytes),或者大于之前平均晋升的old的大小(av_promo),返回false。cms gc是每隔一个周期(默认2s)就会做一次这个检查,如果为false,则不执行YGC,而触发cms gc。
我们经常使用的是啥GC方式?
针对目前线上机器的情况(8G的物流内存),heap区一般设置在4g或者5g左右,一般是使用CMS GC,这时候:
young区使用ParNew(并行GC),Old+Perm(需要单独设置)使用CMS,整个堆(young+old+perm)使用MSC((Mark Sweep Compact)是CMS GC算法的Full GC算法,单线程回收整个堆,回收过程有严格的步骤。压缩,所以回收完理论上任何Generation都不会有内存碎片)压缩回收的方式。
读懂GC日志?
基本上都是这种格式:回收前区域占用的大小->回收后区域占用的大小(区域设置的大小),占用的时间
1、promotion failed的一段日志
1
2
|
2013
-
11
-27T03:
00
:
53.638
+
0800
:
35333.562
: [GC
35333.562
: [ParNew (promotion failed): 1877376K->1877376K(1877376K),
15.7989680
secs]
35349.361
: [CMS: 2144171K->2129287K(2146304K),
10.4200280
sec
s] 3514052K->2129287K(4023680K), [CMS Perm : 119979K->118652K(190132K)],
26.2193500
secs] [Times: user=
30.35
sys=
5.19
, real=
26.22
secs]
|
解释如下:
1
2
3
4
5
|
1877376K->1877376K(1877376K),
15.7989680
secs young区
2144171K->2129287K(2146304K),
10.4200280
sec old区情况
3514052K->2129287K(4023680K) heap区情况
119979K->118652K(190132K)],
26.2193500
secs perm区情况
[Times: user=
30.35
sys=
5.19
, real=
26.22
secs] 整个过程的时间消耗
|
2、一段正常的CMS的日志
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
2013
-
11
-27T04:
00
:
12.819
+
0800
:
38892.743
: [GC [
1
CMS-initial-mark: 1547313K(2146304K)] 1734957K(4023680K),
0.1390860
secs] [Times: user=
0.14
sys=
0.00
, real=
0.14
secs]
2013
-
11
-27T04:
00
:
12.958
+
0800
:
38892.883
: [CMS-concurrent-mark-start]
2013
-
11
-27T04:
00
:
19.231
+
0800
:
38899.155
: [CMS-concurrent-mark:
6.255
/
6.272
secs] [Times: user=
8.49
sys=
1.57
, real=
6.27
secs]
2013
-
11
-27T04:
00
:
19.231
+
0800
:
38899.155
: [CMS-concurrent-preclean-start]
2013
-
11
-27T04:
00
:
19.250
+
0800
:
38899.175
: [CMS-concurrent-preclean:
0.018
/
0.019
secs] [Times: user=
0.02
sys=
0.00
, real=
0.02
secs]
2013
-
11
-27T04:
00
:
19.250
+
0800
:
38899.175
: [CMS-concurrent-abortable-preclean-start]
CMS: abort preclean due to time
2013
-
11
-27T04:
00
:
25.252
+
0800
:
38905.176
: [CMS-concurrent-abortable-preclean:
5.993
/
6.002
secs] [Times: user=
6.97
sys=
2.16
, real=
6.00
secs]
2013
-
11
-27T04:
00
:
25.253
+
0800
:
38905.177
: [GC[YG occupancy:
573705
K (
1877376
K)]
38905.177
: [Rescan (parallel) ,
0.3685690
secs]
38905.546
: [weak refs processing,
0.0024100
secs]
38905.548
: [cla
ss unloading,
0.0177600
secs]
38905.566
: [scrub symbol & string tables,
0.0154090
secs] [
1
CMS-remark: 1547313K(2146304K)] 2121018K(4023680K),
0.4229380
secs] [Times: user=
1.41
sys=
0.01
, real=
0.43
secs]
2013
-
11
-27T04:
00
:
25.676
+
0800
:
38905.601
: [CMS-concurrent-sweep-start]
2013
-
11
-27T04:
00
:
26.436
+
0800
:
38906.360
: [CMS-concurrent-sweep:
0.759
/
0.760
secs] [Times: user=
1.06
sys=
0.48
, real=
0.76
secs]
2013
-
11
-27T04:
00
:
26.436
+
0800
:
38906.360
: [CMS-concurrent-reset-start]
2013
-
11
-27T04:
00
:
26.441
+
0800
:
38906.365
: [CMS-concurrent-reset:
0.005
/
0.005
secs] [Times: user=
0.00
sys=
0.00
, real=
0.00
secs]
|
这个是一个正常的CMS的日志,共分为七个步骤,重点关注initial-mark和remark这两个阶段,因为这两个是停机的。
A、[GC [1 CMS-initial-mark: 1547313K(2146304K)] 1734957K(4023680K), 0.1390860 secs] [Times: user=0.14 sys=0.00, real=0.14 secs]
各个数据依次表示标记前后old区的所有对象占内存大小和old的capacity,整个JavaHeap(不包括perm)所有对象占内存总的大小和JavaHeap的capacity。
B、2013-11-27T04:00:25.253+0800: 38905.177: [GC[YG occupancy: 573705 K (1877376 K)]38905.177: [Rescan (parallel) , 0.3685690 secs]38905.546: [weak refs processing, 0.0024100 secs]38905.548: [class unloading, 0.0177600 secs]38905.566: [scrub symbol & string tables, 0.0154090 secs] [1 CMS-remark: 1547313K(2146304K)] 2121018K(4023680K), 0.4229380 secs] [Times: user=1.41 sys=0.01, real=0.43 secs]
Rescan (parallel)表示的是多线程处理young区和多线程扫描old+perm的卡表的总时间, parallel 表示多GC线程并行。
weak refs processing 处理old区的弱引用的总时间,用于回收native memory。
class unloading 回收SystemDictionary消耗的总时间。
3、一段正常的Young GC的日志
1
2
|
2013
-
11
-27T04:
00
:
07.345
+
0800
:
38887.270
: [GC
38887.270
: [ParNew: 1791076K->170624K(1877376K),
0.2324440
secs] 2988366K->1413629K(4023680K),
0.2326470
secs] [Times: user=
0.80
sys=
0.00
, real=
0
.
23
secs]
|
ParNew这个表明是并行的回收方式,具体的分别是young区、整个heap区的情况;
4、一段通过system.gc产生的FullGC日志
1 | 2013 - 07 -21T17: 44 : 01.554 + 0800 : 50.568 : [Full GC (System) 50.568 : [CMS: 943772K->220K(2596864K), 2.3424070 secs] 1477000K->220K(4061184K), [CMS Perm : 3361K->3361K(98304K)], 2.3425410 secs] [Times: user= 2.33 sys= 0.01 , real= 2.34 secs] |
解释如下:
Full GC (System)意味着这是个system.gc调用产生的MSC。
“943772K->220K(2596864K), 2.3424070 secs”表示:这次MSC前后old区内总对象大小,old的capacity及这次MSC耗时。
“1477000K->220K(4061184K)”表示:这次MSC前后JavaHeap内总对象大小,JavaHeap的capacity。
“3361K->3361K(98304K)], 2.3425410 secs”表示:这次MSC前后Perm区内总对象大小,Perm区的capacity。
5、一个特殊的GC日志,根据动态计算直接进行的FullGC(MSC的方式)
1 | 2013 - 03 -13T13: 48 : 06.349 + 0800 : 7.092 : [GC 7.092 : [ParNew: 471872K->471872K(471872K), 0.0000420 secs] 7.092 : [CMS: 366666K->524287K(524288K), 27.0023450 secs] 838538K->829914K(996160K), [CMS Perm : 3196K->3195K(131072K)], 27.0025170 secs] |
ParNew的时间特别短,jvm在minor gc前会首先确认old是不是足够大,如果不够大,这次young gc直接返回,进行MSC。