? ? ? 早上醒來便被系統(tǒng)報警短信施加了不小的壓力，系統(tǒng)夜間多次報警起意，cpu使用率過高（超過90%）说贝，昨天晚上確實是上線了一個計算類的需求，不過算法相對簡單（簡單來說就是取兩個字符串的公共子串践惑，然后做一些處理),主觀上認為不會因為這導致cpu爆掉腹泌，但是問題就是隨著這個需求出現(xiàn)的，肯定拖不了干系尔觉，哎凉袱，bug排查往往就是這樣，感覺某某地方不應該有問題侦铜，但是除了他又別無懷疑對象专甩。
火急火燎的趕到公司，先申請了幾臺服務器擴容泵额，緩解下壓力配深，（leader也建議先下掉這個接口携添，但是我觀察了這個接口的具體指標后嫁盲，預估先擴下容，能撐住烈掠，撐不住再下羞秤，再則，下掉后左敌，現(xiàn)象也會隨之消失瘾蛋，更不利于排查問題）
擴容后，cpu和內存矫限，都降到了可以接受的程度哺哼。
開始排查
1:單臺服務器qps很低佩抹，個位數(shù)，可以放棄了取董。
2:想通過jstack看下棍苹，但是線上環(huán)境沒權限執(zhí)行這個命令，只能放棄
3:線下模擬茵汰，雖然感覺基本沒用枢里，畢竟上線之前，線下已經(jīng)測試了蹂午，但是死馬當作活馬醫(yī)栏豺，人總是會抱著萬一的想法的，不過現(xiàn)實并不理想豆胸，由于沒有跳出之前測試的思路奥洼，再次測試并沒有突破。
4:真正沒辦法了晚胡，就該冷靜下來了溉卓，既然公司不許線上環(huán)境使用jstack，jmap（確實也不應該允許使用搬泥，至少權限不能完全放開）,那么肯定又其他路子可以通向羅馬桑寨，在公司群里吼了一嗓子后，發(fā)現(xiàn)果然是我太low忿檩，公司的監(jiān)控系統(tǒng)是可以看到堆棧信息的（隨便推薦下公司開源的監(jiān)控系統(tǒng)cat尉尾，github地址：https://github.com/dianping/cat）
截圖如下：
根據(jù)堆棧信息，找到相關代碼燥透，截圖如下：
代碼相對來說簡單沙咏，但從代碼來看，除了list的遍歷寫的不太友好（具體就不細說了班套，都應該能看出來）之外肢藐，并看不出什么。算了吱韭，先把能看到的解決了吆豹，
但是上線之后，問題依舊的話豈不是很尷尬理盆，先測試下兩種方式的效果再說吧痘煤，簡單測試，發(fā)現(xiàn)list長度上萬之后猿规，效率才有差異衷快，果斷放棄這條線了（并不是不改，而是接著排查原因）姨俩，這樣基本就沒啥可排查了蘸拔，只有l(wèi)ist很大了可查了师郑，但是主觀上是不信的，再大能有多大呢调窍。按照之前的測試代碼debug之后呕乎，list長度并無問題，測試和線上不一樣的陨晶，也就只有入?yún)⒘蒜剩瑢α耍雲(yún)⑾扔ゾ€上log中找了cpu報警時的入?yún)⑹簦辛咙c，比測試環(huán)境長很多褐耳，好歹有可測的地方了诈闺，debug之后，果然铃芦，這個入?yún)⒀拍鳎樘幍膌ist的size竟然有將近7千，其中絕大部分都是空刃滓，后面就好定位了仁烹，算法邏輯有問題，在入?yún)⑤^長的情況下咧虎，很容易暴漏出來（這個需求的場景中卓缰，一把都很短，自測也確實不夠全面）砰诵，修復之后征唬，cpu降至個位數(shù)，搞定茁彭。
回頭來看总寒，問題本身很簡單，但是前后排查缺花了近2個小時理肺，讓自己長個急性摄闸，留個爪
