一 公司CMS参数
先说一下公司CMS参数，年轻代3.5G, 其中survivor 50M。老年代1.5G，其实用不到500M，原空间250M。
二 常见参数配置
1 开启 CMS
首先，要说的是，CMS只是老年代的垃圾收集器。其年轻代使用的是ParNew垃圾收集器。
其次，JDK8默认的垃圾收集器并不是CMS，需要手动指定。-XX:+UseConcMarkSweepGC -XX:+UseParNewGC
2 设置堆大小
使用CMS建议总堆空间不超过8G，最好是6G以内。因为如果发生FGC，太大的堆空间会让FGC的STW时间变的特别的长。
-Xmx4G -Xms4G -Xmn1512M
3 线程栈
JDK8默认的线程栈大小是1M，绝大多数微服务项目可以调整为512K -XSS512K
4 -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly
表示只有在老年代达到了70%才进行回收
5 -XX:MetaspaceSize=314572800 其实是300M
因为之前发生过元空间引发的FGC，所以我们项目把这个参数调大了。因为本项目的特点是，会请求大量的接口，引入大量的类。
6 dump路径
必须配置，因为如果发生了OOM，不dump的话，没法定位问题。
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/applogs/system/error.dump
7 GC 日志
必须配置
-XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
-Xloggc:/data/log/gclog/gc.log
8 压缩
CMS是一种并发标记清除算法，而不是标记整理算法。所以，它不会进行碎片内存的移动和整理。
-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0
0表示每次发生fullgc 都进行压缩整理
9 卸载类
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
如果项目中使用了Netty，或者代码里用了堆外内存，只有FGC才能回收这样的堆外内存。也就是说想手动清理堆外内存就得执行System.gc()。而System.gc()触发的是serial old垃圾收集器，时间会很长，一般在5s左右。而FGC的STW的时间会很长，（CMS的完整FGC是退化为线性GC）。而CMS GC暂停服务的时间较短。因此，加了这个参数可以有效地回收堆外内存并且减少暂停时间。
这两个参数也是用来改变System.gc()的默认行为用的；不同的 是这两个参数只能配合CMS使用（-XX:+UseConcMarkSweepGC），而且System.gc()还是会触发GC的，只不过不是触发一个 完全stop-the-world的full GC，而是一次并发GC周期。也还是会触发对外内存的回收。
- CMS采用了Mark-Sweep算法，最后会产生许多内存碎片，当到一定数量时，CMS无法清理这些碎片了，CMS会让Serial Old垃圾处理器来清理这些垃圾碎片，而Serial Old垃圾处理器是单线程操作进行清理垃圾的，效率很低。所以使用CMS就会出现一种情况，硬件升级了，却越来越卡顿，其原因就是因为进行Serial Old GC时，效率过低。
- 解决方案：使用Mark-Sweep-Compact算法，减少垃圾碎片
- 调优参数（配套使用）：-XX:+UseCMSCompactAtFullCollection 开启CMS的压缩
-XX:CMSFullGCsBeforeCompaction 默认为0，指经过多少次CMS FullGC才进行压缩 - 当JVM认为内存不够，再使用CMS进行并发清理内存可能会发生OOM的问题，而不得不进行Serial Old GC，Serial Old是单线程垃圾回收，效率低
- 解决方案：降低触发CMS GC的阈值，让浮动垃圾不那么容易占满老年代
- 调优参数：-XX:CMSInitiatingOccupancyFraction 92% 可以降低这个值，让老年代占用率达到该值就进行CMS GC
附上公司启动脚本
java -jar -javaagent:/data/gravity/gravity-agent.jar=appName=trade-om-app,baseUrl=http://gravity-api.amh-group.com,appType=jar
-Xms8192m -Xmx8192m -Xmn5460m -XX:MetaspaceSize=300m -XX:MaxMetaspaceSize=600m -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/data/applogs/system/error.dump -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
-XX:CMSInitiatingOccupancyFraction=70 -XX:+PrintGCDateStamps -XX:+UseCMSInitiatingOccupancyOnly -XX:+UnlockDiagnosticVMOptions
-XX:+UnsyncloadClass -XX:+UseParNewGC -XX:+PrintGCDetails -Xloggc:/data/applogs/system/gc_202007061528.log
可以看到 配置eden和survivor比例没有配置，应该是使用默认的。
IBM论文里说据他们统计95%的对象朝生夕死一样存活时间极短，为了保险默认实际使用了90%：设置eden 和survivor（两个）为4：1，每次GC都将Eden和其中一个survivor（from）中的存活对象复制到剩余的survivor（to）中