jvm配置参数（记录）

‐Xms2048M（简写） -XX:InitialHeapSize=100M 初始化堆大小
-XX:CICompilerCount=1 最大并行编译数
‐Xmx2048M -XX:MaxHeapSize=100M 堆的最大值
‐Xmn1024M 年轻代大小 -XX:NewSize=20M 年轻代大小 -XX:MaxNewSize=50M 年轻代最大值
-Xss512K 线程的大小
-Xss设置越小count值越小，说明一个线程栈里能分配的栈帧就越少，但是对JVM整体来说能开启的线程数会更多
‐XX:MetaspaceSize=256M 设置原空间触发Fullgc的初始阈值
‐XX:MaxMetaspaceSize=256M 设置原空间最大值 默认-1 即 不受限制以字节为单位，
默认是21M，达到该值就会触发 full gc进行类型卸载， 同时收集器会对该值进行调整：
如果释放了大量的空间， 就适当降低该值； 如果释放了很少的空间，
那么在不超 过-XX：MaxMetaspaceSize（如果设置了的话） 的情况下， 适当提高该值。
-XX:NewRatio 新老生代的比值 比如-XX:Ratio=4，则表示新生代:老年代=1:4，也就是新生代占整个堆内存的1/5
-XX:SurvivorRatio 两个S区和Eden区的比值 比如-XX:SurvivorRatio=8，也就是(S0+S1):Eden=2:8，也就是一个S占整个新生代的1/10

­XX:+UseCompressedOops 启用指针压缩（默认开启）
­XX:­UseCompressedOops 禁用指针压缩
-XX:+DoEscapeAnalysis 开启逃逸分析（jdk7之后默认开启）
-XX:-DoEscapeAnalysis 关闭逃逸分析
-XX:+EliminateAllocations 开启标量替换（jdk7之后默认开启）
-XX:+UseAdaptiveSizePolicy 开启eden和survivor比值自动变换（默认开启）
-XX:-UseAdaptiveSizePolicy 关闭自动变换
‐XX:+PrintGCDetails 打印gc细节
-XX:PretenureSizeThreshold=1000000 (单位是字节)大对象直接进入老年代的大小
-XX:MaxTenuringThreshold 对象从年轻代进入老年代的阈值

-XX:TargetSurvivorRatio 对象动态年龄判断（默认50%）
当前放对象的Survivor区域里(其中一块区域，放对象的那块s区)，一批对象的总大小大于这块Survivor区域内存大小的
50%(-XX:TargetSurvivorRatio可以指定)，那么此时大于等于这批对象年龄最大值的对象，就可以直接进入老年代了，
例如Survivor区域里现在有一批对象，年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区域的50%，此时就会
把年龄n(含)以上的对象都放入老年代。这个规则其实是希望那些可能是长期存活的对象，尽早进入老年代。
对象动态年 龄判断机制一般是在minor gc之后触发的。

-XX:-HandlePromotionFailure 老年代空间分配担保机制
年轻代每次minor gc之前JVM都会计算下老年代剩余可用空间
如果这个可用空间小于年轻代里现有的所有对象大小之和(包括垃圾对象)
就会看一个“-XX:-HandlePromotionFailure”(jdk1.8默认就设置了)的参数是否设置了
如果有这个参数，就会看看老年代的可用内存大小，是否大于之前每一次minor gc后进入老年代的对象的平均大小。
如果上一步结果是小于或者之前说的参数没有设置，那么就会触发一次Full gc，对老年代和年轻代一起回收一次垃圾，
如果回收完还是没有足够空间存放新的对象就会发生"OOM"
当然，如果minor gc之后剩余存活的需要挪动到老年代的对象大小还是大于老年代可用空间，
那么也会触发full gc，full gc完之后如果还是没有空间放minor gc之后的存活对象，则也会发生“OOM”

-XX:+UseSerialGC Serial收集器（单线程收集器）
-XX:+UseSerialOldGC
-XX:+UseParallelGC(年轻代) Parallel Scavenge收集器（Serial的多线程版本）
-XX:+UseParallelOldGC(老年代)
-XX:+UseParNewGC ParNew收集器（和Parallel类似，但是可以和CMS收集器配合使用）
-XX:+UseConcMarkSweepGC(old) CMS收集器
-XX:+UseCMSCompactAtFullCollection CMS收集器的标记清除算法会导致收集结束时有大量空间碎片产生
通过这个参数进行整理
CMS相关参数

1. -XX:+UseConcMarkSweepGC：启用cms
2. -XX:ConcGCThreads：并发的GC线程数
3. -XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）
4. -XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一 次
5. -XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）
6. -XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设 定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整
7. -XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引 用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时 80%都在标记阶段
8. -XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW
9. -XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;
   ===============================================================

初始标记： 暂停所有的其他线程(STW)，并记录下gc roots直接能引用的对象，速度很快。

并发标记： 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程， 这个过程耗时较长但
是不需要停顿用户线程， 可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的
对象状态发生改变。

重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对
象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到三
色标记里的增量更新算法(见下面详解)做重新标记。

并发清理： 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑
色不做任何处理(见下面三色标记算法详解)。

并发重置：重置本次GC过程中的标记数据。