記一次內存沒法回收致使頻繁fullgc機器假死的思路

肯定掛機 絡繹不絕的來不一樣類型的bug

當bug滾滾而來時，不要懷疑，你的發佈的應用基本是不可用狀態了。
觀察哨兵監控數據，特別是內存打到80%基本就掛機了，或者監控數據缺失也基本是掛機了。
此時應當立刻決斷：

• 通知運營暫停操做（大多數是由於後臺應用致使的，純經驗猜想，由於你也不可能讓外部用戶中止操做）
• 重啓大多數機器，保留一臺機器保存現場（下線機器）。

實例：

• 友品app首頁有頻率的失敗
• 運營提bug，後臺導出每次都不可用，其餘的偶現不可用

找到緣由 把此問題復現出來

根據各方面的反饋，加自身的迭代，找尋線索，積極在預發嘗試，以求肯定病根。

• 最近上線內容
• 最近使用操做
• 最近超時接口

實例：
見上描述，導出每次不可用，立刻在預發覆現此問題。
感謝運營的反饋，此處可總結，運營在使用系統過程當中出現問題要及時反饋，不要害羞。

肯定問題根源

線上通常內存偏大，有6-8G，用jmap下來文件很大，也不易分析。
此時可轉換思路，建立一個乾淨的環境，調試此固定邏輯。
這裏的問題是線上數據怎麼來？

1. dubbo 直連（不建議）
2. 通知運維導出線上數據

搭建本地環境，調試固定邏輯：

1. 相關業務邏輯遷移到本地（線上數據來源是2，此時須要導入數據，封裝dao）
2. 本地設置 -xms-xmx爲20M（設置本地使用內存）
3. jmap -histo 77710 >./Downloads/15.log 導出內存文件查看內存消耗
4. 分析並解決，若是是本身責任內則解決，不然拋出（純能力和經驗）

實例：
在本地環境調試後發現導出正常，20M內存能夠支撐導出37萬條數據沒有問題。
此時回過頭去看線上邏輯代碼，比本地多一個文件加水印，此時修改代碼，再文件生成後打印一條日誌，部署預發。
發現文件能夠生成，但文件加水印遲遲未結束。
去掉文件加水印後部署預發，導出正常。
此時排查出問題出在文件加水印，此爲中間件的工具，故而不作解決，直接去掉加水印提測。並報告問題給相應人。

總結

1. 判斷是否掛機
2. 通知運營暫停操做
3. 重啓大多數機器，保留一臺機器保存現場
4. 找到那個操做引發的此現象
5. 轉爲本地調試，找尋問題根源
6. 解決或拋出