1 資料
2 GC日志打印
GC調優(yōu)是個很實驗很伽利略的活兒，GC日志是先決的數(shù)據(jù)參考和最終驗證：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps(GC發(fā)生的時間) -XX:+PrintGCApplicationStoppedTime(GC消耗了多少時間) -XX:+PrintGCApplicationConcurrentTime(GC之間運行了多少時間)
3 收集器選擇
CMS收集器：暫停時間優(yōu)先
配置參數(shù)：-XX:+UseConcMarkSweepGC
已默認無需配置的參數(shù)：-XX:+UseParNewGC(Parallel收集新生代) -XX:+CMSPermGenSweepingEnabled(CMS收集持久代) -XX:UseCMSCompactAtFullCollection(FullGC時壓縮年老代)
初始效果：1G堆內存的新生代約60m，minor gc約5-20毫秒，full gc約130毫秒。
Parallel收集器：吞吐量優(yōu)先
配置參數(shù)： -XX:+UseParallelGC -XX:+UseParallelOldGC(Parallel收集年老代，從JDK6.0開始支持)
已默認無需配置的參數(shù)： -XX:+UseAdaptiveSizePolicy(動態(tài)調整新生代大小)
初始效果：1G堆內存的新生代約90-110m(動態(tài)調整)，minor gc約5-20毫秒，full gc沒有UseParallelOldGC 參數(shù)約 1.3秒，有UseParallelOldGC參數(shù)約1.06秒，差別不大。
另外-XX:MaxGCPauseMillis=100 設置期望minor gc的最大時間，JVM會以此來調整新生代的大小，但在此測試環(huán)境中對象死的太快，此參數(shù)作用不大。
4 調優(yōu)實戰(zhàn)
Parallel收集高達1秒的暫停時間基本不可忍受，所以選擇CMS收集器。
不知為何在被壓的Mule 2.0應用里，每秒都有大約400M的海量短命對象產生：
- 因為默認60M的新生代太小了，頻繁發(fā)生minor gc，大約0.2秒就進行一次。
- 因為CMS收集器中MaxTenuringThreshold(生代對象撐過過多少次minor gc才進入年老代的設置)默認0，存活的臨時對象不經過Survivor區(qū)直接進入年老代，不久就占滿年老代發(fā)生full gc。
對這兩個參數(shù)進行調優(yōu)，既要改善上面兩種情況，又要避免新生代過大，復制次數(shù)過多造成minor gc的暫停時間過長。
- 使用-Xmn調到1/3 總內存。比較后設置-Xmn500m，新生代實際約460m。(-XX:NewRatio參數(shù)無效)。
- 添加-XX:+PrintTenuringDistribution 參數(shù)觀察各個Age的對象總大小，觀察后設置-XX:MaxTenuringThreshold=5。
優(yōu)化后，大約1.1秒才發(fā)生一次minor GC，同時年老代的增長速度大大減緩，預計幾個小時才會發(fā)生一次GC，而minor gc速度依然保持在15-20ms之間。
參數(shù)定稿：
-Xms1024m -Xmx1024m -Xmn500m -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=5 -XX:+ExplicitGCInvokesConcurrent
最后服務處理速度從1180 tps 上升到1380 tps，調整兩個參數(shù)提升17%的性能還是筆很劃算的買賣。