一、概述
內(nèi)存溢出與數(shù)據(jù)庫鎖表的問題，可以說是開發(fā)人員的噩夢，一般的程序異常，總是可以知道在什么時候或是在什么操作步驟上出現(xiàn)了異常，而且根據(jù)堆棧信息也很容易定位到程序中是某處出現(xiàn)了問題。內(nèi)存溢出與鎖表則不然，一般現(xiàn)象是操作一般時間后系統(tǒng)越來越慢，直到死機，但并不能明確是在什么操作上出現(xiàn)的，發(fā)生的時間點也沒有規(guī)律，查看日志或查看數(shù)據(jù)庫也不能定位出問題的代碼。
更嚴(yán)重的是內(nèi)存溢出與數(shù)據(jù)庫鎖表在系統(tǒng)開發(fā)和單元測試階段并不容易被發(fā)現(xiàn)，當(dāng)系統(tǒng)正式上線一般時間后，操作的并發(fā)量上來了，數(shù)據(jù)也積累了一些，系統(tǒng)就容易出現(xiàn)內(nèi)存溢出或是鎖表的現(xiàn)象，而此時系統(tǒng)又不能隨意停機或重啟，為修正BUG帶來很大的困難。本文以筆者開發(fā)和支持的多個項目為例，與大家分享在開發(fā)過程中遇到的Java內(nèi)存溢出和數(shù)據(jù)庫鎖表的檢測和處理解決過程。
二、內(nèi)存溢出的分析
內(nèi)存溢出是指應(yīng)用系統(tǒng)中存在無法回收的內(nèi)存或使用的內(nèi)存過多，最終使得程序運行要用到的內(nèi)存大于虛擬機能提供的最大內(nèi)存。為了解決Java中內(nèi)存溢出問題，首先必須了解Java是如何管理內(nèi)存的。Java的內(nèi)存管理就是對象的分配和釋放問題。
在Java中，內(nèi)存的分配是由程序完成的，而內(nèi)存的釋放是由垃圾收集器(Garbage Collection，GC)完成的，程序員不需要通過調(diào)用GC函數(shù)來釋放內(nèi)存，因為不同的JVM實現(xiàn)者可能使用不同的算法管理GC，有的是內(nèi)存使用到達一定程度時，GC才開始工作，也有定時執(zhí)行的，有的是中斷式執(zhí)行GC。但GC只能回收無用并且不再被其它對象引用的那些對象所占用的空間。Java的內(nèi)存垃圾回收機制是從程序的主要運行對象開始檢查引用鏈，當(dāng)遍歷一遍后發(fā)現(xiàn)沒有被引用的孤立對象就作為垃圾回收。引起內(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)存溢出的解決
內(nèi)存溢出雖然很棘手，但也有相應(yīng)的解決辦法，可以按照從易到難，一步步的解決。
第一步，就是修改JVM啟動參數(shù)，直接增加內(nèi)存。這一點看上去似乎很簡單，但很容易被忽略。JVM默認(rèn)可以使用的內(nèi)存為64M，Tomcat默認(rèn)可以使用的內(nèi)存為128MB，對于稍復(fù)雜一點的系統(tǒng)就會不夠用。在某項目中，就因為啟動參數(shù)使用的默認(rèn)值，經(jīng)常報“OutOfMemory”錯誤。因此，-Xms，-Xmx參數(shù)一定不要忘記加。
第二步，檢查錯誤日志，查看“OutOfMemory”錯誤前是否有其它異常或錯誤。在一個項目中，使用兩個數(shù)據(jù)庫連接，其中專用于發(fā)送短信的數(shù)據(jù)庫連接使用DBCP連接池管理，用戶為不將短信發(fā)出，有意將數(shù)據(jù)庫連接用戶名改錯，使得日志中有許多數(shù)據(jù)庫連接異常的日志，一段時間后，就出現(xiàn) “OutOfMemory”錯誤。經(jīng)分析，這是由于DBCP連接池BUG引起的，數(shù)據(jù)庫連接不上后，沒有將連接釋放，最終使得DBCP報 “OutOfMemory”錯誤。經(jīng)過修改正確數(shù)據(jù)庫連接參數(shù)后，就沒有再出現(xiàn)內(nèi)存溢出的錯誤。查看日志對于分析內(nèi)存溢出是非常重要的，通過仔細查看日志，分析內(nèi)存溢出前做過哪些操作，可以大致定位有問題的模塊。
第三步，安排有經(jīng)驗的編程人員對代碼進行走查和分析，找出可能發(fā)生內(nèi)存溢出的位置。重點排查以下幾點：
(1) 檢查代碼中是否有死循環(huán)或遞歸調(diào)用。
(2) 檢查是否有大循環(huán)重復(fù)產(chǎn)生新對象實體。
(3) 檢查對數(shù)據(jù)庫查詢中，是否有一次獲得全部數(shù)據(jù)的查詢。一般來說，如果一次取十萬條記錄到內(nèi)存，就可能引起內(nèi)存溢出。這個問題比較隱蔽，在上線前，數(shù)據(jù)庫中數(shù)據(jù)較少，不容易出問題，上線后，數(shù)據(jù)庫中數(shù)據(jù)多了，一次查詢就有可能引起內(nèi)存溢出。因此對于數(shù)據(jù)庫查詢盡量采用分頁的方式查詢。
(4) 檢查List、MAP等集合對象是否有使用完后，未清除的問題。List、MAP等集合對象會始終存有對對象的引用，使得這些對象不能被GC回收。
這里引用一個常看到的例子，在下面的代碼中，循環(huán)申請Object對象，并將所申請的對象放入一個Vector中，如果僅僅釋放對象本身，但因為Vector仍然引用該對象，所以這個對象對GC來說是不可回收的。因此如果對象加入到Vector后，還必須從Vector中刪除，最簡單的方法就是將Vector對象設(shè)置為null。實際上這些對象已經(jīng)是無用的，但還被引用，GC就無能為力了(事實上GC認(rèn)為它還有用)，這一點是導(dǎo)致內(nèi)存泄漏最重要的原因。
Vector v = new Vector(10);
for (int i = 1; i < 100; i++)
{
Object o = new Object();
v.add(o);
o = null;
} // 此時所有的Object對象都沒有被釋放，因為變量v引用這些對象
再引用另一個例子來說明Java的內(nèi)存泄漏。假設(shè)有一個日志類Logger，其提供一個靜態(tài)的log(String msg)，任何其它類都可以調(diào)用Logger.Log(message)來將message的內(nèi)容記錄到系統(tǒng)的日志文件中。Logger類有一個類型為HashMap的靜態(tài)變量temp，每次在執(zhí)行l(wèi)og(message)的時候，都首先將message的值寫入temp中(以當(dāng)前線程+當(dāng)前時間為鍵)，在退出之前再從temp中將以當(dāng)前線程和當(dāng)前時間為鍵的條目刪除。注意，這里當(dāng)前時間是不斷變化的，所以log在退出之前執(zhí)行刪除條目的操作并不能刪除執(zhí)行之初寫入的條目。這樣，任何一個作為參數(shù)傳給log的字符串最終由于被Logger的靜態(tài)變量temp引用，而無法得到回收，這種對象保持就是我們所說的Java內(nèi)存泄漏。總的來說，內(nèi)存管理中的內(nèi)存泄漏產(chǎn)生的主要原因：保留下來卻永遠不再使用的對象引用。
第四步，使用內(nèi)存查看工具動態(tài)查看內(nèi)存使用情況。某個項目上線后，每次系統(tǒng)啟動兩天后，就會出現(xiàn)內(nèi)存溢出的錯誤。這種情況一般是代碼中出現(xiàn)了緩慢的內(nèi)存泄漏，用上面三個步驟解決不了，這就需要使用內(nèi)存查看工具了。
內(nèi)存查看工具有許多，比較有名的有：Optimizeit Profiler、JProbe Profiler、JinSight和Java1.5的Jconsole等。它們的基本工作原理大同小異，都是監(jiān)測Java程序運行時所有對象的申請、釋放等動作，將內(nèi)存管理的所有信息進行統(tǒng)計、分析、可視化。開發(fā)人員可以根據(jù)這些信息判斷程序是否有內(nèi)存泄漏問題。一般來說，一個正常的系統(tǒng)在其啟動完成后其內(nèi)存的占用量是基本穩(wěn)定的，而不應(yīng)該是無限制的增長的。持續(xù)地觀察系統(tǒng)運行時使用的內(nèi)存的大小，可以看到在內(nèi)存使用監(jiān)控窗口中是基本規(guī)則的鋸齒形的圖線，如果內(nèi)存的大小持續(xù)地增長，則說明系統(tǒng)存在內(nèi)存泄漏問題。通過間隔一段時間取一次內(nèi)存快照，然后對內(nèi)存快照中對象的使用與引用等信息進行比對與分析，可以找出是哪個類的對象在泄漏。
四、總結(jié)
通過以上四個步驟的分析與處理，基本能處理內(nèi)存溢出的問題。當(dāng)然，在這些過程中也需要相當(dāng)?shù)慕?jīng)驗與敏感度，需要在實際的開發(fā)與調(diào)試過程中不斷積累。總體上來說，產(chǎn)生內(nèi)存溢出是由于代碼寫的不好造成的，因此提高代碼的質(zhì)量是最根本的解決辦法。有的人認(rèn)為先把功能實現(xiàn)，有BUG時再在測試階段進行修正，這種想法是錯誤的。正如一件產(chǎn)品的質(zhì)量是在生產(chǎn)制造的過程中決定的，而不是質(zhì)量檢測時決定的，軟件的質(zhì)量在設(shè)計與編碼階段就已經(jīng)決定了，測試只是對軟件質(zhì)量的一個驗證，因為測試不可能找出軟件中所有的BUG。