頻繁GC背景

處理過(guò)線上問(wèn)題的同學(xué)基本上都會(huì)遇到系統(tǒng)突然運(yùn)行緩慢，CPU 100%，以及Full GC次數(shù)過(guò)多的問(wèn)題。當(dāng)然，這些問(wèn)題的最終導(dǎo)致的直觀現(xiàn)象就是系統(tǒng)運(yùn)行緩慢，并且有大量的報(bào)警。

本文主要記一次針對(duì)系統(tǒng)頻繁GC這一問(wèn)題，提供該問(wèn)題的排查思路，從而定位出問(wèn)題的代碼點(diǎn)，進(jìn)而提供解決該問(wèn)題的思路。

不再重復(fù)贅述網(wǎng)上大部分排查GC命令，工具使用或者GC本身定義等

問(wèn)題描述

發(fā)現(xiàn)商品應(yīng)用product-dubbo頻繁GC告警

規(guī)則名稱: 【性能告警】應(yīng)用GC次數(shù)大于20次/分鐘（且新生代GC時(shí)間大于50ms）
觸發(fā)時(shí)值: 74
監(jiān)控指標(biāo): [AlarmName=GC次數(shù) application=product-dubbo ...]
持續(xù)時(shí)長(zhǎng): 0s
觸發(fā)時(shí)間: 2025-06-21 11:44:06

同時(shí)有慢接口告警

規(guī)則名稱: 【嚴(yán)重性能告警】應(yīng)用接口平均響應(yīng)時(shí)間大于1s
觸發(fā)時(shí)值: 2.4098
規(guī)則備注: 過(guò)去十分鐘內(nèi)的平均響應(yīng)時(shí)間
監(jiān)控指標(biāo): [AlarmName=接口RT application=product-client uri=/api/product/client/list]
持續(xù)時(shí)長(zhǎng): 0s
觸發(fā)時(shí)間: 2025-06-21 11:03:39

問(wèn)題排查思路

對(duì)于線上系統(tǒng)突然出現(xiàn)頻繁GC問(wèn)題，這種情況可能的原因主要有：代碼中某個(gè)位置讀取數(shù)據(jù)量較大，導(dǎo)致系統(tǒng)內(nèi)存耗盡，從而導(dǎo)致Full GC次數(shù)過(guò)多，那么首先需要做的就是，導(dǎo)出dump堆棧文件，分析其具體的內(nèi)存信息

使用線程轉(zhuǎn)儲(chǔ)(Thread Dump)分析工具：

鏈接: link

其中等待線程數(shù)558，超時(shí)等待線程數(shù)49，運(yùn)行線程數(shù)44

未發(fā)現(xiàn)消耗CPU的線程和阻塞線程

同時(shí)也沒有死鎖線程

排除掉異常線程導(dǎo)致頻繁gc問(wèn)題

進(jìn)一步分析線程池里包含的線程

其中dubbo線程占據(jù)90%，其余線程比如tomcat線程，logback線程，自定義線程池線程等只占一小部分

排查dubbo線程堆棧發(fā)現(xiàn)問(wèn)題

出現(xiàn)mysql存在異常

同時(shí)存在druid超時(shí)線程

綜合分析

dubbo線程調(diào)用方法里面出現(xiàn)mysql異常，結(jié)合告警的慢接口是同一處，懷疑是否是慢sql導(dǎo)致的數(shù)據(jù)庫(kù)連接池druid打滿，進(jìn)而導(dǎo)致dubbo大部分線程處于等待狀態(tài)

通過(guò)arthas分析本次告警的慢接口

trace com.biz.prooduct queryList '#cost > 100'

進(jìn)一步驗(yàn)證上述分析結(jié)論

通過(guò)arthas分析內(nèi)存對(duì)象

dumpheap --live /tmp/dump.hprof'

打開本地jvm分析工具分析hprof文件如下：

發(fā)現(xiàn)堆中占內(nèi)存前三位的分別是char[]、String 和 ConcurrentHashMap$Node三個(gè)類其中char[]占用絕大部分空間，進(jìn)一步分析char[]數(shù)據(jù)：

上述char[]中存放的基本都是/api/product/client/list返回的數(shù)據(jù)

綜合分析

由于/api/product/client/list是客戶端獲取商品列表接口，客戶端每次查詢商品都會(huì)去掉用，存在大量并發(fā)的場(chǎng)景，并且接口方法內(nèi)部是拉取全量商品數(shù)據(jù)。

同時(shí)該接口有數(shù)次慢sql的代碼，慢SQL進(jìn)一步導(dǎo)致數(shù)據(jù)庫(kù)連接池耗盡，進(jìn)而阻塞Dubbo線程的典型故障鏈，從而引發(fā)頻繁GC。

解決方案

1.慢sql優(yōu)化（通過(guò)執(zhí)行計(jì)劃按量?jī)?yōu)化索引等）

2.方法優(yōu)化（異步處理非核心代碼）

3.業(yè)務(wù)優(yōu)化（監(jiān)聽商品變動(dòng)方法，客戶端拉取全量商品存在本地，商品發(fā)生變動(dòng)通知客戶端重新拉取商品）

總結(jié)

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論