gc調優是個很實驗很伽利略的活兒，gc日誌是先決的資料參考和最終驗證：
cms收集器：暫停時間優先
配置引數：-xx:+useconcmarksweepgc
已預設無需配置的引數：-xx:+useparnewgc(parallel收集新生代) -xx:+cmspermgensweepingenabled(cms收集持久代) -xx:usecmscompactatfullcollection(full gc時壓縮年老代)
初始效果：1g堆記憶體的新生代約60m，minor gc約5-20毫秒，full gc約130毫秒。
parallel收集器：吞吐量優先
配置引數： -xx:+useparallelgc -xx:+useparalleloldgc(parallel收集年老代，從jdk6.0開始支援)
已預設無需配置的引數： -xx:+useadaptivesizepolicy(動態調整新生代大小)
初始效果：1g堆記憶體的新生代約90-110m(動態調整)，minor gc約5-20毫秒，full gc有無useparalleloldgc 引數分別為1.3/1.1秒，差別不大。
另外-xx:maxgcpausemillis=100 設定minor gc的期望最大時間，jvm會以此來調整新生代的大小，但在此測試環境中物件死的太快，此引數作用不大。
parallel收集高達1秒的暫停時間基本不可忍受，所以選擇cms收集器。
在被壓測的mule 2.0應用裡，每秒都有大約400m的海量短命物件產生：
因為預設60m的新生代太小了，頻繁發生minor gc，大約0.2秒就進行一次。
因為cms收集器中maxtenuringthreshold(生代物件撐過過多少次minor gc才進入年老代的設定)預設0，存活的臨時物件不經過survivor區直接進入年老代，不久就佔滿年老代發生full gc。
對這兩個引數的調優，既要改善上面兩種情況，又要避免新生代過大，複製次數過多造成minor gc的暫停時間過長。
使用-xmn調到1/3 總記憶體。觀察後設定-xmn500m，新生代實際約460m。(用-xx:newratio設定無效，只能用 -xmn)。
新增-xx:+printtenuringdistribution 引數觀察各個age的物件總大小，觀察後設定-xx:maxtenuringthreshold=5。
優化後，大約1.1秒才發生一次minor gc，且速度依然保持在15-20ms之間。同時年老代的增長速度大大減緩，很久才發生一次full gc，
引數定稿：
-server -xms1024m -xmx1024m -xmn500m -xx:+useconcmarksweepgc -xx:maxtenuringthreshold=5 -xx:+explicitgcinvokesconcurrent最後服務處理速度從1180 tps 上公升到1380 tps，調整兩個引數提公升17%的效能還是筆很划算的買賣。
另外，jdk6 update 7自帶了乙個visualvm工具，內裡就是之前也有用過的netbean profiler，類似jconsole一樣使用，可以看到執行緒狀態，記憶體中物件以及方法的cpu時間等調優重要參考依據。免費**啊，sun 這樣搞法，其他做profiler的公司要關門了。
（源自：
Java垃圾收集調優實戰
cms收集器 暫停時間優先 配置引數 xx useconcmarksweepgc 已預設無需配置的引數 xx useparnewgc parallel收集新生代 xx cmspermgensweepingenabled cms收集持久代 xx usecmscompactatfullcollectio...
一次Java垃圾收集調優實戰
cms收集器 暫停時間優先 配置引數 xx useconcmarksweepgc 已預設無需配置的引數 xx useparnewgc parallel收集新生代 xx cmspermgensweepingenabled cms收集持久代 xx usecmscompactatfullcollectio...
一次Java垃圾收集調優實戰
cms收集器 暫停時間優先 配置引數 xx useconcmarksweepgc 已預設無需配置的引數 xx useparnewgc parallel收集新生代 xx cmspermgensweepingenabled cms收集持久代 xx usecmscompactatfullcollectio...