內(nèi)存泄漏memory leak :

是指程序在申請內(nèi)存后，無法釋放已申請的內(nèi)存空間，一次內(nèi)存泄漏似乎不會有大的影響，但內(nèi)存泄漏堆積后的后果就是內(nèi)存溢出

內(nèi)存溢出 out of memory :

指程序申請內(nèi)存時，沒有足夠的內(nèi)存供申請者使用，或者說，給了你一塊存儲int類型數(shù)據(jù)的存儲空間，但是你卻存儲long類型的數(shù)據(jù)，那么結(jié)果就是內(nèi)存不夠用，此時就會報錯OOM,即所謂的內(nèi)存溢出。

二者的關(guān)系：

1.內(nèi)存泄漏的堆積最終會導(dǎo)致內(nèi)存溢出
2.內(nèi)存溢出就是你要的內(nèi)存空間超過了系統(tǒng)實際分配給你的空間，此時系統(tǒng)相當(dāng)于沒法滿足你的需求，就會報內(nèi)存溢出的錯誤。
3.內(nèi)存泄漏是指你向系統(tǒng)申請分配內(nèi)存進(jìn)行使用(new)，可是使用完了以后卻不歸還(delete)，結(jié)果你申請到的那塊內(nèi)存你自己也不能再訪問（也許你把它的地址給弄丟了），而系統(tǒng)也不能再次將它分配給需要的程序。就相當(dāng)于你租了個帶鑰匙的柜子，你存完東西之后把柜子鎖上之后，把鑰匙丟了或者沒有將鑰匙還回去，那么結(jié)果就是這個柜子將無法供給任何人使用，也無法被垃圾回收器回收，因為找不到他的任何信息。
4.內(nèi)存溢出：一個盤子用盡各種方法只能裝4個果子，你裝了5個，結(jié)果掉倒地上不能吃了。這就是溢出。比方說棧，棧滿時再做進(jìn)棧必定產(chǎn)生空間溢出，叫上溢，?？諘r再做退棧也產(chǎn)生空間溢出，稱為下溢。就是分配的內(nèi)存不足以放下數(shù)據(jù)項序列,稱為內(nèi)存溢出。說白了就是我承受不了那么多，那我就報錯。

內(nèi)存泄漏的分類（按發(fā)生方式來分類）

