內存溢出（out of memory）通俗理解就是內存不夠，通常在運行大型軟件或遊戲時，軟件或遊戲所需要的內存遠遠超出了你主機內安裝的內存所承受大小，就叫內存溢出。此時軟件或遊戲就運行不了，系統會提示內存溢出，有時候會自動關閉軟件，重啟電腦或者軟件後釋放掉一部分內存又可以正常運行該軟件。

內存溢出已經是軟件開發歷史上存在了近40年的“老大難”問題，像在“紅色代碼”病毒事件中表現的那樣，它已經成為黑客攻擊企業網絡的“罪魁禍首”。 如在一個域中輸入的數據超過了它的要求就會引發數據溢出問題，多余的數據就可以作為指令在計算機上運行。

據有關安全小組稱，操作系統中超過50%的安全漏洞都是由內存溢出引起的，其中大多數與

緩沖區溢出好比是將十磅的糖放進一個只能裝五磅的容器裏。一旦該容器放滿了，余下的部分就溢出在櫃臺和地板上，弄得一團糟。由於計算機程序的編寫者寫了一些編碼，但是這些編碼沒有對目的區域或緩沖區——五磅的容器——做適當的檢查，看它們是否夠大，能否完全裝入新的內容——十磅的糖，結果可能造成緩沖區溢出的產生。如果打算被放進新地方的數據不適合，溢得到處都是，該數據也會制造很多麻煩。但是，如果緩沖區僅僅溢出，這只是一個問題。到此時為止，它還沒有破壞性。當糖溢出時，櫃臺被蓋住。可以把糖擦掉或用吸塵器吸走，還櫃臺本來面貌。與之相對的是，當緩沖區溢出時，過剩的信息覆蓋的是計算機內存中以前的內容。除非這些被覆蓋的內容被保存或能夠恢復，否則就會永遠丟失

解決方法

第一步，就是修改JVM啟動參數，直接增加內存。

這一點看上去似乎很簡單，但很容易被忽略。JVM默認可以使用的內存為64M，Tomcat默認可以使用的內存為128MB，對於稍復雜一點的系統就會不夠用。在某項目中，就因為啟動參數使用的默認值，經常報“OutOfMemory”錯誤。因此，-Xms，-Xmx參數一定不要忘記加。

第二步，檢查錯誤日誌，查看“OutOfMemory”錯誤前是否有其它異常或錯誤。

在一個項目中，使用兩個數據庫連接，其中專用於發送短信的數據庫連接使用DBCP連接池管理，用戶為不將短信發出，有意將數據庫連接用戶名改錯，使得日誌中有許多數據庫連接異常的日誌，一段時間後，就出現“OutOfMemory”錯誤。經分析，這是由於DBCP連接池BUG引起的，數據庫連接不上後，沒有將連接釋放，最終使得DBCP報“OutOfMemory”錯誤。經過修改正確數據庫連接參數後，就沒有再出現內存溢出的錯誤。

查看日誌對於分析內存溢出是非常重要的，通過仔細查看日誌，分析內存溢出前做過哪些操作，可以大致定位有問題的模塊。

第三步，安排有經驗的編程人員對代碼進行走查和分析，找出可能發生內存溢出的位置。重點排查以下幾點：

檢查代碼中是否有死循環或遞歸調用。

檢查是否有大循環重復產生新對象實體。

檢查對數據庫查詢中，是否有一次獲得全部數據的查詢。

一般來說，如果一次取十萬條記錄到內存，就可能引起內存溢出。這個問題比較隱蔽，在上線前，數據庫中數據較少，不容易出問題，上線後，數據庫中數據多了，一次查詢就有可能引起內存溢出。因此對於數據庫查詢盡量采用分頁的方式查詢。

檢查List、MAP等集合對象是否有使用完後，未清除的問題。

List、MAP等集合對象會始終存有對對象的引用，使得這些對象不能被GC回收。

第四步，使用內存查看工具動態查看內存使用情況。

某個項目上線後，每次系統啟動兩天後，就會出現內存溢出的錯誤。這種情況一般是代碼中出現了緩慢的內存泄漏，用上面三個步驟解決不了，這就需要使用內存查看工具了。

內存查看工具有許多，比較有名的有：Optimizeit Profiler、JProbeProfiler、JinSight和Java1.5的Jconsole等。它們的基本工作原理大同小異，都是監測Java程序運行時所有對象的申請、釋放等動作，將內存管理的所有信息進行統計、分析、可視化。

開發人員可以根據這些信息判斷程序是否有內存泄漏問題。一般來說，一個正常的系統在其啟動完成後其內存的占用量是基本穩定的，而不應該是無限制的增長的。持續地觀察系統運行時使用的內存的大小，可以看到在內存使用監控窗口中是基本規則的鋸齒形的圖線，如果內存的大小持續地增長，則說明系統存在內存泄漏問題。通過間隔一段時間取一次內存快照，然後對內存快照中對象的使用與引用等信息進行比對與分析，可以找出是哪個類的對象在泄漏。

通過以上四個步驟的分析與處理，基本能處理內存溢出的問題。當然，在這些過程中也需要相當的經驗與敏感度，需要在實際的開發與調試過程中不斷積累。

本文出自 “寫個博客騙錢” 博客，請務必保留此出處http://dadonggg.blog.51cto.com/12672150/1952289

內存溢出