作者簡介
超哥，2008年畢業後進入IT行業，目前就職於餓了麼物流架構部，曾就職於聯想研究院的AR裝置視覺團隊和阿里巴巴的業務中臺團隊。 工作內容涉及大資料計算平臺構建，計算視覺雲端應用，業務中介軟體研發以及業務領域模型抽象與實現等。 即時配送業務的高速增長，對系統的複雜度提出了更大的挑戰，同時也給我們足夠多的場景去嘗試與征服。
開發同學反饋應用docker化部署之後，gc時間比KVM部署時漲了好幾倍，最近正好手熱，上機器擼了一把。
問題定位
通過gc日誌收集工具，檢視jvm的gc資訊，平均單次ygc的時間非常不穩定，但基本上都在100ms以上。
從叢集裡隨機挑了幾臺機器看了一下gc log，每次gc的堆大小都比較正常，但是時間不太科學。
猜測是gc執行緒出了問題。jinfo檢視了
服務的docker容器分配了8核16g的資源，上面拉出來的gc執行緒和併發標記執行緒數是38和10，顯然不科學(猜測拉的宿主機的核數)。
預設的gc執行緒和併發標記執行緒數計算公式如下：
通過與運維同學溝通，瞭解到宿主機是56核，根據上面公式進行計算，對上了。
修改配置灰度驗證
從叢集中隨機挑選幾臺機器進行灰度，修改下jvm啟動引數，增加 -XX:ParallelGCThreads=8(8是容器核數），設定了ParallelGCThreads之後CMS的併發標記執行緒數會同步下降。
執行了一個晚上和一個白天，發現灰度機的ygc變的非常平穩，時間降到了 10ms左右，gc的log如下:
結論
因為容器不是物理隔離的，部署的java應用，務必要指定-XX:ParallelGCThreads=CPU_COUNT ，以防被YGC被坑了。
閱讀部落格還不過癮？
歡迎大家掃二維碼加入交流群，討論和部落格有關的技術問題，還可以和博主有更多互動
部落格轉載、線下活動及合作等問題請郵件至 shadowfly_zyl@hotmail.com 進行溝通
