內存溢出(Out Of Memory，簡稱OOM)是指應用系統中存在無法回收的內存或使用的內存過多，最終使得程序運行要用到的內存大於能提供的最大內存。此時程序就運行不了，系統會提示內存溢出，有時候會自動關閉軟件，重啓電腦或者軟件後釋放掉一部分內存又可以正常運行該軟件，而由系統配置、數據流、用戶代碼等原因而導致的內存溢出錯誤，即使用戶重新執行任務依然無法避免。
JVM發生OOM異常可能是以下幾種情況：Java堆溢出、虛擬機棧和本地方法棧溢出、方法區和運行時常量池溢出、本機直接內存溢出。這幾種情況分別由不同的原因引起。
而在真實的業務場景中，環境往往更加複雜。今天，堆堆就帶大家學習幾個OOM問題排查實戰案例，通過幾位作者記錄的真實案例，提醒自己避免踩坑，也順便複習相關知識點。
1.體驗了一把線上CPU100%及應用OOM的排查和解決過程
作者：阿飛雲 https://heapdump.cn/article/1665572 概述： 作者在收到應用異常告警後，登錄了出現問題的服務器進行檢查，在查看服務的日誌時發現服務OOM了，緊接着使用Top命令查看系統中各個進程的資源佔用狀況，發現有一個進程CPU使用率達到了300%，然後查詢該進程下所有線程的CPU使用情況並保存堆棧數據。根據前述操作，獲取了出現問題的服務的GC信息、線程堆棧、堆快照等數據之後，使用HeapDump社區提供的XElephant進行分析，發現是InMemoryReporterMetrics引起的OOM，進一步發現出現問題的這個服務依賴的zipkin版本較低，將其升級後解決了問題。
亮點：雖然本文描述和解決的不是罕見的疑難雜症，但排查思路清晰，過程完整，還推薦了排查工具，適合新手閱讀學習。
2.一次容器化springboot程序OOM問題探險
作者：俠夢 https://heapdump.cn/article/1588447
概述：作者被告知一個容器化的java程序每跑一段時間就會出現OOM問題，首先查日誌並未發現異常；然後通過JStat查看GC情況，發現GC情況正常但ByteBuffer對象佔用最高（異常點1）；接着通過JStack查看線程快照情況，發現創建了過多kafka生產者（異常點2）；最後通過編寫Demo程序驗證猜想，確定問題是業務代碼中循環創建Producer對象導致的。
亮點：排查過程清晰明瞭，工具使用嫺熟，驗證過程快速準確。
3.一次百萬長連接壓測 Nginx OOM 的問題排查分析
作者：挖坑的張師傅 https://heapdump.cn/article/433792
概述： 作者在一次百萬長連接壓測中，發現32C 128G的四臺Nginx頻繁出現OOM。發現問題後首先查看了 Nginx 和客戶端兩端的網絡連接狀態，首先懷疑是jmeter客戶端處理能力有限，有較多消息堆積在中轉的Nginx處，於是dump了nginx的內存查看，堅定了是因爲緩存了大量的消息導致的內存上漲；隨後查看了 Nginx 的參數配置，發現proxy_buffers 這個值設置的特別大；然後模擬了upstream 上下游收發速度不一致對Nginx內存佔用的影響。最後將proxy_buffering 設置爲 off並調小了 proxy_buffer_size 的值以後，Nginx的內存穩定了。
亮點：作者排查思路清晰，工具使用、參數調節十分嫺熟，對底層原理和源碼理解深刻，無論是經驗還是態度都十分值得學習參考。