Java内存溢出分析
內(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ù)庫鎖表的檢測和處理解決過程。
2．內(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)存溢出的原因有很多種，常見的有以下幾種：
l???????? 內(nèi)存中加載的數(shù)據(jù)量過于龐大，如一次從數(shù)據(jù)庫取出過多數(shù)據(jù)；
l???????? 集合類中有對對象的引用，使用完后未清空，使得JVM不能回收；
l???????? 代碼中存在死循環(huán)或循環(huán)產(chǎn)生過多重復(fù)的對象實體；
l???????? 使用的第三方軟件中的BUG；
l???????? 啟動參數(shù)內(nèi)存值設(shè)定的過小；
3．內(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)存溢出是非常重要的，通過仔細(xì)查看日志，分析內(nèi)存溢出前做過哪些操作，可以大致定位有問題的模塊。
第三步，安排有經(jīng)驗的編程人員對代碼進行走查和分析，找出可能發(fā)生內(nèi)存溢出的位置。重點排查以下幾點：
l???????? 檢查代碼中是否有死循環(huán)或遞歸調(diào)用。
l???????? 檢查是否有大循環(huán)重復(fù)產(chǎn)生新對象實體。
l???????? 檢查對數(shù)據(jù)庫查詢中，是否有一次獲得全部數(shù)據(jù)的查詢。一般來說，如果一次取十萬條記錄到內(nèi)存，就可能引起內(nèi)存溢出。這個問題比較隱蔽，在上線前，數(shù)據(jù)庫中數(shù)據(jù)較少，不容易出問題，上線后，數(shù)據(jù)庫中數(shù)據(jù)多了，一次查詢就有可能引起內(nèi)存溢出。因此對于數(shù)據(jù)庫查詢盡量采用分頁的方式查詢。
l???????? 檢查List、MAP等集合對象是否有使用完后，未清除的問題。List、MAP等集合對象會始終存有對對象的引用，使得這些對象不能被GC回收。
第四步，使用內(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)存快照中對象的使用與引用等信息進行比對與分析，可以找出是哪個類的對象在泄漏。
通過以上四個步驟的分析與處理，基本能處理內(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。
?
--------------------------------------------------------------------------------------------------------------------------------
?
原因有很多種，比如：
1.數(shù)據(jù)量過于龐大；死循環(huán) ；靜態(tài)變量和靜態(tài)方法過多；遞歸；無法確定是否被引用的對象；
2.虛擬機不回收內(nèi)存（內(nèi)存泄漏）；
??? 說白了就是程序運行要用到的內(nèi)存大于虛擬機能提供的最大內(nèi)存就發(fā)生內(nèi)存溢出了。 內(nèi)存溢出的問題要看業(yè)務(wù)和系統(tǒng)大小而定，對于某些系統(tǒng)可能內(nèi)存溢出不常見，但某些系統(tǒng)還是很常見的解決的方法，
一個是優(yōu)化程序代碼，如果業(yè)務(wù)龐大，邏輯復(fù)雜，盡量減少全局變量的引用，讓程序使用完變量的時候釋放該引用能夠讓垃圾回收器回收，釋放資源。
二就是物理解決，增大物理內(nèi)存，然后通過：-Xms256m -Xmx256m -XX:MaxNewSize=256m -XX:MaxPermSize=256m的修改
一、內(nèi)存溢出類型?
1 、 java.lang.OutOfMemoryError: PermGen space
JVM 管理兩種類型的內(nèi)存，堆和非堆。堆是給開發(fā)人員用的上面說的就是，是在 JVM 啟動時創(chuàng)建；非堆是留給 JVM 自己用的，用來存放類的信息的。它和堆不同，運行期內(nèi) GC 不會釋放空間。如果 web app 用了大量的第三方 jar 或者應(yīng)用有太多的 class 文件而恰好 MaxPermSize 設(shè)置較小，超出了也會導(dǎo)致這塊內(nèi)存的占用過多造成溢出，或者 tomcat 熱部署時侯不會清理前面加載的環(huán)境，只會將 context 更改為新部署的，非堆存的內(nèi)容就會越來越多。
2 、 java.lang.OutOfMemoryError: Java heap space
第一種情況是個補充，主要存在問題就是出現(xiàn)在這個情況中。其默認(rèn)空間 ( 即 -Xms) 是物理內(nèi)存的 1/64 ，最大空間 (-Xmx) 是物理內(nèi)存的 1/4 。如果內(nèi)存剩余不到 40 ％， JVM 就會增大堆到 Xmx 設(shè)置的值，內(nèi)存剩余超過 70 ％， JVM 就會減小堆到 Xms 設(shè)置的值。所以服務(wù)器的 Xmx 和 Xms 設(shè)置一般應(yīng)該設(shè)置相同避免每次 GC 后都要調(diào)整虛擬機堆的大小。假設(shè)物理內(nèi)存無限大，那么 JVM 內(nèi)存的最大值跟操作系統(tǒng)有關(guān)，一般 32 位機是 1.5g 到 3g 之間，而 64 位的就不會有限制了。
注意：如果 Xms 超過了 Xmx 值，或者堆最大值和非堆最大值的總和超過了物理內(nèi)存或者操作系統(tǒng)的最大限制都會引起服務(wù)器啟動不起來。
垃圾回收 GC 的角色
JVM 調(diào)用 GC 的頻度還是很高的，主要兩種情況下進行垃圾回收：
當(dāng)應(yīng)用程序線程空閑；另一個是 java 內(nèi)存堆不足時，會不斷調(diào)用 GC ，若連續(xù)回收都解決不了內(nèi)存堆不足的問題時，就會報 out of memory 錯誤。因為這個異常根據(jù)系統(tǒng)運行環(huán)境決定，所以無法預(yù)期它何時出現(xiàn)。
根據(jù) GC 的機制，程序的運行會引起系統(tǒng)運行環(huán)境的變化，增加 GC 的觸發(fā)機會。
為了避免這些問題，程序的設(shè)計和編寫就應(yīng)避免垃圾對象的內(nèi)存占用和 GC 的開銷。顯示調(diào)用 System.GC() 只能建議 JVM 需要在內(nèi)存中對垃圾對象進行回收，但不是必須馬上回收，
一個是并不能解決內(nèi)存資源耗空的局面，另外也會增加 GC 的消耗。
二、 JVM 內(nèi)存區(qū)域組成?
簡單的說 java中的堆和棧
java把內(nèi)存分兩種：一種是棧內(nèi)存，另一種是堆內(nèi)存
1。在函數(shù)中定義的基本類型變量和對象的引用變量都在函數(shù)的棧內(nèi)存中分配；
2。堆內(nèi)存用來存放由 new創(chuàng)建的對象和數(shù)組
在函數(shù)（代碼塊）中定義一個變量時， java就在棧中為這個變量分配內(nèi)存空間，當(dāng)超過變量的作用域后， java會自動釋放掉為該變量所分配的內(nèi)存空間；在堆中分配的內(nèi)存由 java虛擬機的自動垃圾回收器來管理
堆的優(yōu)勢是可以動態(tài)分配內(nèi)存大小，生存期也不必事先告訴編譯器，因為它是在運行時動態(tài)分配內(nèi)存的。缺點就是要在運行時動態(tài)分配內(nèi)存，存取速度較慢；
棧的優(yōu)勢是存取速度比堆要快，缺點是存在棧中的數(shù)據(jù)大小與生存期必須是確定的無靈活 性。
java 堆分為三個區(qū)： New 、 Old 和 Permanent
GC 有兩個線程：
新創(chuàng)建的對象被分配到 New 區(qū)，當(dāng)該區(qū)被填滿時會被 GC 輔助線程移到 Old 區(qū)，當(dāng) Old 區(qū)也填滿了會觸發(fā) GC 主線程遍歷堆內(nèi)存里的所有對象。 Old 區(qū)的大小等于 Xmx 減去 -Xmn
java棧存放
棧調(diào)整：參數(shù)有 +UseDefaultStackSize -Xss256K，表示每個線程可申請 256k的棧空間
每個線程都有他自己的 Stack
三、 JVM如何設(shè)置虛擬內(nèi)存?
提示：在 JVM中如果 98％的時間是用于 GC且可用的 Heap size 不足 2％的時候?qū)伋龃水惓Ｐ畔ⅰ?/p>
提示： Heap Size 最大不要超過可用物理內(nèi)存的 80％，一般的要將 -Xms和 -Xmx選項設(shè)置為相同，而 -Xmn為 1/4的 -Xmx值。
提示： JVM初始分配的內(nèi)存由 -Xms指定，默認(rèn)是物理內(nèi)存的 1/64； JVM最大分配的內(nèi)存由 -Xmx指定，默認(rèn)是物理內(nèi)存的 1/4。
默認(rèn)空余堆內(nèi)存小于 40%時， JVM就會增大堆直到 -Xmx的最大限制；空余堆內(nèi)存大于 70%時， JVM會減少堆直到 -Xms的最小限制。因此服務(wù)器一般設(shè)置 -Xms、 -Xmx相等以避免在每次 GC 后調(diào)整堆的大小。
提示：假設(shè)物理內(nèi)存無限大的話， JVM內(nèi)存的最大值跟操作系統(tǒng)有很大的關(guān)系。
簡單的說就 32位處理器雖然可控內(nèi)存空間有 4GB,但是具體的操作系統(tǒng)會給一個限制，
這個限制一般是 2GB-3GB（一般來說 Windows系統(tǒng)下為 1.5G-2G， Linux系統(tǒng)下為 2G-3G）， 而 64bit以上的處理器就不會有限制了
提示：注意：如果 Xms超過了 Xmx值，或者堆最大值和非堆最大值的總和超過了物理內(nèi) 存或者操作系統(tǒng)的最大限制都會引起服務(wù)器啟動不起來。
提示：設(shè)置 NewSize、 MaxNewSize相等， “new”的大小最好不要大于 “old”的一半，原因是 old區(qū)如果不夠大會頻繁的觸發(fā) “主 ” GC ，大大降低了性能
JVM使用 -XX:PermSize設(shè)置非堆內(nèi)存初始值，默認(rèn)是物理內(nèi)存的 1/64；
由 XX:MaxPermSize設(shè)置最大非堆內(nèi)存的大小，默認(rèn)是物理內(nèi)存的 1/4。
解決方法：手動設(shè)置 Heap size
修改 TOMCAT_HOME/bin/catalina.bat
在“ echo “Using CATALINA_BASE: $CATALINA_BASE””上面加入以下行：
四、性能檢查工具使用?
定位內(nèi)存泄漏：
JProfiler 工具主要用于檢查和跟蹤系統(tǒng)（限于 Java 開發(fā)的）的性能。 JProfiler 可以通過時時的監(jiān)控系統(tǒng)的內(nèi)存使用情況，隨時監(jiān)視垃圾回收，線程運行狀況等手段，從而很好的監(jiān)視 JVM 運行情況及其性能。
1. 應(yīng)用服務(wù)器內(nèi)存長期不合理占用，內(nèi)存經(jīng)常處于高位占用，很難回收到低位；
2. 應(yīng)用服務(wù)器極為不穩(wěn)定，幾乎每兩天重新啟動一次，有時甚至每天重新啟動一次；
3. 應(yīng)用服務(wù)器經(jīng)常做 Full GC(Garbage Collection)，而且時間很長，大約需要 30-40秒，應(yīng)用服務(wù)器在做 Full GC的時候是不響應(yīng)客戶的交易請求的，非常影響系統(tǒng)性能。
因為開發(fā)環(huán)境和產(chǎn)品環(huán)境會有不同，導(dǎo)致該問題發(fā)生有時會在產(chǎn)品環(huán)境中發(fā)生， 通常可以使用工具跟蹤系統(tǒng)的內(nèi)存使用情況，在有些個別情況下或許某個時刻確實 是使用了大量內(nèi)存導(dǎo)致 out of memory，這時應(yīng)繼續(xù)跟蹤看接下來是否會有下降，
如果一直居高不下這肯定就因為程序的原因?qū)е聝?nèi)存泄漏。
五、不健壯代碼的特征及解決辦法?
1 、盡早釋放無用對象的引用。好的辦法是使用臨時變量的時候，讓引用變量在退出活動域后，自動設(shè)置為 null ，暗示垃圾收集器來收集該對象，防止發(fā)生內(nèi)存泄露。
對于仍然有指針指向的實例， jvm 就不會回收該資源 , 因為垃圾回收會將值為 null 的對象作為垃圾，提高 GC 回收機制效率；
2 、我們的程序里不可避免大量使用字符串處理，避免使用 String ，應(yīng)大量使用 StringBuffer ，每一個 String 對象都得獨立占用內(nèi)存一塊區(qū)域；
3 、盡量少用靜態(tài)變量，因為靜態(tài)變量是全局的， GC 不會回收的；
4 、避免集中創(chuàng)建對象尤其是大對象， JVM 會突然需要大量內(nèi)存，這時必然會觸發(fā) GC 優(yōu)化系統(tǒng)內(nèi)存環(huán)境；顯示的聲明數(shù)組空間，而且申請數(shù)量還極大。
這是一個案例想定供大家警戒:
使用jspsmartUpload作文件上傳,現(xiàn)在運行過程中經(jīng)常出現(xiàn)java.outofMemoryError的錯誤，用top命令看看進程使用情況，發(fā)現(xiàn)內(nèi)存不足2M，花了很長時間，發(fā)現(xiàn)是jspsmartupload的問題。把jspsmartupload組件的源碼文件（class文件）反編譯成Java文件，如夢方醒：
變量m_totalBytes表示用戶上傳的文件的總長度，這是一個很大的數(shù)。如果用這樣大的數(shù)去聲明一個byte數(shù)組，并給數(shù)組的每個元素分配內(nèi)存空間，而且m_binArray數(shù)組不能馬上被釋放，JVM的垃圾回收確實有問題，導(dǎo)致的結(jié)果就是內(nèi)存溢出。
jspsmartUpload為什末要這樣作，有他的原因，根據(jù)RFC1867的http上傳標(biāo)準(zhǔn)，得到一個文件流，并不知道文件流的長度。設(shè)計者如果想文件的長度，只有操作servletinputstream一次才知道，因為任何流都不知道大小。只有知道文件長度了，才可以限制用戶上傳文件的長度。為了省去這個麻煩，jspsmartUpload設(shè)計者直接在內(nèi)存中打開文件，判斷長度是否符合標(biāo)準(zhǔn)，符合就寫到服務(wù)器的硬盤。這樣產(chǎn)生內(nèi)存溢出，這只是我的一個猜測而已。
所以編程的時候，不要在內(nèi)存中申請大的空間，因為web服務(wù)器的內(nèi)存有限，并且盡可能的使用流操作，例如
5 、盡量運用對象池技術(shù)以提高系統(tǒng)性能；生命周期長的對象擁有生命周期短的對象時容易引發(fā)內(nèi)存泄漏，例如大集合對象擁有大數(shù)據(jù)量的業(yè)務(wù)對象的時候，可以考慮分塊進行處理，然后解決一塊釋放一塊的策略。
6 、不要在經(jīng)常調(diào)用的方法中創(chuàng)建對象，尤其是忌諱在循環(huán)中創(chuàng)建對象。可以適當(dāng)?shù)氖褂?hashtable ， vector 創(chuàng)建一組對象容器，然后從容器中去取那些對象，而不用每次 new 之后又丟棄
7 、一般都是發(fā)生在開啟大型文件或跟數(shù)據(jù)庫一次拿了太多的數(shù)據(jù)，造成 Out Of Memory Error 的狀況，這時就大概要計算一下數(shù)據(jù)量的最大值是多少，并且設(shè)定所需最小及最大的內(nèi)存空間值。
總結(jié)
以上是生活随笔為你收集整理的Java内存溢出分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 在CLASSPATH中加载目录下所有的j
- 下一篇： jvm的参数含义及设置