記憶體溢位與記憶體洩露的區別與聯絡，如何檢測、解決
阿新 • • 發佈：2018-11-15
記憶體溢位 out of memory，是指程式在申請記憶體時，沒有足夠的記憶體空間供其使用，出現out of memory；比如申請了一個integer,但給它存了long才能存下的數，那就是記憶體溢位
記憶體洩露 memory leak，是指程式在申請記憶體後，無法釋放已申請的記憶體空間，一次記憶體洩露危害可以忽略，但記憶體洩露堆積後果很嚴重，無論多少記憶體,遲早會被佔光 memory leak會最終會導致out of memory！
因為： 記憶體溢位就是你要求分配的記憶體超出了系統能給你的，系統不能滿足需求，於是產生溢位。 比方說棧，棧滿時再做進棧必定產生空間溢位，叫上溢，棧空時再做退棧也產生空間溢位，稱為下溢。
記憶體洩漏是指你向系統申請分配記憶體進行使用(new)，可是使用完了以後卻不歸還(delete)，結果你申請到的那塊記憶體你自己也不能再訪問（也許你把它的地址給弄丟了），而系統也不能再次將它分配給需要的程式。
記憶體洩露分類： 1. 常發性記憶體洩漏。發生記憶體洩漏的程式碼會被多次執行到，每次被執行的時候都會導致一塊記憶體洩漏。 2. 偶發性記憶體洩漏。發生記憶體洩漏的程式碼只有在某些特定環境或操作過程下才會發生。常發性和偶發性是相對的。對於特定的環境，偶發性的也許就變成了常發性的。所以測試環境和測試方法對檢測記憶體洩漏至關重要。
3. 一次性記憶體洩漏。
4. 隱式記憶體洩漏。程式在執行過程中不停的分配記憶體，但是直到結束的時候才釋放記憶體。嚴格的說這裡並沒有發生記憶體洩漏，因為最終程式釋放了所有申請的記憶體。但是對於一個伺服器程式，需要執行幾天，幾周甚至幾個月，不及時釋放記憶體也可能導致最終耗盡系統的所有記憶體。所以，我們稱這類記憶體洩漏為隱式記憶體洩漏。
從使用者使用程式的角度來看，記憶體洩漏本身不會產生什麼危害，作為一般的使用者，根本感覺不到記憶體洩漏的存在。真正有危害的是記憶體洩漏的堆積，這會最終消耗盡系統所有的記憶體。
檢測方式： 在大多數情況下，一個OutOfMemoryError是記憶體洩漏的標誌。一個解決辦法就是繼續監聽GC的活動，看看隨時間的流逝，記憶體使用量是否會增加，如果有，程式中一定存在記憶體洩漏
定位記憶體洩漏問題我一般使用如下命令： Jstat -gcutil15469 2500 70 檢視 FGC — 從應用程式啟動到取樣時發生 Full GC 的次數 如果有大量的FGC就要查詢是否有記憶體洩漏的問題了
記憶體溢位的原因以及解決方法
引起記憶體溢位的原因有很多種，小編列舉一下常見的有以下幾種：
1.記憶體中載入的資料量過於龐大，如一次從資料庫取出過多資料；
2.集合類中有對物件的引用，使用完後未清空，使得JVM不能回收；
3.程式碼中存在死迴圈或迴圈產生過多重複的物件實體；
4.使用的第三方軟體中的BUG； 5.啟動引數記憶體值設定的過小
記憶體溢位的解決方案：
第一步，修改JVM啟動引數，直接增加記憶體。(-Xms，-Xmx引數一定不要忘記加。)
第二步，檢查錯誤日誌，檢視“OutOfMemory”錯誤前是否有其它異常或錯誤。
第三步，對程式碼進行走查和分析，找出可能發生記憶體溢位的位置。
重點排查以下幾點：
1.檢查對資料庫查詢中，是否有一次獲得全部資料的查詢。一般來說，如果一次取十萬條記錄到記憶體，就可能引起記憶體溢位。這個問題比較隱蔽，在上線前，資料庫中資料較少，不容易出問題，上線後，資料庫中資料多了，一次查詢就有可能引起記憶體溢位。因此對於資料庫查詢儘量採用分頁的方式查詢。
2.檢查程式碼中是否有死迴圈或遞迴呼叫。
3.檢查是否有大迴圈重複產生新物件實體。
4.檢查對資料庫查詢中，是否有一次獲得全部資料的查詢。一般來說，如果一次取十萬條記錄到記憶體，就可能引起記憶體溢位。這個問題比較隱蔽，在上線前，資料庫中資料較少，不容易出問題，上線後，資料庫中資料多了，一次查詢就有可能引起記憶體溢位。因此對於資料庫查詢儘量採用分頁的方式查詢。
5.檢查List、MAP等集合物件是否有使用完後，未清除的問題。List、MAP等集合物件會始終存有對物件的引用，使得這些物件不能被GC回收。
第四步，使用記憶體檢視工具動態檢視記憶體使用情況
記憶體洩露 memory leak，是指程式在申請記憶體後，無法釋放已申請的記憶體空間，一次記憶體洩露危害可以忽略，但記憶體洩露堆積後果很嚴重，無論多少記憶體,遲早會被佔光 memory leak會最終會導致out of memory！
因為： 記憶體溢位就是你要求分配的記憶體超出了系統能給你的，系統不能滿足需求，於是產生溢位。 比方說棧，棧滿時再做進棧必定產生空間溢位，叫上溢，棧空時再做退棧也產生空間溢位，稱為下溢。
記憶體洩漏是指你向系統申請分配記憶體進行使用(new)，可是使用完了以後卻不歸還(delete)，結果你申請到的那塊記憶體你自己也不能再訪問（也許你把它的地址給弄丟了），而系統也不能再次將它分配給需要的程式。
記憶體洩露分類： 1. 常發性記憶體洩漏。發生記憶體洩漏的程式碼會被多次執行到，每次被執行的時候都會導致一塊記憶體洩漏。 2. 偶發性記憶體洩漏。發生記憶體洩漏的程式碼只有在某些特定環境或操作過程下才會發生。常發性和偶發性是相對的。對於特定的環境，偶發性的也許就變成了常發性的。所以測試環境和測試方法對檢測記憶體洩漏至關重要。
3. 一次性記憶體洩漏。
4. 隱式記憶體洩漏。程式在執行過程中不停的分配記憶體，但是直到結束的時候才釋放記憶體。嚴格的說這裡並沒有發生記憶體洩漏，因為最終程式釋放了所有申請的記憶體。但是對於一個伺服器程式，需要執行幾天，幾周甚至幾個月，不及時釋放記憶體也可能導致最終耗盡系統的所有記憶體。所以，我們稱這類記憶體洩漏為隱式記憶體洩漏。
從使用者使用程式的角度來看，記憶體洩漏本身不會產生什麼危害，作為一般的使用者，根本感覺不到記憶體洩漏的存在。真正有危害的是記憶體洩漏的堆積，這會最終消耗盡系統所有的記憶體。
檢測方式： 在大多數情況下，一個OutOfMemoryError是記憶體洩漏的標誌。一個解決辦法就是繼續監聽GC的活動，看看隨時間的流逝，記憶體使用量是否會增加，如果有，程式中一定存在記憶體洩漏
定位記憶體洩漏問題我一般使用如下命令： Jstat -gcutil15469 2500 70 檢視 FGC — 從應用程式啟動到取樣時發生 Full GC 的次數 如果有大量的FGC就要查詢是否有記憶體洩漏的問題了
記憶體溢位的原因以及解決方法
引起記憶體溢位的原因有很多種，小編列舉一下常見的有以下幾種：
1.記憶體中載入的資料量過於龐大，如一次從資料庫取出過多資料；
2.集合類中有對物件的引用，使用完後未清空，使得JVM不能回收；
3.程式碼中存在死迴圈或迴圈產生過多重複的物件實體；
4.使用的第三方軟體中的BUG； 5.啟動引數記憶體值設定的過小
記憶體溢位的解決方案：
第一步，修改JVM啟動引數，直接增加記憶體。(-Xms，-Xmx引數一定不要忘記加。)
第二步，檢查錯誤日誌，檢視“OutOfMemory”錯誤前是否有其它異常或錯誤。
第三步，對程式碼進行走查和分析，找出可能發生記憶體溢位的位置。
重點排查以下幾點：
1.檢查對資料庫查詢中，是否有一次獲得全部資料的查詢。一般來說，如果一次取十萬條記錄到記憶體，就可能引起記憶體溢位。這個問題比較隱蔽，在上線前，資料庫中資料較少，不容易出問題，上線後，資料庫中資料多了，一次查詢就有可能引起記憶體溢位。因此對於資料庫查詢儘量採用分頁的方式查詢。
2.檢查程式碼中是否有死迴圈或遞迴呼叫。
3.檢查是否有大迴圈重複產生新物件實體。
4.檢查對資料庫查詢中，是否有一次獲得全部資料的查詢。一般來說，如果一次取十萬條記錄到記憶體，就可能引起記憶體溢位。這個問題比較隱蔽，在上線前，資料庫中資料較少，不容易出問題，上線後，資料庫中資料多了，一次查詢就有可能引起記憶體溢位。因此對於資料庫查詢儘量採用分頁的方式查詢。
5.檢查List、MAP等集合物件是否有使用完後，未清除的問題。List、MAP等集合物件會始終存有對物件的引用，使得這些物件不能被GC回收。
第四步，使用記憶體檢視工具動態檢視記憶體使用情況