GC 参数设置【转帖】

基本参数设置
-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails


高级参数设置
1.启用CMS：-XX:+UseConcMarkSweepGC

2.CMS默认启动的回收线程数目是 (ParallelGCThreads + 3)/4) ，如果你需要明确
设定，可以通过-XX:ParallelCMSThreads=20来设定,其中ParallelGCThreads是年
轻代的并行收集线程数

3.、CMS是不会整理堆碎片的，因此为了防止堆碎片引起full gc，通过会开启CMS
阶段进行合并碎片选项：-XX:+UseCMSCompactAtFullCollection，开启这个选
项一定程度上会影响性能，可以通过配置适当的CMSFullGCsBeforeCompaction来调整性能

4.为了避免Perm区满引起的full gc，建议开启CMS回收Perm区选项：
+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

6.默认CMS是在tenured generation沾满68%的时候开始进行CMS收集，如果你的年
老代增长不是那么快，并且希望降低CMS次数的话，可以适当调高此值：
-XX:CMSInitiatingOccupancyFraction=80
这里修改成80%占满的时候才开始CMS回收。

7.年轻代的并行收集线程数默认是(cpu <= 8 ) ? cpu : 3 + ((cpu * 5) / 8 )，如果你希望降低这个线程数，可以通过-XX:ParallelGCThreads= N 来调整。

例子1：
-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:MaxTenuringThreshold=20 -Xloggc:log/gc.log

例子2：
-server -Xms1536m -Xmx1536m -XX:NewSize=256m -
XX:MaxNewSize=256m -XX:PermSize=64m
-XX:MaxPermSize=64m -XX:-UseConcMarkSweepGC -
XX:+UseCMSCompactAtFullCollection
-XX:CMSInitiatingOccupancyFraction=80 -XX:+CMSParallelRemarkEnabled
-XX:SoftRefLRUPolicyMSPerMB=0


CMS，全称Concurrent Low Pause Collector，是jdk1.4后期版本开始引入的新gc
算法，在jdk5和jdk6中得到了进一步改进，它的主要适合场景是对响应时间的重
要性需求大于对吞吐量的要求，能够承受垃圾回收线程和应用线程共享处理器资
源，并且应用中存在比较多的长生命周期的对象的应用。CMS是用于对tenured
generation的回收，也就是年老代的回收，目标是尽量减少应用的暂停时间，减少
full gc发生的几率，利用和应用程序线程并发的垃圾回收线程来标记清除年老
代。在我们的应用中，因为有缓存的存在，并且对于响应时间也有比较高的要
求，因此希望能尝试使用CMS来替代默认的server型JVM使用的并行收集器，以
便获得更短的垃圾回收的暂停时间，提高程序的响应性。
CMS并非没有暂停，而是用两次短暂停来替代串行标记整理算法的长暂停，它
的收集周期是这样：
初始标记(CMS-initial-mark) -> 并发标记(CMS-concurrent-mark) -> 重新标记
(CMS-remark) -> 并发清除(CMS-concurrent-sweep) ->并发重设状态等待下次
CMS的触发(CMS-concurrent-reset)。
其中的1，3两个步骤需要暂停所有的应用程序线程的。第一次暂停从root对象
开始标记存活的对象，这个阶段称为初始标记；第二次暂停是在并发标记之后，
暂停所有应用程序线程，重新标记并发标记阶段遗漏的对象（在并发标记阶段结
束后对象状态的更新导致）。第一次暂停会比较短，第二次暂停通常会比较长，
并且 remark这个阶段可以并行标记。
而并发标记、并发清除、并发重设阶段的所谓并发，是指一个或者多个垃圾回
收线程和应用程序线程并发地运行，垃圾回收线程不会暂停应用程序的执行，如果你有多于一个处理器，那么并发收集线程将与应用线程在不同的处理器上运
行，显然，这样的开销就是会降低应用的吞吐量。Remark阶段的并行，是指暂停
了所有应用程序后，启动一定数目的垃圾回收进程进行并行标记，此时的应用线
程是暂停的。
CMS的young generation的回收采用的仍然是并行复制收集器，这个跟Paralle gc
算法是一致的。

Java代码
[ParNew (promotion failed): 320138K->320138K(353920K), 0.2365970 secs]
42576.951: [CMS: 1139969K->1120688K(
166784K), 9.2214860 secs] 1458785K->1120688K
(2520704K), 9.4584090 secs]

这个问题的产生是由于救助空间不够，从而向年老代转移对象，年老代没有足够
的空间来容纳这些对象，导致一次full gc的产生。解决这个问题的办法有两种完
全相反的倾向：增大救助空间、增大年老代或者去掉救助空间。增大救助空间就
是调整-XX:SurvivorRatio参数，这个参数是Eden区和Survivor区的大小比值，默认
是32，也就是说Eden区是 Survivor区的32倍大小，要注意Survivo是有两个区的，
因此Surivivor其实占整个young genertation的1/34。调小这个参数将增大survivor
区，让对象尽量在survitor区呆长一点，减少进入年老代的对象。去掉救助空间的
想法是让大部分不能马上回收的数据尽快进入年老代，加快年老代的回收频率，
减少年老代暴涨的可能性，这个是通过将-XX:SurvivorRatio 设置成比较大的值
（比如65536)来做到。在我们的应用中，将young generation设置成256M，这个值
相对来说比较大了，而救助空间设置成默认大小(1/34)，从压测情况来看，没有出
现prommotion failed的现象，年轻代比较大，从GC日志来看，minor gc的时间也在
5-20毫秒内，还可以接受，因此暂不调整。
Concurrent mode failed的产生是由于CMS回收年老代的速度太慢，导致年老代在
CMS完成前就被沾满，引起full gc，避免这个现象的产生就是调小-
XX:CMSInitiatingOccupancyFraction参数的值，让CMS更早更频繁的触发，降
低年老代被沾满的可能。我们的应用暂时负载比较低，在生产环境上年老代的增
长非常缓慢，因此暂时设置此参数为80。在压测环境下，这个参数的表现还可
以，没有出现过Concurrent mode failed。