內(nèi)存溢出(Out Of Memory，簡(jiǎn)稱OOM)是指應(yīng)用系統(tǒng)中存在無(wú)法回收的內(nèi)存或使用的內(nèi)存過(guò)多，最終使得程序運(yùn)行要用到的內(nèi)存大于能提供的最大內(nèi)存。此時(shí)程序就運(yùn)行不了，系統(tǒng)會(huì)提示內(nèi)存溢出晒他，有時(shí)候會(huì)自動(dòng)關(guān)閉軟件，重啟電腦或者軟件后釋放掉一部分內(nèi)存又可以正常運(yùn)行該軟件逸贾，而由系統(tǒng)配置陨仅、數(shù)據(jù)流、用戶代碼等原因而導(dǎo)致的內(nèi)存溢出錯(cuò)誤铝侵，即使用戶重新執(zhí)行任務(wù)依然無(wú)法避免灼伤。
JVM發(fā)生OOM異常可能是以下幾種情況：Java堆溢出哟沫、虛擬機(jī)棧和本地方法棧溢出饺蔑、方法區(qū)和運(yùn)行時(shí)常量池溢出、本機(jī)直接內(nèi)存溢出嗜诀。這幾種情況分別由不同的原因引起猾警。
而在真實(shí)的業(yè)務(wù)場(chǎng)景中，環(huán)境往往更加復(fù)雜隆敢。今天发皿，堆堆就帶大家學(xué)習(xí)幾個(gè)OOM問(wèn)題排查實(shí)戰(zhàn)案例，通過(guò)幾位作者記錄的真實(shí)案例拂蝎，提醒自己避免踩坑穴墅，也順便復(fù)習(xí)相關(guān)知識(shí)點(diǎn)。
1.體驗(yàn)了一把線上CPU100%及應(yīng)用OOM的排查和解決過(guò)程
作者：阿飛云
體驗(yàn)了一把線上CPU100%及應(yīng)用OOM的排查和解決過(guò)程 | HeapDump性能社區(qū)
概述：
作者在收到應(yīng)用異常告警后温自，登錄了出現(xiàn)問(wèn)題的服務(wù)器進(jìn)行檢查玄货，在查看服務(wù)的日志時(shí)發(fā)現(xiàn)服務(wù)OOM了，緊接著使用Top命令查看系統(tǒng)中各個(gè)進(jìn)程的資源占用狀況悼泌，發(fā)現(xiàn)有一個(gè)進(jìn)程CPU使用率達(dá)到了300%松捉，然后查詢?cè)撨M(jìn)程下所有線程的CPU使用情況并保存堆棧數(shù)據(jù)。根據(jù)前述操作馆里，獲取了出現(xiàn)問(wèn)題的服務(wù)的GC信息隘世、線程堆棧、堆快照等數(shù)據(jù)之后鸠踪，使用HeapDump社區(qū)提供的XElephant進(jìn)行分析丙者，發(fā)現(xiàn)是InMemoryReporterMetrics引起的OOM，進(jìn)一步發(fā)現(xiàn)出現(xiàn)問(wèn)題的這個(gè)服務(wù)依賴的zipkin版本較低营密，將其升級(jí)后解決了問(wèn)題械媒。
亮點(diǎn)：雖然本文描述和解決的不是罕見(jiàn)的疑難雜癥，但排查思路清晰评汰，過(guò)程完整滥沫，還推薦了排查工具侣集，適合新手閱讀學(xué)習(xí)键俱。
2.一次容器化springboot程序OOM問(wèn)題探險(xiǎn)
作者：俠夢(mèng)
一次容器化springboot程序OOM問(wèn)題探險(xiǎn) | HeapDump性能社區(qū)
概述：作者被告知一個(gè)容器化的java程序每跑一段時(shí)間就會(huì)出現(xiàn)OOM問(wèn)題兰绣，首先查日志并未發(fā)現(xiàn)異常；然后通過(guò)JStat查看GC情況编振，發(fā)現(xiàn)GC情況正常但ByteBuffer對(duì)象占用最高（異常點(diǎn)1）缀辩；接著通過(guò)JStack查看線程快照情況，發(fā)現(xiàn)創(chuàng)建了過(guò)多kafka生產(chǎn)者（異常點(diǎn)2）踪央；最后通過(guò)編寫(xiě)Demo程序驗(yàn)證猜想臀玄，確定問(wèn)題是業(yè)務(wù)代碼中循環(huán)創(chuàng)建Producer對(duì)象導(dǎo)致的。
亮點(diǎn)：排查過(guò)程清晰明了畅蹂，工具使用嫻熟健无，驗(yàn)證過(guò)程快速準(zhǔn)確。
3.一次百萬(wàn)長(zhǎng)連接壓測(cè) Nginx OOM 的問(wèn)題排查分析
作者：挖坑的張師傅
一次百萬(wàn)長(zhǎng)連接壓測(cè) Nginx OOM 的問(wèn)題排查分析
概述：
作者在一次百萬(wàn)長(zhǎng)連接壓測(cè)中液斜，發(fā)現(xiàn)32C 128G的四臺(tái)Nginx頻繁出現(xiàn)OOM累贤。發(fā)現(xiàn)問(wèn)題后首先查看了 Nginx 和客戶端兩端的網(wǎng)絡(luò)連接狀態(tài)，首先懷疑是jmeter客戶端處理能力有限少漆，有較多消息堆積在中轉(zhuǎn)的Nginx處臼膏，于是dump了nginx的內(nèi)存查看，堅(jiān)定了是因?yàn)榫彺媪舜罅康南?dǎo)致的內(nèi)存上漲示损；隨后查看了 Nginx 的參數(shù)配置渗磅，發(fā)現(xiàn)proxy_buffers 這個(gè)值設(shè)置的特別大；然后模擬了upstream 上下游收發(fā)速度不一致對(duì)Nginx內(nèi)存占用的影響检访。最后將proxy_buffering 設(shè)置為 off并調(diào)小了 proxy_buffer_size 的值以后始鱼，Nginx的內(nèi)存穩(wěn)定了。
亮點(diǎn)：作者排查思路清晰脆贵，工具使用医清、參數(shù)調(diào)節(jié)十分嫻熟，對(duì)底層原理和源碼理解深刻丹禀，無(wú)論是經(jīng)驗(yàn)還是態(tài)度都十分值得學(xué)習(xí)參考状勤。
