點擊上方?好好學java?，選擇?星標?公眾號

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

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

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

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

• 分析思路：

• • 如何快速恢復業務

  • 分析解決問題

  • 收集內存溢出Dump文件

  • 分析Dump文件

如果我們所在公司的業務量比較大，在生產環境經常會出現JVM內存溢出的現象，那我們該如何快速響應，快速定位，快速恢復問題呢？

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

案例：架構組接到某項目組反饋，Zabbix監控上顯示JMX不可用，請求協助處理。

分析思路：

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

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

具體分析過程如下。

1

快速恢復業務

通常線上的故障會對業務造成重大影響，影響用戶體驗，故如果線上服務器出現故障，應規避對業務造成影響，但不能簡單的重啟服務器，因為需要盡可能保留現場，為后續的問題分析打下基礎。

那我們如何快速規避對業務的影響，并能保留現場呢？

通常的做法是隔離故障服務器。

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

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

2

分析解決問題

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

收集內存溢出Dump文件

收集Dump文件有兩種方式：

• 設置JVM啟動參數
  -XX:+HeapDumpOnOutOfMemoryError
  -XX:HeapDumpPath=/opt/jvmdump

在每次發生內存溢出時，JVM會自動將堆轉儲，dump文件存放在-XX:HeapDumpPath指定的路徑下。

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

分析Dump文件

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

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

工具按鈕介紹：

：直方圖視圖，將堆中所有的內存消耗情況統計出來，其如圖所示：

：內存使用樹狀結構，以線程為維度，樹狀形式展開，如圖所示：

線程棧，其截圖如下：

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

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

從上面的截圖中可以得出如下關鍵信息點：

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

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

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

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

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

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

繼續往上查找，要找到SQL語句，應該找到Mybatis處理結果集相關的類，如圖所示：

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

然后鼠標可以放在SQL屬性中，右鍵，可以將SQL語句復制出來。

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

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

解決方案：

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

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。