JVM CMS 经常使用参数配置（修订）

-XX:+UseConcMarkSweepGC

该标志首先是激活CMS收集器。默认HotSpot JVM使用的是并行收集器。

-XX:UseParNewGC

当使用CMS收集器时，该标志激活年轻代使用多线程并行执行垃圾回收。这使人很惊讶，咱们不能简单在并行收集器中重用-XX:UserParNewGC标志，由于概念上年轻代用的算法是同样的。然而，对于CMS收集器，年轻代GC算法和老年代GC算法是不一样的，所以年轻代GC有两种不一样的实现，而且是两个不一样的标志。注意最新的JVM版本，当使用-XX:+UseConcMarkSweepGC时，-XX:UseParNewGC会自动开启。所以，若是年轻代的并行GC不想开启，能够经过设置-XX:-UseParNewGC来关掉。

-XX:+CMSParallelRemarkEnabled

采用并行标记方式下降停顿。

-XX:+CMSConcurrentMTEnabled

当该标志被启用时，并发的CMS阶段将以多线程执行（所以，多个GC线程会与全部的应用程序线程并行工做）。该标志已经默认开启，若是顺序执行更好，这取决于所使用的硬件，多线程执行能够经过-XX:-CMSConcurremntMTEnabled禁用。

-XX:ConcGCThreads

标志-XX:ConcGCThreads=<value>（早期JVM版本也叫-XX:ParallelCMSThreads）定义并发CMS过程运行时的线程数。好比value=4意味着CMS周期的全部阶段都以4个线程来执行。尽管更多的线程会加快并发CMS过程，但其也会带来额外的同步开销。所以，对于特定的应用程序，应该经过测试来判断增长CMS线程数是否真的可以带来性能的提高。若是还标志未设置，JVM会根据并行收集器中的-XX:ParallelGCThreads参数的值来计算出默认的并行CMS线程数。该公式是ConcGCThreads =(ParallelGCThreads + 3)/4。所以，对于CMS收集器，-XX:ParallelGCThreads标志不只影响“stop-the-world”垃圾收集阶段，还影响并发阶段。总之，有很多方法能够配置CMS收集器的多线程执行。正是因为这个缘由,建议第一次运行CMS收集器时使用其默认设置, 而后若是须要调优再进行测试。只有在生产系统中测量（或类生产测试系统）发现应用程序的暂停时间的目标没有达到 , 就能够经过这些标志应该进行GC调优。

-XX:CMSInitiatingOccupancyFraction

当堆满以后，并行收集器便开始进行垃圾收集，例如，当没有足够的空间来容纳新分配或提高的对象。对于CMS收集器，长时间等待是不可取的，由于在并发垃圾收集期间应用持续在运行（而且分配对象）。所以，为了在应用程序使用完内存以前完成垃圾收集周期，CMS收集器要比并行收集器更先启动。由于不一样的应用会有不一样对象分配模式，JVM会收集实际的对象分配(和释放)的运行时数据，而且分析这些数据，来决定何时启动一次CMS垃圾收集周期。为了引导这一过程，JVM会在一开始执行CMS周期前做一些线索查找。该线索由-XX:CMSInitiatingOccupancyFraction=<value>来设置，该值表明老年代堆空间的使用率。好比，value=75意味着第一次CMS垃圾收集会在老年代被占用75%时被触发。一般CMSInitiatingOccupancyFraction的默认值为68（以前很长时间的经从来决定的）。

-XX:+UseCMSInitiatingOccupancyOnly

咱们用-XX:+UseCMSInitiatingOccupancyOnly标志来命令JVM不基于运行时收集的数据来启动CMS垃圾收集周期。而是，当该标志被开启时，JVM经过CMSInitiatingOccupancyFraction的值进行每一次CMS收集，而不只仅是第一次。然而，请记住大多数状况下，JVM比咱们本身能做出更好的垃圾收集决策。所以，只有当咱们充足的理由（好比测试）而且对应用程序产生的对象的生命周期有深入的认知时，才应该使用该标志。

-XX:+CMSClassUnloadingEnabled

相对于并行收集器，CMS收集器默认不会对永久代进行垃圾回收。若是但愿对永久代进行垃圾回收，可用设置标志-XX:+CMSClassUnloadingEnabled。在早期JVM版本中，要求设置额外的标志-XX:+CMSPermGenSweepingEnabled。注意，即便没有设置这个标志，一旦永久代耗尽空间也会尝试进行垃圾回收，可是收集不会是并行的，而再一次进行Full GC。

-XX:+CMSIncrementalMode

该标志将开启CMS收集器的增量模式。增量模式常常暂停CMS过程，以便对应用程序线程做出彻底的让步。所以，收集器将花更长的时间完成整个收集周期。所以，只有经过测试后发现正常CMS周期对应用程序线程干扰太大时，才应该使用增量模式。因为现代服务器有足够的处理器来适应并发的垃圾收集，因此这种状况发生得不多。

-XX:+ExplicitGCInvokesConcurrent和-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses

现在,被普遍接受的最佳实践是避免显式地调用GC（所谓的“系统GC”），即在应用程序中调用system.gc()。然而，这个建议是无论使用的GC算法的，值得一提的是，当使用CMS收集器时，系统GC将是一件很不幸的事，由于它默认会触发一次Full GC。幸运的是，有一种方式能够改变默认设置。标志-XX:+ExplicitGCInvokesConcurrent命令JVM不管何时调用系统GC，都执行CMS GC，而不是Full GC。第二个标志-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses保证当有系统GC调用时，永久代也被包括进CMS垃圾回收的范围内。所以，经过使用这些标志，咱们能够防止出现意料以外的“stop-the-world”的系统GC。

-XX:+DisableExplicitGC

然而在这个问题上…这是一个很好提到-XX:+DisableExplicitGC标志的机会，该标志将告诉JVM彻底忽略系统的GC调用（无论使用的收集器是什么类型）。对于我而言，该标志属于默认的标志集合中，能够安全地定义在每一个JVM上运行，而不须要进一步思考。

-XX:+UseCompressedOops

这个参数用于对类对象数据进行压缩处理，提升内存利用率。

-XX:MaxGCPauseMillis=50

这个参数用于设置GC暂停等待时间，单位为毫秒，不要设置太低。

综上所述，通常状况下，推荐使用以下的参数设置：

 

-XX:+UseCompressedOops
-XX:MaxGCPauseMillis=50
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:+CMSClassUnloadingEnabled