喧譁的夜滿地銀光。望向窗外， 星的眨眼頻率格外的高，低眼看泛著油光的鍵盤，心中的寂寞。。。

滴滴，靠著每天【ctrl+alt+w】幾千+的慣性，開啟最【嘿嘿嘿】的聊天軟體，心中不免惆悵，已過午時三刻，還tm不下班。

惆 惆啥？油光的臉瞬間露出一縷微笑，惺忪的眼也充滿了血絲,活來啦！！！我看見bug在向我招手，大爺來玩呀，來吧來吧。。。刻不容緩。

那麼：問題來了， 一點自己寫的程式碼的資訊沒有，怎麼找？相信這是大多數兄弟遇到記憶體問題的第一反應

錯誤資訊是我朋友發給我的截圖，我並沒有他的程式碼，也不清楚專案的業務，更不知道為什麼會OutOfMemory，懵逼中

開始搞事情

首先：理清思路

1. 發現問題

2. 分析問題

3. 解決問題

首先梳理一下思路：

• OutOfMemory，記憶體溢位， 是的，溢位了，什麼問題導致的呢，是不是程式的記憶體給的不夠引起的呢。

  隨即，我問了我的朋友程式啟動指定記憶體沒有？如果沒有的話制定以下記憶體會不會解決問題呢

  -Xms512m -Xmx2048m

  回覆：啟動成功後，朋友測試了一下還真的好了( •̀ ω •́ )y，真開心
  

• 你以為到這就結束了嗎？那未免也太積薄水了吧
  

  (●’◡’●)： 不行呀，兄弟， 我訪問沒問題了，給我們老闆訪問就不行了，還是java.lang.OutOfMemoryError: Java heap space，是不是我們老闆有毒呀，我是不是考慮要換一個公司呀。

  /(ㄒoㄒ)/： 兄弟，我認真的思考了一下。不瞞你說,我感覺你們老闆沒有那麼簡單，最起碼也得會個氣功什麼的，你以後要小心呀！！！（重要的事情三個感嘆號）
  (●’◡’●)：葵花寶典我已經看完前言了，我離成功就差那麼零點零一毫米了，但是現在tmd記憶體溢位了我腫麼辦！
  /(ㄒoㄒ)/：兄弟莫著急，你用OutOfMemoryError神器jvisualvm看一下記憶體情況
  (●’◡’●)：那是什麼玩意，玉女心經裡的麼？md我還沒看到那呢
  。。。。。。。。。。。。。。。。。。。
  一番神講解下終於開啟jvisualvm查看了記憶體情況。。。
  該工具位於jdk安裝目錄下bin目錄下，是jdk自帶分析工具，功能非常強大
  開啟該nb工具後的樣子是這樣的
  

  
  沒聽過的的兄弟請點此處查閱後繼續檢視本文章

1. 發現問題

兄弟一看，情況不對呀，儘管分配了記憶體，但是記憶體還是會溢位
經過一下系列分析（分析詳細過程）：

okokok 接下來，就是見證奇蹟的時刻，lets go
1. 這位兄弟告訴我，啟動程式沒問題，一訪問就出問題，ok，（重點，要劃線）
既然啟動沒問題，那你把啟動的時候的記憶體分佈情況與第一次訪問的時候的記憶體情況發給我。
如下圖片是第一次啟動程式的情況

其實很多資訊都很明瞭了，啟動程式的分配的堆記憶體大小、程式所佔用的堆記憶體大小，暫時看起來是沒什麼毛病，記憶體的大小並沒有什麼異常的情況，而且此時並沒有發聲記憶體溢位的異常。

但是，沒有問題怎麼會出異常呢，表開心的太找，下面這張圖片是沒有為程式啟動的時候分配記憶體，並且發起了一次請求後的記憶體情況。

最大記憶體瞬間暴漲好幾倍，而且程式同時丟擲如下異常

嗯，問題出來了

要解決的就是你，此時，問題bug已經重現，問題發現，第一關完美通關！！！

2. 分析問題

好的女王大人

前面說了這麼多（扯。蛋。），但是，問題就是這麼個問題，記憶體溢位，ok下面就是真正的展現技術的時刻了，你們給我坐正咯

記憶體出現溢位後，我讓這位朋友分配了一下啟動的最大記憶體與最小記憶體

既然問題已經出來了，那就用jvisualvm分析一下記憶體把，第一次請求出現的問題是記憶體暴漲，既然是記憶體問題，那麼我們就對症下藥，分析記憶體。

點選上圖堆dump按鈕進行堆記憶體分析，點選後如下所示

點選類後檢視物件的記憶體佔比情況如下，點選大小按鈕進行記憶體佔比大小排序

找到這個可恨的特務了，就是你，害的我兄弟被領導大問號臉，哼

3. 解決問題

繼續跟蹤這個物件，看丫的到底是個什麼東西，有必要搞他一搞。

右擊該物件，點選在例項檢視中顯示按鈕，跳轉如下頁面

跟蹤物件發現，名字竟然是一個叫做headerbuffer的東西，看名字，可能是一個request請求的header的緩衝區，佔了400多m，一個request的請求頭，你佔了400多m，臉呢？

問題找到了，一個request的請求頭佔了四百兆，後續根據這個結果發現，為這個程式分配了兩個g的最大記憶體之後，每次請求都會生成400m的該byte陣列，接下來就定位到了請求的身上。

問題找到了，接下來就該看程式碼了，程式碼是這位兄弟寫的，我就不方便隨便貼人家的程式碼了，我先讓這位兄弟檢查一下程式碼，這個介面上做沒做什麼特殊處理，攔截器、過濾器、所有跟request請求相關的配置，都檢查一遍，最後在springboot的配置檔案中發現瞭如下配置：

這簡直就是自己挖坑給自己跳呀，具體配置說明兄弟就不再解釋了

滿腦子黑人問號不再多bb了，咱們在這不多討論該兄弟為什麼這麼寫

jvisualvm、 jprofile真的是一個記憶體優化、排查問題的一個好工具，java們早晚會用到它，jprofile教程網上並不少，但是講的好的並沒有幾個。重要的還是要自己去熟悉，去理解。

該篇文章僅作為記憶體溢位的一個解決思路

另提醒各位程式朋友們，可能做不到每一行程式碼都能刨根問底知道底層是怎麼實現、什麼原理，但是儘量知道你寫或copy的每一行程式碼什麼意思，影響有多大。