早上被報(bào)警叫醒，使用gceasy.io分析了服務(wù)器的gc日志猜揪，報(bào)告見：2017-05-28 gc.log報(bào)告
這份報(bào)告里明確得指出了應(yīng)用的問題惭墓，即在2017.2.28 07:09左右發(fā)生了長時(shí)間的GC停頓，入下圖所示：
gc報(bào)告問題
- 點(diǎn)擊進(jìn)入reduce long GC pause而姐，這篇文章列舉了幾個(gè)可能引起長時(shí)間GC停頓的原因：
- 高速的對(duì)象創(chuàng)建速率腊凶，報(bào)告顯示我的應(yīng)用沒問題
- Heap區(qū)域，年輕代較幸闳恕吭狡；jdk 1.8只配置了Xmx和Xms相同大小尖殃，2048丈莺，沒有指定-Xmn或-XX:NewRatio，可能有影響送丰；
- GC算法選擇問題缔俄，我使用G1回收器：G1回收器適合高并發(fā)場景，應(yīng)該沒問題
- Process Swapping器躏，進(jìn)程內(nèi)存置換
- 較少的GC線程
- 后臺(tái)IO阻塞俐载，根據(jù)系統(tǒng)監(jiān)控發(fā)現(xiàn)在同一時(shí)間IO延時(shí)、占用CPU都飆高登失，懷疑是這個(gè)問題遏佣。
- 點(diǎn)擊進(jìn)入fix this problem，這篇文章首先介紹了user-time揽浙、system-time和real-time的區(qū)別状婶，由于多線程進(jìn)行GC過程，因此在正常情況下馅巷，real-time應(yīng)該小于user-time + system-time（例如：如果user-time + system-time為2秒膛虫，而有5個(gè)線程在執(zhí)行GC算法，那么real-time應(yīng)該為400毫秒）钓猬。但是在一些特定場景下會(huì)出現(xiàn)real-time大于user-time + system-time之和稍刀，如果在GC日志中出現(xiàn)多個(gè)這樣的情況，原因可能是：IO飆高敞曹；CPU資源耗盡账月。
綜上分析综膀，可能是JVM參數(shù)或io問題引起的GC長時(shí)間停頓，IO問題可能性更高局齿。
