java 程式記憶體溢位

3．記憶體溢位的解決

記憶體溢位雖然很棘手，但也有相應的解決辦法，可以按照從易到難，一步步的解決。

第一步，就是修改JVM啟動引數，直接增加記憶體。這一點看上去似乎很簡單，但很容易被忽略。JVM預設可以使用的記憶體為64M，Tomcat預設可以使用的記憶體為128MB，對於稍複雜一點的系統就會不夠用。在某專案中，就因為啟動引數使用的預設值，經常報“OutOfMemory”錯誤。因此，-Xms，-Xmx引數一定不要忘記加。

第二步，檢查錯誤日誌，檢視“OutOfMemory”錯誤前是否有其它異常或錯誤。在一個專案中，使用兩個資料庫連線，其中專用於傳送簡訊的資料庫連線使用DBCP連線池管理，使用者為不將簡訊發出，有意將資料庫連線使用者名稱改錯，使得日誌中有許多資料庫連線異常的日誌，一段時間後，就出現“OutOfMemory”錯誤。經分析，這是由於DBCP連線池BUG引起的，資料庫連線不上後，沒有將連線釋放，最終使得DBCP報“OutOfMemory”錯誤。經過修改正確資料庫連線引數後，就沒有再出現記憶體溢位的錯誤。

檢視日誌對於分析記憶體溢位是非常重要的，通過仔細檢視日誌，分析記憶體溢位前做過哪些操作，可以大致定位有問題的模組。

第三步，安排有經驗的程式設計人員對程式碼進行走查和分析，找出可能發生記憶體溢位的位置。重點排查以下幾點：

l          檢查程式碼中是否有死迴圈或遞迴呼叫。

l          檢查是否有大迴圈重複產生新物件實體。

l          檢查對資料庫查詢中，是否有一次獲得全部資料的查詢。一般來說，如果一次取十萬條記錄到記憶體，就可能引起記憶體溢位。這個問題比較隱蔽，在上線前，資料庫中資料較少，不容易出問題，上線後，資料庫中資料多了，一次查詢就有可能引起記憶體溢位。因此對於資料庫查詢儘量採用分頁的方式查詢。

l          檢查List、MAP等集合物件是否有使用完後，未清除的問題。List、MAP等集合物件會始終存有對物件的引用，使得這些物件不能被GC回收。

第四步，使用記憶體檢視工具動態檢視記憶體使用情況。某個專案上線後，每次系統啟動兩天後，就會出現記憶體溢位的錯誤。這種情況一般是程式碼中出現了緩慢的記憶體洩漏，用上面三個步驟解決不了，這就需要使用記憶體檢視工具了。

記憶體檢視工具有許多，比較有名的有：Optimizeit Profiler、JProbe Profiler、JinSight和Java1.5的Jconsole等。它們的基本工作原理大同小異，都是監測Java程式執行時所有物件的申請、釋放等動作，將記憶體管理的所有資訊進行統計、分析、視覺化。開發人員可以根據這些資訊判斷程式是否有記憶體洩漏問題。一般來說，一個正常的系統在其啟動完成後其記憶體的佔用量是基本穩定的，而不應該是無限制的增長的。持續地觀察系統執行時使用的記憶體的大小，可以看到在記憶體使用監控視窗中是基本規則的鋸齒形的圖線，如果記憶體的大小持續地增長，則說明系統存在記憶體洩漏問題。通過間隔一段時間取一次記憶體快照，然後對記憶體快照中物件的使用與引用等資訊進行比對與分析，可以找出是哪個類的物件在洩漏。

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