CMS常见错误

** 碎片参数 **

-XX:OldPLABSize=16
-XX:-ResizeOldPLAB
-XX:+PrintGCDetails
-XX:+PrintPromotionFailure
-XX:PrintFLSStatistics=1

** Concurrent mode failure **

1. 设置-XX:CMSInitiatingOccupancyFraction
2. 增大old区的大小

At beginning  of each young GC, collector should ensure that there is enough free
 memory in old space to promote aged objects from young space. Modern CMS 
collector estimates size of objects to be promoted using statistics from previous
 collections. If old space does not have enough free bytes to hold estimated 
promotion amount, **concurrent mode failure** will be raise. Concurrent mode
 failure doesn't necessary lead to Full GC, in certain cases JVM will just wait for
 concurrent collection cycle to finish, but application will remain in STW pause 
until young collection will be finished.


Most frequent reason for concurrent mode failure is late initiation of CMS cycle. 
JVM tries to estimate amount of garbage in heap and duration of CMS cycle and
 start it as late as possible to avoid wasting of CPU. Unfortunately this estimation
 may be too optimistic. You can advise JVM to start CMS earlier using following
 flags:

-XX:CMSInitiatingOccupancyFraction=30-XX:+UseCMSInitiatingOccupancyOnly


Setting above will force CMS cycle is more than 30% of old space is use. Second 
option disables JVM heuristics, without second parameter JVM may not obey 
CMS initiating occupancy fraction setting.


Normally for server type applications you would like CMS to be running 
continuously. If you are experiencing **concurrent mode failure**, even though 
next CMS cycle is starting right after previous, it means that CMS throughput is 
just not enough. In this case you should increase size of old generation and give 
CMS collector more head room to do its job. Alternatively you may try to dedicate 
more CPU cores for concurrent collector, but CPU is usually even more limited 
resource on modern servers than memory.


In summary, there are two reasons for **concurrent mode failure**STW pause 
mentioned above, both of them can be remedied fairly easily with JVM options.

** Promotion failure **

Promotion failure is more complicated situation. CMS collector is not compacting 
free memory in old space, instead it have to deal with fragmented free space (a 
set of free memory chunks). It is possible, that all free bytes are scattered though 
small chunks, and it is impossible to find certain amount of continuous memory to 
promote particular large object, even though total number of free bytes is large
 enough.

Heap fragmentation is well known problem, and there are few effective techniques 
reducing fragmentation.

CMS memory manager is using separate free lists for different size of chunks. 
Using these free lists, it can effectively fill small holes in fragmented memory 
space with objects of exact size. This technique is known to be fairly effective 
(and widely used in C/C++ memory managers). But, surprisingly, it doesn't seems
 to work well for JVM in many real live situations.