JVM 参数设置
JVM 参数设置
参考文献：http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html
某个大流量网站中JVM参数设置如下：
-Xms10000M -Xmx10000M -Xmn5000M -Xss128k -XX:PermSize=256m -XX:MaxPermSize=512m -XX:+UseParNewGC -XX:ParallelGCThreads=8 默认开启回收线程数（并行GC线程数+3）/4 -XX:SurvivorRatio=6 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=30 控制对象在新生代存活的最大次数 -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection 下面两个参数，由于CMS会产生垃圾浮点，所以每执行5次full GC -XX:CMSFullGCsBeforeCompaction=5 内存就进行整理 -XX:CMSInitiatingOccupancyFraction=55 旧生代使用55%的比例触发full GC -XX:SoftRefLRUPolicyMSPerMB=0 -XX:CMSIncrementalSafetyFactor=20 ？？？？？？？？？？？？？？ -XX:+CMSIncrementalMode ？？？？？？？？？？？？？ -XX:+UseCMSInitiatingOccupancyOnly 禁止hotspot自行触发CMS GC -XX:+PrintGCDetails -XX:+PrintGCTimeStamp
考虑的是持久代的GC也可以设置：-XX:+CMSPermGenSweepingEnabled,-XX:+CMSClassUnloadingEnabled
额外参数需要考虑的：
-XX:+DisableExplicitGC禁止System.gc()
-XX:SoftRefLRUPolicyMSPerMB
softly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap，我觉得没必要等1秒；
如果在CMS算法中配置了: -XX:+UseAdaptiveSizePolicy 表示堆中各个区的比例由JVM自己分配即动态变化
-XX:+DisableExplicitGC禁止System.gc()
CMS算法
优点：
- 在Old进行回收时，对应用的暂停时间非常短，适合对latency要求高的应用
缺点：
- 内存碎片和浮动垃圾
- Old区内存分配效率低
- 回收的整个耗时比较长
- 和应用争取CPU
二、内存回收触发机制
1、YGC eden空间不足
2、CMS GC
- Old区域使用达到一定的比例，默认是92%
- 配置了CMSClassunloadingEnabled，且Perm 区域使用达到一定比例，默认92%
- hotspot自己根据估计决定是否要触发
- 在配置ExplicitGCInvokesConcurrent的情况下调用了System.gc
Full GC如果出现了Promotion failed 或Concurrent Mode Failure 时，GC采用 serial MSC
promotion failed，(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn
三、对于CMS算法中增量模式的解释
-XX:+CMSIncrementalMode
请看原文的意思：
The concurrent collector can be used in a mode in which the concurrent phases are done
incrementally. Recall that during a concurrent phase the garbage collector thread is using a processor.
The incremental mode is meant to lessen the impact of long concurrent phases by periodically stopping
the concurrent phase to yield back the processor to the application. This mode
(referred to here as “i-cms”) divides the work done by concurrently by the collector into small chunks
of time which are scheduled between young generation collections. This feature is useful when
applications that need the low pause times provided by the concurrent collector are run on machines
with small numbers of processors (e.g., 1 or 2).
The concurrent collection cycle typically includes the following steps:
stop all application threads; do the initial mark; resume all application threads
do the concurrent mark (uses one procesor for the concurrent work)
do the concurrent pre-clean (uses one processor for the concurrent work)
stop all application threads; do the remark; resume all application threads
do the concurrent sweep (uses one processor for the concurrent work)
do the concurrent reset (uses one processor for the concurrent work)
Normally, the concurrent collector uses one processor for the concurrent work for the entire
concurrent mark phase, without (voluntarily) relinquishing it. Similarly, one processor is used for the
entire concurrent sweep phase, again without relinquishing it. This processor utilization can be too
much of a disruption for applications with pause time constraints, particularly when run on systems
with just one or two processors. i-cms solves this problem by breaking up the concurrent phases into
short bursts of activity, which are scheduled to occur mid-way between minor pauses.
I-cms uses a "duty cycle" to control the amount of work the concurrent collector is allowed to do
before voluntarily giving up the processor. The duty cycle is the percentage of time between young
generation collections that the concurrent collector is allowed to run. I-cms can automatically compute
the duty cycle based on the behavior of the application (the recommended method), or the duty cycle
can be set to a fixed value on the command line.
The following command-line options control i-cms (see below for recommendations for an initial set of options): -XX:+CMSIncrementalMode default: disabled This flag enables the incremental mode. Note that the concurrent collector must be enabled (with -XX:+UseConcMarkSweepGC) for this option to work. -XX:+CMSIncrementalPacing default: disabled This flag enables automatic adjustment of the incremental mode duty cycle based on statistics collected while the JVM is running. -XX:CMSIncrementalDutyCycle=<N> default: 50 This is the percentage (0-100) of time between minor collections that the concurrent collector is allowed to run. If CMSIncrementalPacing is enabled, then this is just the initial value. -XX:CMSIncrementalDutyCycleMin=<N> default: 10 This is the percentage (0-100) which is the lower bound on the duty cycle when CMSIncrementalPacing is enabled. -XX:CMSIncrementalSafetyFactor=<N> default: 10 This is the percentage (0-100) used to add conservatism when computing the duty cycle. -XX:CMSIncrementalOffset=<N> default: 0 This is the percentage (0-100) by which the incremental mode duty cycle is shifted to the right within the period between minor collections. -XX:CMSExpAvgFactor=<N> default: 25 This is the percentage (0-100) used to weight the current sample when computing exponential averages for the concurrent collection statistics. 5.4.9.2 Recommended Options for i-cms When trying i-cms, we recommend the following as an initial set of command line options: -XX:+UseConcMarkSweepGC \ -XX:+CMSIncrementalMode \ -XX:+CMSIncrementalPacing \ -XX:CMSIncrementalDutyCycleMin=0 \ -XX:+CMSIncrementalDutyCycle=10 \ -XX:+PrintGCDetails \ -XX:+PrintGCTimeStamps \ -XX:-TraceClassUnloading
所以要慎重的使用该参数，不要使用JVM自己收集JVM信息去触发GC，自己使用过该参数，深有体会，full gc不可控。