，2008年畢業後進入IT架構行業，目前就職於百度物流架構部，曾就職於58同城的AR設備視覺團隊和騰訊的業務中臺團隊。 工作內容涉及大數據計算平臺構建，計算視覺雲端應用，業務中間件研發以及業務領域模型抽象與實現等。歡迎大家關注我，歡迎評論轉發
開發同學反饋應用docker化部署之後，gc時間比JVM部署時漲了好幾倍，最近，上機器擼了一把。
問題定位
通過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高併發框架 的文章