1.常發(fā)性內(nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼會被多次執(zhí)行到，每次被執(zhí)行的時候都會導(dǎo)致一塊內(nèi)存泄漏。
偶發(fā)性內(nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼只有在某些特定環(huán)境或操作過程下才會發(fā)生。常發(fā)性和偶發(fā)性是相對的。對于特定的環(huán)境，偶發(fā)性的也許就變成了常發(fā)性的。所以測試環(huán)境和測試方法對檢測內(nèi)存泄漏至關(guān)重要。
2.一次性內(nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼只會被執(zhí)行一次，或者由于算法上的缺陷，導(dǎo)致總會有一塊僅且一塊內(nèi)存發(fā)生泄漏。比如，在類的構(gòu)造函數(shù)中分配內(nèi)存，在析構(gòu)函數(shù)中卻沒有釋放該內(nèi)存，所以內(nèi)存泄漏只會發(fā)生一次。
3.隱式內(nèi)存泄漏。程序在運行過程中不停的分配內(nèi)存，但是直到結(jié)束的時候才釋放內(nèi)存。嚴(yán)格的說這里并沒有發(fā)生內(nèi)存泄漏，因為最終程序釋放了所有申請的內(nèi)存。但是對于一個服務(wù)器程序，需要運行幾天，幾周甚至幾個月，不及時釋放內(nèi)存也可能導(dǎo)致最終耗盡系統(tǒng)的所有內(nèi)存。所以，我們稱這類內(nèi)存泄漏為隱式內(nèi)存泄漏。

內(nèi)存溢出的原因及解決方法：

• 內(nèi)存溢出原因：

1.內(nèi)存中加載的數(shù)據(jù)量過于龐大，如一次從數(shù)據(jù)庫取出過多數(shù)據(jù)；
2.集合類中有對對象的引用，使用完后未清空，使得JVM不能回收；
3.代碼中存在死循環(huán)或循環(huán)產(chǎn)生過多重復(fù)的對象實體；
4.使用的第三方軟件中的BUG；
5.啟動參數(shù)內(nèi)存值設(shè)定的過小

• 內(nèi)存溢出的解決方案：

第一步，修改JVM啟動參數(shù)，直接增加內(nèi)存。(-Xms，-Xmx參數(shù)一定不要忘記加。)
第二步，檢查錯誤日志，查看“OutOfMemory”錯誤前是否有其 它異?；蝈e誤。
第三步，對代碼進(jìn)行走查和分析，找出可能發(fā)生內(nèi)存溢出的位置。
重點排查以下幾點：
1.檢查對數(shù)據(jù)庫查詢中，是否有一次獲得全部數(shù)據(jù)的查詢。一般來說，如果一次取十萬條記錄到內(nèi)存，就可能引起內(nèi)存溢出。這個問題比較隱蔽，在上線前，數(shù)據(jù)庫中數(shù)據(jù)較少，不容易出問題，上線后，數(shù)據(jù)庫中數(shù)據(jù)多了，一次查詢就有可能引起內(nèi)存溢出。因此對于數(shù)據(jù)庫查詢盡量采用分頁的方式查詢。
2.檢查代碼中是否有死循環(huán)或遞歸調(diào)用。
3.檢查是否有大循環(huán)重復(fù)產(chǎn)生新對象實體。
4.檢查對數(shù)據(jù)庫查詢中，是否有一次獲得全部數(shù)據(jù)的查詢。一般來說，如果一次取十萬條記錄到內(nèi)存，就可能引起內(nèi)存溢出。這個問題比較隱蔽，在上線前，數(shù)據(jù)庫中數(shù)據(jù)較少，不容易出問題，上線后，數(shù)據(jù)庫中數(shù)據(jù)多了，一次查詢就有可能引起內(nèi)存溢出。因此對于數(shù)據(jù)庫查詢盡量采用分頁的方式查詢。
5.檢查List、MAP等集合對象是否有使用完后，未清除的問題。List、MAP等集合對象會始終存有對對象的引用，使得這些對象不能被GC回收。
第四步，使用內(nèi)存查看工具動態(tài)查看內(nèi)存使用情況

其他的一些參考

由于java的JVM引入了垃圾回收機制，垃圾回收器會自動回收不再使用的對象，了解JVM回收機制的都知道JVM是使用引用計數(shù)法和可達(dá)性分析算法來判斷對象是否是不再使用的對象，本質(zhì)都是判斷一個對象是否還被引用。那么對于這種情況下，由于代碼的實現(xiàn)不同就會出現(xiàn)很多種內(nèi)存泄漏問題（讓JVM誤以為此對象還在引用中，無法回收，造成內(nèi)存泄漏）。

1、靜態(tài)集合類，如HashMap、LinkedList等等。如果這些容器為靜態(tài)的，那么它們的生命周期與程序一致，則容器中的對象在程序結(jié)束之前將不能被釋放，從而造成內(nèi)存泄漏。簡單而言，長生命周期的對象持有短生命周期對象的引用，盡管短生命周期的對象不再使用，但是因為長生命周期對象持有它的引用而導(dǎo)致不能被回收。

2、各種連接，如數(shù)據(jù)庫連接、網(wǎng)絡(luò)連接和IO連接等。在對數(shù)據(jù)庫進(jìn)行操作的過程中，首先需要建立與數(shù)據(jù)庫的連接，當(dāng)不再使用時，需要調(diào)用close方法來釋放與數(shù)據(jù)庫的連接。只有連接被關(guān)閉后，垃圾回收器才會回收對應(yīng)的對象。否則，如果在訪問數(shù)據(jù)庫的過程中，對Connection、Statement或ResultSet不顯性地關(guān)閉，將會造成大量的對象無法被回收，從而引起內(nèi)存泄漏。

3、變量不合理的作用域。一般而言，一個變量的定義的作用范圍大于其使用范圍，很有可能會造成內(nèi)存泄漏。另一方面，如果沒有及時地把對象設(shè)置為null，很有可能導(dǎo)致內(nèi)存泄漏的發(fā)生。
如上面這個偽代碼，通過readFromNet方法把接受的消息保存在變量msg中，然后調(diào)用saveDB方法把msg的內(nèi)容保存到數(shù)據(jù)庫中，此時msg已經(jīng)就沒用了，由于msg的生命周期與對象的生命周期相同，此時msg還不能回收，因此造成了內(nèi)存泄漏。

實際上這個msg變量可以放在receiveMsg方法內(nèi)部，當(dāng)方法使用完，那么msg的生命周期也就結(jié)束，此時就可以回收了。還有一種方法，在使用完msg后，把msg設(shè)置為null，這樣垃圾回收器也會回收msg的內(nèi)存空間。

4、內(nèi)部類持有外部類，如果一個外部類的實例對象的方法返回了一個內(nèi)部類的實例對象，這個內(nèi)部類對象被長期引用了，即使那個外部類實例對象不再被使用，但由于內(nèi)部類持有外部類的實例對象，這個外部類對象將不會被垃圾回收，這也會造成內(nèi)存泄露。

5、改變哈希值，當(dāng)一個對象被存儲進(jìn)HashSet集合中以后，就不能修改這個對象中的那些參與計算哈希值的字段了，否則，對象修改后的哈希值與最初存儲進(jìn)HashSet集合中時的哈希值就不同了，在這種情況下，即使在contains方法使用該對象的當(dāng)前引用作為的參數(shù)去HashSet集合中檢索對象，也將返回找不到對象的結(jié)果，這也會導(dǎo)致無法從HashSet集合中單獨刪除當(dāng)前對象，造成內(nèi)存泄露