CMS回收器参数解释

采用1：
-XX:+AggressiveOpts

-XX:MaxDirectMemorySize=2G

-Xmx10G

-Xms10G

-Xmn8G

-XX:+UseConcMarkSweepGC

-XX:CMSInitiatingOccupancyFraction=70 是指设定CMS在对内存占用率达到70%的时候开始GC(因为CMS会有浮动垃圾,所以一般都较早启动GC)

-XX:+UseCMSInitiatingOccupancyOnly 只是用设定的回收阈值(上面指定的70%),如果不指定,JVM仅在第一次使用设定值,后续则自动调整.

-XX:+CMSIncrementalMode 该标志将开启CMS收集器的增量模式。增量模式经常暂停CMS过程，以便对应用程序线程作出完全的让步。因此，收集器将花更长的时间完成整个收集周期。
因此，只有通过测试后发现正常CMS周期对应用程序线程干扰太大时，才应该使用增量模式。由于现代服务器有足够的处理器来适应并发的垃圾收集，所以这种情况发生得很少。

-XX:+UseCMSCompactAtFullCollection

-XX:CMSFullGCsBeforeCompaction=0
CMSFullGCsBeforeCompaction 说的是，在上一次CMS并发GC执行过后，到底还要再执行多少次full GC才会做压缩。默认是0，也就是在默认配置下每次CMS GC顶不住了而要转入full GC的时候都会做压缩。
把CMSFullGCsBeforeCompaction配置为10，就会让上面说的第一个条件变成每隔10次真正的full GC才做一次压缩（而不是每10次CMS并发GC就做一次压缩，目前VM里没有这样的参数）。这会使full GC更少做压缩，也就更容易使CMS的old gen受碎片化问题的困扰。
本来这个参数就是用来配置降低full GC压缩的频率，以期减少某些full GC的暂停时间。CMS回退到full GC时用的算法是mark-sweep-compact，
但compaction是可选的，不做的话碎片化会严重些但这次full GC的暂停时间会短些；这是个取舍。

-XX:MaxTenuringThreshold=10 默认15，该参数主要是控制新生代需要经历多少次GC晋升到老年代中的最大阈值。

-XX:+CMSScavengeBeforeRemark
在CMS GC前启动一次ygc，目的在于减少old gen对ygc gen的引用，降低remark时的开销-----一般CMS的GC耗时 80%都在remark阶段

-XX:ParallelCMSThreads=6 定义并发CMS过程运行时的线程数
关于线程数：
1）-XX:ParallelGCThreads，如果你没有设置该参数，该参数jvm会默认设置成online的cpu的核数。设置收集器的线程数, 默认与 CPU的核数是相同的, 建议设置小于核数, 不建议设大于核数. 当核数大于8个 ParallelGCThreads=3 + (5 * cpu core / 8)

			2）-XX:ParallelCMSThreads，设置 CMS并发收集器的线程数, 默认启动的线程数是(ParallelGCThreads + 3) / 4 = 2; ParallelGCThreads 是新年代 ParNew并行收集器的线程数。不能超过cpu线程数，需要注意的是增加gc线程数，就会和应用争抢资源。
			 
			 保持默认值，不设置。

-XX:+CMSParallelInitialMarkEnabled 开启该阶段的并行标记，使用多个线程进行标记，减少暂停时间。

-XX:+CMSParallelRemarkEnabled 开启并行的Remark，加快remark的速度。

-XX:-UseAdaptiveSizePolicy

可以获取到，CMS Remark 重新标记“Stop The World” 1.9392917 secs。
总计：CMS Initial Mark（0.0139600 secs） + CMS Remark （1.9392917 secs）=1953.2517ms