點擊上方?好好學(xué)java?，選擇?星標(biāo)?公眾號

重磅資訊、干貨，第一時間送達

今日推薦：Nginx 為什么快到根本停不下來？

個人原創(chuàng)100W+訪問量博客：點擊前往，查看更多

來源：blog.csdn.net/prestigeding/article/details/89075661

• 分析思路：

• • 如何快速恢復(fù)業(yè)務(wù)

  • 分析解決問題

  • 收集內(nèi)存溢出Dump文件

  • 分析Dump文件

如果我們所在公司的業(yè)務(wù)量比較大，在生產(chǎn)環(huán)境經(jīng)常會出現(xiàn)JVM內(nèi)存溢出的現(xiàn)象，那我們該如何快速響應(yīng)，快速定位，快速恢復(fù)問題呢？

本文將通過一個線上環(huán)境JVM內(nèi)存溢出的案例向大家介紹一下處理思路與分析方法。

案例：架構(gòu)組接到某項目組反饋，Zabbix監(jiān)控上顯示JMX不可用，請求協(xié)助處理。

分析思路：

• JMX不可用，往往是由于垃圾回收時間停頓時間過長、內(nèi)存溢出等問題引起的。

• 線上故障分析的原則是首先要采取措施快速恢復(fù)故障對業(yè)務(wù)的影響，然后才是采集信息、分析定位問題，并最終給出解決辦法。

具體分析過程如下。

1

快速恢復(fù)業(yè)務(wù)

通常線上的故障會對業(yè)務(wù)造成重大影響，影響用戶體驗，故如果線上服務(wù)器出現(xiàn)故障，應(yīng)規(guī)避對業(yè)務(wù)造成影響，但不能簡單的重啟服務(wù)器，因為需要盡可能保留現(xiàn)場，為后續(xù)的問題分析打下基礎(chǔ)。

那我們?nèi)绾慰焖僖?guī)避對業(yè)務(wù)的影響，并能保留現(xiàn)場呢？

通常的做法是隔離故障服務(wù)器。

通常線上服務(wù)器是集群部署，一個好的分布式負(fù)載方案會自動剔除故障的機器，從而實現(xiàn)高可用架構(gòu)，但如果未被剔除，則需要運維人員將故障服務(wù)器進行剔除，保留現(xiàn)場進行分析。

發(fā)生內(nèi)存泄露，通常情況下是由于代碼的原因造成的，一般無法立即對代碼進行修復(fù)，很容易會發(fā)送連鎖反應(yīng)造成應(yīng)用服務(wù)器一臺一臺接連宕機，故障面積會慢慢擴大，針對此種情況，應(yīng)快速定位發(fā)生內(nèi)存泄露的原因，將該服務(wù)進行降級，避免對其他服務(wù)造成影響。最簡單的降級方法是根據(jù)F5(Nginx)轉(zhuǎn)發(fā)策略，對該功能定向到一個單獨的集群，與其他流量進行隔離，確保其他業(yè)務(wù)不受牽連，給故障排查、解決提供寶貴的緩沖時間。

2

分析解決問題

首先可以通過查看日志，確定是哪種內(nèi)存溢出，堆內(nèi)存溢出可發(fā)生的地方：Java heap space(堆空間)、perm space(持久代)。

收集內(nèi)存溢出Dump文件

收集Dump文件有兩種方式：

• 設(shè)置JVM啟動參數(shù)
  -XX:+HeapDumpOnOutOfMemoryError
  -XX:HeapDumpPath=/opt/jvmdump

在每次發(fā)生內(nèi)存溢出時，JVM會自動將堆轉(zhuǎn)儲，dump文件存放在-XX:HeapDumpPath指定的路徑下。

• 使用jmap命令收集
  通過jmap -dump:live,format=b,file=/opt/jvm/dump.hprof pid。

分析Dump文件

在獲取Dump文件后，可以使用工具MAT(MemoryAnalyzer)進行分析，該工具大家可以通過百度自行下載。

使用MAT打開Dump文件后，首頁截圖如下：

工具按鈕介紹：

：直方圖視圖，將堆中所有的內(nèi)存消耗情況統(tǒng)計出來，其如圖所示：

：內(nèi)存使用樹狀結(jié)構(gòu)，以線程為維度，樹狀形式展開，如圖所示：

線程棧，其截圖如下：

根據(jù)該圖，可以明確，堆的總大小為1.9G，被4個線程全部占據(jù)，導(dǎo)致其他線程無法再申請資源，拋出堆內(nèi)存溢出錯誤。

接下來，我通常的做法是直接去看這個視圖(以線程為基本維度，查找線程中占用內(nèi)存的對象)，為后續(xù)定位排查提供必要的依據(jù)。

從上面的截圖中可以得出如下關(guān)鍵信息點：

• org.apache.ibatis.executor.result.DefaultResultHandler內(nèi)部持有一個List，其原始為java.util.HashMap，從這個類基本可以看出是與數(shù)據(jù)庫的查詢相關(guān)，對數(shù)據(jù)庫返回結(jié)果的解碼并組織成HashMap。

• 這個List中的元素總共有146033個，初步可以判斷出是在一次查詢中從數(shù)據(jù)庫中一次查詢出了太多數(shù)據(jù)，造成了內(nèi)存溢出。

由于SQL查詢代碼中，是用HashMap來接收數(shù)據(jù)庫中的返回字段，無法一時間看出是那個查詢，那我們能不能精確找到是哪一個查詢，哪一行代碼，甚至與哪一條SQL語句呢？

答案是可以的，我們可以從視圖一探究竟。

溫馨提示：
視圖使用技巧：展開技巧：沿著使用率最高的項一層一層進行展開，直至發(fā)現(xiàn)具體占用內(nèi)存的對象。

接下來我們從 視圖去尋找是哪個方法，哪條SQL語句觸發(fā)的。
具體方法：首先完全展開一個線程，從展開圖的底部向上尋找：
其線程的入口(控制層代碼)

繼續(xù)往上查找，要找到SQL語句，應(yīng)該找到Mybatis處理結(jié)果集相關(guān)的類，如圖所示：

然后展開boundSql即能找到SQL語句：

然后鼠標(biāo)可以放在SQL屬性中，右鍵，可以將SQL語句復(fù)制出來。

由于這里涉及到公司的代碼機密，故在這里不貼出具體的SQL語句。

這里根據(jù)后面的分析，原來是在做導(dǎo)出功能的時候，沒有使用分頁對數(shù)據(jù)進行分頁查詢，分頁寫入Excel文件，而是一次將全部數(shù)據(jù)查詢，導(dǎo)致導(dǎo)出功能如果并發(fā)數(shù)超過4個時，就會將所有內(nèi)存耗盡。

解決方案：

• 首先在運維層面將該請求導(dǎo)入到指定的一臺服務(wù)器上，是導(dǎo)出任務(wù)與其他任務(wù)進行隔離，避免對其他重要服務(wù)造成影響。

• 項目組對其代碼進行修復(fù)，可以使用分頁查數(shù)據(jù)，然后分配寫入Excel。

最后，再附上我歷時三個月總結(jié)的?Java 面試 + Java 后端技術(shù)學(xué)習(xí)指南，筆者這幾年及春招的總結(jié)，github 1.4k star，拿去不謝！下載方式1.?首先掃描下方二維碼 2.?后臺回復(fù)「Java面試」即可獲取

總結(jié)

以上是生活随笔為你收集整理的生产环境JVM内存溢出案例分析！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。