搜集到的一些參數內容，比較有用，大部分轉載自并發編程網ifeve.com。

-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
然而在這個問題上&hellip;這是一個很好提到-XX:+DisableExplicitGC標志的機會，該標志將告訴JVM完全忽略系統的GC調用（不管使用的收集器是什么類型）。對于我而言，該標志屬于默認的標志集合中，可以安全地定義在每個JVM上運行，而不需要進一步思考。