JVM 參數設置和回收算法

併發收集器(響應時間優先)，有須要的朋友能夠參考下。

　　併發收集器(響應時間優先)

　　-XX:+UseConcMarkSweepGC:即CMS收集，設置年老代爲併發收集。CMS收集是JDK1.4後期版本開始引入的新GC算法。它的主要適合場景是對響應時間的重要性需求大於對吞吐量的需求，可以承受垃圾回收線程和應用線程共享CPU資源，而且應用中存在比較多的長生命週期對象。CMS收集的目標是儘可能減小應用的暫停時間，減小Full GC發生的概率，利用和應用程序線程併發的垃圾回收線程來標記清除年老代內存。

　　-XX:+UseParNewGC:設置年輕代爲併發收集。可與CMS收集同時使用。JDK5.0以上，JVM會根據系統配置自行設置，因此無需再設置此參數。

　　-XX:CMSFullGCsBeforeCompaction=0:因爲併發收集器不對內存空間進行壓縮和整理，因此運行一段時間並行收集之後會產生內存碎片，內存使用效率下降。此參數設置運行0次Full GC後對內存空間進行壓縮和整理，即每次Full GC後馬上開始壓縮和整理內存。

　　-XX:+UseCMSCompactAtFullCollection:打開內存空間的壓縮和整理，在Full GC後執行。可能會影響性能，但能夠消除內存碎片。

　　-XX:+CMSIncrementalMode:設置爲增量收集模式。通常適用於單CPU狀況。

　　-XX:CMSInitiatingOccupancyFraction=70:表示年老代內存空間使用到70%時就開始執行CMS收集，以確保年老代有足夠的空間接納來自年輕代的對象，避免Full GC的發生。

　　其它垃圾回收參數

　　-XX:+ScavengeBeforeFullGC:年輕代GC優於Full GC執行。

　　-XX:-DisableExplicitGC:不響應 System.gc() 代碼。

　　-XX:+UseThreadPriorities:啓用本地線程優先級API.即便 java.lang.Thread.setPriority() 生效，不啓用則無效。

　　-XX:SoftRefLRUPolicyMSPerMB=0:軟引用對象在最後一次被訪問後能存活0毫秒(JVM默認爲1000毫秒)。

　　-XX:TargetSurvivorRatio=90:容許90%的Survivor區被佔用(JVM默認爲50%)。提升對於Survivor區的使用率。

　　輔助信息參數設置

　　-XX:-CITime:打印消耗在JIT編譯的時間。

　　-XX:ErrorFile=./hs_err_pid.log:保存錯誤日誌或數據到指定文件中。

　　-XX:HeapDumpPath=./java_pid.hprof:指定Dump堆內存時的路徑。

　　-XX:-HeapDumpOnOutOfMemoryError:當首次遭遇內存溢出時Dump出此時的堆內存。

　　-XX:OnError=";":出現致命ERROR後運行自定義命令。

　　-XX:OnOutOfMemoryError=";":當首次遭遇內存溢出時執行自定義命令。

　　-XX:-PrintClassHistogram:按下 Ctrl+Break 後打印堆內存中類實例的柱狀信息，同JDK的 jmap -histo 命令。

　　-XX:-PrintConcurrentLocks:按下 Ctrl+Break 後打印線程棧中併發鎖的相關信息，同JDK的 jstack -l 命令。

　　-XX:-PrintCompilation:當一個方法被編譯時打印相關信息。

　　-XX:-PrintGC:每次GC時打印相關信息。

　　-XX:-PrintGCDetails:每次GC時打印詳細信息。

　　-XX:-PrintGCTimeStamps:打印每次GC的時間戳。

　　-XX:-TraceClassLoading:跟蹤類的加載信息。

　　-XX:-TraceClassLoadingPreorder:跟蹤被引用到的全部類的加載信息。

　　-XX:-TraceClassResolution:跟蹤常量池。

　　-XX:-TraceClassUnloading:跟蹤類的卸載信息。

　　關於參數名稱等

　　標準參數(-)，全部JVM都必須支持這些參數的功能，並且向後兼容;例如：

　　-client--設置JVM使用Client模式，特色是啓動速度比較快，但運行時性能和內存管理效率不高，一般用於客戶端應用程序或開發調試;在32位環境下直接運行Java程序默認啓用該模式。

　　-server--設置JVM使Server模式，特色是啓動速度比較慢，但運行時性能和內存管理效率很高，適用於生產環境。在具備64位能力的JDK環境下默認啓用該模式。

　　非標準參數(-X)，默認JVM實現這些參數的功能，可是並不保證全部JVM實現都知足，且不保證向後兼容;

　　非穩定參數(-XX)，此類參數各個JVM實現會有所不一樣，未來可能會不被支持，須要慎重使用;

　　JVM服務參數調優實戰

　　大型網站服務器案例

　　承受海量訪問的動態Web應用

　　服務器配置：8 CPU, 8G MEM, JDK 1.6.X

　　參數方案：

　　-server -Xmx3550m -Xms3550m -Xmn1256m -Xss128k -XX:SurvivorRatio=6 -XX:MaxPermSize=256m -XX:ParallelGCThreads=8 -XX:MaxTenuringThreshold=0 -XX:+UseConcMarkSweepGC

　　調優說明：

　　-Xmx 與 -Xms 相同以免JVM反覆從新申請內存。-Xmx 的大小約等於系統內存大小的一半，即充分利用系統資源，又給予系統安全運行的空間。

　　-Xmn1256m 設置年輕代大小爲1256MB.此值對系統性能影響較大，Sun官方推薦配置年輕代大小爲整個堆的3/8.

　　-Xss128k 設置較小的線程棧以支持建立更多的線程，支持海量訪問，並提高系統性能。

　　-XX:SurvivorRatio=6 設置年輕代中Eden區與Survivor區的比值。系統默認是8,根據經驗設置爲6,則2個Survivor區與1個Eden區的比值爲2:6,一個Survivor區佔整個年輕代的1/8.

　　-XX:ParallelGCThreads=8 配置並行收集器的線程數，即同時8個線程一塊兒進行垃圾回收。此值通常配置爲與CPU數目相等。

　　-XX:MaxTenuringThreshold=0 設置垃圾最大年齡(在年輕代的存活次數)。若是設置爲0的話，則年輕代對象不通過Survivor區直接進入年老代。對於年老代比較多的應用，能夠提升效率;若是將此值設置爲一個較大值，則年輕代對象會在Survivor區進行屢次複製，這樣能夠增長對象再年輕代的存活時間，增長在年輕代即被回收的機率。根據被海量訪問的動態Web應用之特色，其內存要麼被緩存起來以減小直接訪問DB,要麼被快速回收以支持高併發海量請求，所以其內存對象在年輕代存活屢次意義不大，能夠直接進入年老代，根據實際應用效果，在這裏設置此值爲0.