java會內存溢出嗎
java會內存溢出嗎
內存溢出與數據庫鎖表的問題,可以說是開發人員的噩夢,一般的程序異常,總是可以知道在什么時候或是在什么操作步驟上出現了異常,而且根據堆棧信息也很容易定位到程序中是某處出現了問題。內存溢出與鎖表則不然,一般現象是操作一般時間后系統越來越慢,直到死機,但并不能明確是在什么操作上出現的,發生的時間點也沒有規律,查看日志或查看數據庫也不能定位出問題的代碼。下面就由學習啦小編為大家整理的溢出問題解決方法,供大家參考!
1內存溢出的分析
內存溢出是指應用系統中存在無法回收的內存或使用的內存過多,最終使得程序運行要用到的內存大于虛擬機能提供的最大內存。為了解決Java中內存溢出問題,我們首先必須了解Java是如何管理內存的。Java的內存管理就是對象的分配和釋放問題。在Java中,內存的分配是由程序完成的,而內存的釋放是由垃圾收集器(Garbage Collection,GC)完成的,程序員不需要通過調用GC函數來釋放內存,因為不同的JVM實現者可能使用不同的算法管理GC,有的是內存使用到達一定程度時,GC才開始工作,也有定時執行的,有的是中斷式執行GC。但GC只能回收無用并且不再被其它對象引用的那些對象所占用的空間。Java的內存垃圾回收機制是從程序的主要運行對象開始檢查引用鏈,當遍歷一遍后發現沒有被引用的孤立對象就作為垃圾回收。
引起內存溢出的原因有很多種,常見的有以下幾種:
l 內存中加載的數據量過于龐大,如一次從數據庫取出過多數據;
l 集合類中有對對象的引用,使用完后未清空,使得JVM不能回收;
l 代碼中存在死循環或循環產生過多重復的對象實體;
l 使用的第三方軟件中的BUG;
l 啟動參數內存值設定的過小;
2內存溢出的解決
內存溢出雖然很棘手,但也有相應的解決辦法,可以按照從易到難,一步步的解決。
第一步,就是修改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程序運行時所有對象的申請、釋放等動作,將內存管理的所有信息進行統計、分析、可視化。開發人員可以根據這些信息判斷程序是否有內存泄漏問題。一般來說,一個正常的系統在其啟動完成后其內存的占用量是基本穩定的,而不應該是無限制的增長的。持續地觀察系統運行時使用的內存的大小,可以看到在內存使用監控窗口中是基本規則的鋸齒形的圖線,如果內存的大小持續地增長,則說明系統存在內存泄漏問題。通過間隔一段時間取一次內存快照,然后對內存快照中對象的使用與引用等信息進行比對與分析,可以找出是哪個類的對象在泄漏。
通過以上四個步驟的分析與處理,基本能處理內存溢出的問題。當然,在這些過程中也需要相當的經驗與敏感度,需要在實際的開發與調試過程中不斷積累。
