项目背景

C端的项目，用户量比较多，请求比较多。

启动参数表

Xmx指定应用程序可用的最大堆大小。
Xms指定应用程序可用的最小堆大小。
（一般情况下，需要设置Xmx和Xms为相等的值，且为一个固定的值）
如果该值设置过小，那么当内存不足，则会去操作系统中申请内存，整体进行一个扩容的话，可能会产生内存的抖动。如果产生内存抖动则会导致我们服务有一个停顿。所以我们的考虑是一步扩到位，那么有人可能会说这种方式可能会对空间做一些浪费。那么一般我们整个容器是布置一个单体应用。这种情况下，是用空间换时间的一种方式。

-XX:newSize 新生代初始化内存的大小（注意：该值需要小于-Xms的值）。
-XX:MaxnewSize 新生代可被分配的内存的最大上限（注意：该值需要小于-Xmx的值）。

-XX:MetaspaceSize和-XX:MaxMetaspaceSize设置元空间初始大小以及最大可分配大小。
JDK1.8之后，设置了元空间去存储我们类的各种各样的信息，他是用来保证我们元数据大小的初始化和最大可分配的大小。

如果说，不配置的话，他会一直往我们的内存去进行申请。内存有多大，最大的峰值就可能达到多大。最好还是需要一个配置，防止把我们整个机器的内存占用，导致我们整个机器内存不够的情况。

-Xss：设置栈内存的大小，设置的栈的大小决定了函数调用的最大深度。
Xss设置的大小决定了函数调用的深度，如果函数调用的深度大小设置的Xss大小，那么将会抛“java.lang.StackOverflowError”异常。

-XX:+UnlockExperimentalVMOptions：解锁实验参数。

-XX:+UseParNewGC: 新生代用parnew收集器

-XX:ParallelGCThreads:这个参数是指定并行GC线程的数量，一般最好和CPU核心数量相当。默认情况下，当CPU数量小于8,ParallelGCThreads的值等于CPU数量，当CPU数量大于8时，则使用公式：ParallelGCThreads=8+(N-8)*5/8)=3+((5引*CPU)/8);同时这个参数只要是并行GC都可以使用，不只是ParNew。

-XX:+UseConcMarkSweepGC:使用cms收集器。
JVM分为新生代和老年代，老年代使用是cms收集器。

-XX:+UseCMSCompactAtFullCollection XX:CMSFullGCsBeforeCompaction=1:
来配置在进行了Full GC时，对老年代进行压缩整理，处理掉内存碎片，其中CMSFuLlGCsBeforeCompaction配置进行了多少次Full GC之后执行一次内存压缩。

-XX:CMSInitiatingOccupancyFraction可以指定当老年代空间使用的值达到多少才进行一次CMS拉圾回收。

-XX:+UseCMSInitiatingOccupancyOnly:指定用设定的回收阚值（-XX:CMSInitiatingOccupancyFraction参数的值），如果不指定，JVM仅在第一次使用设定值，后续则会根据运行时采集的数据做自动调整，如果指定了该参数，那么每次JVM都会在到达规定设定值时进行GC。不过大多数情况下，JVM都能够作出更好的垃圾收集决策，所以如果不是很有信心的话，不建议使用该参数，放心的把决定权交给JVM。

-XX:MaxTenuringThreshold设置的是年龄阈值，默认15（对象被复制的次数）

-XX:+ExplicitGCInvokesConcurrent:System.gc0是正常FULL GC,会产生STW（Stop of Work）。打开此参数后，在做System…gc0时会做background模式CMS GC,即并行FULL GC,可提高FULL GC效率。

-XX:+CMSParallelRemarkEnabled:通过CMSScavengeBeforeRemark参数可以强制在重新标记阶段之前强制进行一次YoungGC,通过设置CMSParallelRemarkEnabled参数可以开启并行的Remark,加快remark的速度。

-XX:-OmitStackTracelnFastThrow:字面意思是省略异常栈信息从而快速拖出，那么JVM是如何做到快速抛出的呢？JVM对一些特定的异常类型做了Fast Throw优化，如果检测到在代码里某个位置连续多次地出同一类型异常的话，C2会决定用Fast Throw方式来地出异常，而异常Trace即详细的异常栈信息会被清空。这种异常抛出速度非常快，因为不需要在堆里分配内存，也不需要构造完整的异常栈信息。

参考资料：【经验分享】Jvm调优最佳参数（仅供参考）