2016-10-16T15:42:04.951+0800: 229702.081: [GC [1 CMS-initial-mark: 1479564K(2097152K)] 1970155K(3984640K), 3.2226160 secs] [Times: user=3.23 sys=0.00, real=3.22 secs] 
##初始標(biāo)記 stop-customer-thread{因此此階段標(biāo)記的對象只是從root集最直接可達(dá)的對象}
2016-10-16T15:42:08.174+0800: 229705.304: [CMS-concurrent-mark-start]
2016-10-16T15:42:10.193+0800: 229707.323: [CMS-concurrent-mark: 1.895/2.019 secs] [Times: user=11.04 sys=0.22, real=2.02 secs] 
##開始并發(fā)標(biāo)記 no-stop-customer-thread{此階段是和應(yīng)用線程并發(fā)執(zhí)行的，所謂并發(fā)收集器指的就是這個，主要作用是標(biāo)記可達(dá)的對象}
2016-10-16T15:42:10.193+0800: 229707.323: [CMS-concurrent-preclean-start]
2016-10-16T15:42:10.203+0800: 229707.333: [CMS-concurrent-preclean: 0.009/0.010 secs] [Times: user=0.04 sys=0.00, real=0.01 secs]
##開始預(yù)清理preclean{并發(fā)}階段 ---{此階段主要是進行一些預(yù)清理，因為標(biāo)記和應(yīng)用線程是并發(fā)執(zhí)行的，因此會有些對象的狀態(tài)在標(biāo)記后會改變，此階段正是解決這個問題}
##---重點-start
2016-10-16T15:42:40.380+0800: 229737.510: [CMS-concurrent-abortable-preclean-start]
 CMS: abort preclean due to time 2016-10-16T15:42:45.454+0800: 229742.584: [CMS-concurrent-abortable-preclean: 1.510/5.073 secs] [Times: user=11.25 sys=0.32, real=5.07 secs]
##---重點-end
##終止preclean
2016-10-16T15:42:45.516+0800: 229742.646: [GC[YG occupancy: 660948 K (1887488 K)] ##yonggc情況
    2016-10-16T15:42:45.516+0800: 229742.646: [Rescan (parallel) , 2.6980830 secs] ##第二個stop-customer-thread階段了,即Rescan階段,此階段暫停應(yīng)用線程,對對象進行重新掃描并
     標(biāo)記 花費了2.6秒
    2016-10-16T15:42:48.214+0800: 229745.344: [weak refs processing, 0.0000400 secs] ##若引用耗時
    2016-10-16T15:42:48.214+0800: 229745.344: [scrub string table, 0.0019500 secs]  ##類卸載耗時
                          [1 CMS-remark: 1479888K(2097152K)] 2140836K(3984640K), 2.7003330 secs] ##老年代-remark耗時
                          [Times: user=21.08 sys=0.03, real=2.70 secs] 
<<!-- 
2016-12-13T06:29:47.359+0800: 73101.931: [Full GC2016-12-13T06:29:47.359+0800: 73101.932: 
                      [CMS[YG occupancy: 907481 K (1747648 K)]
    2016-12-13T06:29:49.783+0800: 73104.356: [weak refs processing, 0.0002290 secs]2016-12-13T06:29:49.784+0800: 73104.356: [scrub string table, 0.0017710 secs]: 436765K->296514K(2097152K), 2.6775580 secs] 1344246K->1203995K(3844800K), [CMS Perm : 114819K->114819K(115136K)], 2.6784240 secs] [Times: user=3.03 sys=0.00, real=2.68 secs] 
-->>
    
##stop-customer-thread 階段,從根及被其引用對象開始，重新掃描 CMS 堆中殘留的更新過的對象。
2016-10-16T15:42:48.216+0800: 229745.346: [CMS-concurrent-sweep-start]
2016-10-16T15:42:49.057+0800: 229746.187: [CMS-concurrent-sweep: 0.774/0.840 secs] [Times: user=1.93 sys=0.06, real=0.84 secs]
##并發(fā)垃圾清理 no-stop-customer-thread
2016-10-16T15:42:49.057+0800: 229746.187: [CMS-concurrent-reset-start]
2016-10-16T15:42:49.064+0800: 229746.194: [CMS-concurrent-reset: 0.007/0.007 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
##最后。為下一次cms gc重置相關(guān)數(shù)據(jù)結(jié)構(gòu) no-stop-customer-thread
2016-10-16T15:42:49.641+0800: 229746.771: [GC [1 CMS-initial-mark: 1479877K(2097152K)] 2229843K(3984640K), 3.3950880 secs] [Times: user=3.40 sys=0.00, real=3.40 secs] 
## 下一次標(biāo)記階段 

綜上所述：
    a.之前問題發(fā)生在配置-XX:CMSInitiatingOccupancyFraction=70，老年代被占用70%時，才進行cms-gc的intial-mark-preclean-rescan-sweep-reset。當(dāng)時jvm總?cè)萘渴?g，新生到2g，老年代2g，老年代的70%是1467mb，那么剩下的也就不到600m，此時問題有兩個：1.如果此時有大對象通過空間擔(dān)保機制直接從新生代逾越到老年代，此時系統(tǒng)可能直接宕機。2.1467mb的老年代容量不算小，雖然cms是concurrent進行標(biāo)記-整理，但是過多的對象會導(dǎo)致上面log中的CMS-initial-mark、Rescan-remark 壓力巨大，每次時間都達(dá)到了2~3秒，這種開銷是要命的，這就是為什么系統(tǒng)半死不活的狀態(tài)，對外服務(wù)tp拉高。
    b.從日志中分析得出： CMS: abort preclean due to time。這句話翻譯過來是說：cms 終止了preclean操作花費時間是5.073s 這是一個浪費的開銷，預(yù)清理操作明細(xì)是一個優(yōu)化清理的動作，結(jié)果成為負(fù)擔(dān)了。這里也是我們著重優(yōu)化的點：-XX:CMSMaxAbortablePrecleanTime=500(單位是毫秒) 來約束preclean動作，還可以用其他參數(shù)進行約束preclean如：-XX:CMSScheduleRemarkEdenPenetration、-XX:CMSScheduleRemarkEdenPenetration

    c.年輕代的優(yōu)化也是這次的重點：年輕代設(shè)置過大會這樣？


有2種情況會觸發(fā)full gc，在full gc時，整個應(yīng)用會暫停
a）concurrent-mode-failure：當(dāng)cms gc正進行時，此時有新的對象要進行old代，但是old代空間不足造成的
b）promotion-failed：當(dāng)進行young gc時，有部分young代對象仍然可用，但是S1或S2放不下，
    因此需要放到old代，但此時old代空間無法容納此