少年阿賓

內(nèi)存溢出與數(shù)據(jù)庫鎖表的問題，可以說是開發(fā)人員的噩夢，一般的程序異常，總是可以知道在什么時(shí)候或是在什么操作步驟上出現(xiàn)了異常，而且根據(jù)堆棧信息也很容易定位到程序中是某處出現(xiàn)了問題。內(nèi)存溢出與鎖表則不然，一般現(xiàn)象是操作一般時(shí)間后系統(tǒng)越來越慢，直到死機(jī)，但并不能明確是在什么操作上出現(xiàn)的，發(fā)生的時(shí)間點(diǎn)也沒有規(guī)律，查看日志或查看數(shù)據(jù)庫也不能定位出問題的代碼。

更嚴(yán)重的是內(nèi)存溢出與數(shù)據(jù)庫鎖表在系統(tǒng)開發(fā)和單元測試階段并不容易被發(fā)現(xiàn)，當(dāng)系統(tǒng)正式上線一般時(shí)間后，操作的并發(fā)量上來了，數(shù)據(jù)也積累了一些，系統(tǒng)就容易出現(xiàn)內(nèi)存溢出或是鎖表的現(xiàn)象，而此時(shí)系統(tǒng)又不能隨意停機(jī)或重啟，為修正BUG帶來很大的困難。

本文以筆者開發(fā)和支持的多個(gè)項(xiàng)目為例，與大家分享在開發(fā)過程中遇到的Java內(nèi)存溢出和數(shù)據(jù)庫鎖表的檢測和處理解決過程。

2．內(nèi)存溢出的分析
內(nèi)存溢出是指應(yīng)用系統(tǒng)中存在無法回收的內(nèi)存或使用的內(nèi)存過多，最終使得程序運(yùn)行要用到的內(nèi)存大于虛擬機(jī)能提供的最大內(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)存，因?yàn)椴煌腏VM實(shí)現(xiàn)者可能使用不同的算法管理GC，有的是內(nèi)存使用到達(dá)一定程度時(shí)，GC才開始工作，也有定時(shí)執(zhí)行的，有的是中斷式執(zhí)行GC。但GC只能回收無用并且不再被其它對象引用的那些對象所占用的空間。Java的內(nèi)存垃圾回收機(jī)制是從程序的主要運(yùn)行對象開始檢查引用鏈，當(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ù)的對象實(shí)體；

l         使用的第三方軟件中的BUG；

l         啟動(dòng)參數(shù)內(nèi)存值設(shè)定的過小；

3．內(nèi)存溢出的解決
內(nèi)存溢出雖然很棘手，但也有相應(yīng)的解決辦法，可以按照從易到難，一步步的解決。

第一步，就是修改JVM啟動(dòng)參數(shù)，直接增加內(nèi)存。這一點(diǎn)看上去似乎很簡單，但很容易被忽略。JVM默認(rèn)可以使用的內(nèi)存為64M，Tomcat默認(rèn)可以使用的內(nèi)存為128MB，對于稍復(fù)雜一點(diǎn)的系統(tǒng)就會(huì)不夠用。在某項(xiàng)目中，就因?yàn)閱?dòng)參數(shù)使用的默認(rèn)值，經(jīng)常報(bào)“OutOfMemory”錯(cuò)誤。因此，-Xms，-Xmx參數(shù)一定不要忘記加。

第二步，檢查錯(cuò)誤日志，查看“OutOfMemory”錯(cuò)誤前是否有其它異常或錯(cuò)誤。在一個(gè)項(xiàng)目中，使用兩個(gè)數(shù)據(jù)庫連接，其中專用于發(fā)送短信的數(shù)據(jù)庫連接使用DBCP連接池管理，用戶為不將短信發(fā)出，有意將數(shù)據(jù)庫連接用戶名改錯(cuò)，使得日志中有許多數(shù)據(jù)庫連接異常的日志，一段時(shí)間后，就出現(xiàn)“OutOfMemory”錯(cuò)誤。經(jīng)分析，這是由于DBCP連接池BUG引起的，數(shù)據(jù)庫連接不上后，沒有將連接釋放，最終使得DBCP報(bào)“OutOfMemory”錯(cuò)誤。經(jīng)過修改正確數(shù)據(jù)庫連接參數(shù)后，就沒有再出現(xiàn)內(nèi)存溢出的錯(cuò)誤。

查看日志對于分析內(nèi)存溢出是非常重要的，通過仔細(xì)查看日志，分析內(nèi)存溢出前做過哪些操作，可以大致定位有問題的模塊。

第三步，安排有經(jīng)驗(yàn)的編程人員對代碼進(jìn)行走查和分析，找出可能發(fā)生內(nèi)存溢出的位置。重點(diǎn)排查以下幾點(diǎn)：

l         檢查代碼中是否有死循環(huán)或遞歸調(diào)用。

l         檢查是否有大循環(huán)重復(fù)產(chǎn)生新對象實(shí)體。

l         檢查對數(shù)據(jù)庫查詢中，是否有一次獲得全部數(shù)據(jù)的查詢。一般來說，如果一次取十萬條記錄到內(nèi)存，就可能引起內(nèi)存溢出。這個(gè)問題比較隱蔽，在上線前，數(shù)據(jù)庫中數(shù)據(jù)較少，不容易出問題，上線后，數(shù)據(jù)庫中數(shù)據(jù)多了，一次查詢就有可能引起內(nèi)存溢出。因此對于數(shù)據(jù)庫查詢盡量采用分頁的方式查詢。

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

第四步，使用內(nèi)存查看工具動(dòng)態(tài)查看內(nèi)存使用情況。某個(gè)項(xiàng)目上線后，每次系統(tǒng)啟動(dòng)兩天后，就會(huì)出現(xiàn)內(nèi)存溢出的錯(cuò)誤。這種情況一般是代碼中出現(xiàn)了緩慢的內(nèi)存泄漏，用上面三個(gè)步驟解決不了，這就需要使用內(nèi)存查看工具了。

內(nèi)存查看工具有許多，比較有名的有：Optimizeit Profiler、JProbe Profiler、JinSight和Java1.5的Jconsole等。它們的基本工作原理大同小異，都是監(jiān)測Java程序運(yùn)行時(shí)所有對象的申請、釋放等動(dòng)作，將內(nèi)存管理的所有信息進(jìn)行統(tǒng)計(jì)、分析、可視化。開發(fā)人員可以根據(jù)這些信息判斷程序是否有內(nèi)存泄漏問題。一般來說，一個(gè)正常的系統(tǒng)在其啟動(dòng)完成后其內(nèi)存的占用量是基本穩(wěn)定的，而不應(yīng)該是無限制的增長的。持續(xù)地觀察系統(tǒng)運(yùn)行時(shí)使用的內(nèi)存的大小，可以看到在內(nèi)存使用監(jiān)控窗口中是基本規(guī)則的鋸齒形的圖線，如果內(nèi)存的大小持續(xù)地增長，則說明系統(tǒng)存在內(nèi)存泄漏問題。通過間隔一段時(shí)間取一次內(nèi)存快照，然后對內(nèi)存快照中對象的使用與引用等信息進(jìn)行比對與分析，可以找出是哪個(gè)類的對象在泄漏。

通過以上四個(gè)步驟的分析與處理，基本能處理內(nèi)存溢出的問題。當(dāng)然，在這些過程中也需要相當(dāng)?shù)慕?jīng)驗(yàn)與敏感度，需要在實(shí)際的開發(fā)與調(diào)試過程中不斷積累。

總體上來說，產(chǎn)生內(nèi)存溢出是由于代碼寫的不好造成的，因此提高代碼的質(zhì)量是最根本的解決辦法。有的人認(rèn)為先把功能實(shí)現(xiàn)，有BUG時(shí)再在測試階段進(jìn)行修正，這種想法是錯(cuò)誤的。正如一件產(chǎn)品的質(zhì)量是在生產(chǎn)制造的過程中決定的，而不是質(zhì)量檢測時(shí)決定的，軟件的質(zhì)量在設(shè)計(jì)與編碼階段就已經(jīng)決定了，測試只是對軟件質(zhì)量的一個(gè)驗(yàn)證，因?yàn)闇y試不可能找出軟件中所有的BUG。

 

--------------------------------------------------------------------------------------------------------------------------------

 

原因有很多種，比如：

1.數(shù)據(jù)量過于龐大；死循環(huán) ；靜態(tài)變量和靜態(tài)方法過多；遞歸；無法確定是否被引用的對象；

2.虛擬機(jī)不回收內(nèi)存（內(nèi)存泄漏）；

    說白了就是程序運(yùn)行要用到的內(nèi)存大于虛擬機(jī)能提供的最大內(nèi)存就發(fā)生內(nèi)存溢出了。 內(nèi)存溢出的問題要看業(yè)務(wù)和系統(tǒng)大小而定，對于某些系統(tǒng)可能內(nèi)存溢出不常見，但某些系統(tǒng)還是很常見的解決的方法，

一個(gè)是優(yōu)化程序代碼，如果業(yè)務(wù)龐大，邏輯復(fù)雜，盡量減少全局變量的引用，讓程序使用完變量的時(shí)候釋放該引用能夠讓垃圾回收器回收，釋放資源。
二就是物理解決，增大物理內(nèi)存，然后通過：-Xms256m -Xmx256m -XX:MaxNewSize=256m -XX:MaxPermSize=256m的修改

一、內(nèi)存溢出類型
1 、 java.lang.OutOfMemoryError: PermGen space

JVM 管理兩種類型的內(nèi)存，堆和非堆。堆是給開發(fā)人員用的上面說的就是，是在 JVM 啟動(dòng)時(shí)創(chuàng)建；非堆是留給 JVM 自己用的，用來存放類的信息的。它和堆不同，運(yùn)行期內(nèi) GC 不會(huì)釋放空間。如果 web app 用了大量的第三方 jar 或者應(yīng)用有太多的 class 文件而恰好 MaxPermSize 設(shè)置較小，超出了也會(huì)導(dǎo)致這塊內(nèi)存的占用過多造成溢出，或者 tomcat 熱部署時(shí)侯不會(huì)清理前面加載的環(huán)境，只會(huì)將 context 更改為新部署的，非堆存的內(nèi)容就會(huì)越來越多。

2 、 java.lang.OutOfMemoryError: Java heap space

第一種情況是個(gè)補(bǔ)充，主要存在問題就是出現(xiàn)在這個(gè)情況中。其默認(rèn)空間 ( 即 -Xms) 是物理內(nèi)存的 1/64 ，最大空間 (-Xmx) 是物理內(nèi)存的 1/4 。如果內(nèi)存剩余不到 40 ％， JVM 就會(huì)增大堆到 Xmx 設(shè)置的值，內(nèi)存剩余超過 70 ％， JVM 就會(huì)減小堆到 Xms 設(shè)置的值。所以服務(wù)器的 Xmx 和 Xms 設(shè)置一般應(yīng)該設(shè)置相同避免每次 GC 后都要調(diào)整虛擬機(jī)堆的大小。假設(shè)物理內(nèi)存無限大，那么 JVM 內(nèi)存的最大值跟操作系統(tǒng)有關(guān)，一般 32 位機(jī)是 1.5g 到 3g 之間，而 64 位的就不會(huì)有限制了。

注意：如果 Xms 超過了 Xmx 值，或者堆最大值和非堆最大值的總和超過了物理內(nèi)存或者操作系統(tǒng)的最大限制都會(huì)引起服務(wù)器啟動(dòng)不起來。

垃圾回收 GC 的角色

JVM 調(diào)用 GC 的頻度還是很高的，主要兩種情況下進(jìn)行垃圾回收：

當(dāng)應(yīng)用程序線程空閑；另一個(gè)是 java 內(nèi)存堆不足時(shí)，會(huì)不斷調(diào)用 GC ，若連續(xù)回收都解決不了內(nèi)存堆不足的問題時(shí)，就會(huì)報(bào) out of memory 錯(cuò)誤。因?yàn)檫@個(gè)異常根據(jù)系統(tǒng)運(yùn)行環(huán)境決定，所以無法預(yù)期它何時(shí)出現(xiàn)。

根據(jù) GC 的機(jī)制，程序的運(yùn)行會(huì)引起系統(tǒng)運(yùn)行環(huán)境的變化，增加 GC 的觸發(fā)機(jī)會(huì)。

為了避免這些問題，程序的設(shè)計(jì)和編寫就應(yīng)避免垃圾對象的內(nèi)存占用和 GC 的開銷。顯示調(diào)用 System.GC() 只能建議 JVM 需要在內(nèi)存中對垃圾對象進(jìn)行回收，但不是必須馬上回收，

一個(gè)是并不能解決內(nèi)存資源耗空的局面，另外也會(huì)增加 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ù)（代碼塊）中定義一個(gè)變量時(shí)， java就在棧中為這個(gè)變量分配內(nèi)存空間，當(dāng)超過變量的作用域后， java會(huì)自動(dòng)釋放掉為該變量所分配的內(nèi)存空間；在堆中分配的內(nèi)存由 java虛擬機(jī)的自動(dòng)垃圾回收器來管理

堆的優(yōu)勢是可以動(dòng)態(tài)分配內(nèi)存大小，生存期也不必事先告訴編譯器，因?yàn)樗窃谶\(yùn)行時(shí)動(dòng)態(tài)分配內(nèi)存的。缺點(diǎn)就是要在運(yùn)行時(shí)動(dòng)態(tài)分配內(nèi)存，存取速度較慢；

棧的優(yōu)勢是存取速度比堆要快，缺點(diǎn)是存在棧中的數(shù)據(jù)大小與生存期必須是確定的無靈活 性。

java 堆分為三個(gè)區(qū)： New 、 Old 和 Permanent

GC 有兩個(gè)線程：

新創(chuàng)建的對象被分配到 New 區(qū)，當(dāng)該區(qū)被填滿時(shí)會(huì)被 GC 輔助線程移到 Old 區(qū)，當(dāng) Old 區(qū)也填滿了會(huì)觸發(fā) GC 主線程遍歷堆內(nèi)存里的所有對象。 Old 區(qū)的大小等于 Xmx 減去 -Xmn

java棧存放

棧調(diào)整：參數(shù)有 +UseDefaultStackSize -Xss256K，表示每個(gè)線程可申請 256k的棧空間

每個(gè)線程都有他自己的 Stack

三、 JVM如何設(shè)置虛擬內(nèi)存
提示：在 JVM中如果 98％的時(shí)間是用于 GC且可用的 Heap size 不足 2％的時(shí)候?qū)伋龃水惓Ｐ畔ⅰ?/p>

提示： Heap Size 最大不要超過可用物理內(nèi)存的 80％，一般的要將 -Xms和 -Xmx選項(xiàng)設(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%時(shí)， JVM就會(huì)增大堆直到 -Xmx的最大限制；空余堆內(nèi)存大于 70%時(shí)， JVM會(huì)減少堆直到 -Xms的最小限制。因此服務(wù)器一般設(shè)置 -Xms、 -Xmx相等以避免在每次 GC 后調(diào)整堆的大小。

提示：假設(shè)物理內(nèi)存無限大的話， JVM內(nèi)存的最大值跟操作系統(tǒng)有很大的關(guān)系。

簡單的說就 32位處理器雖然可控內(nèi)存空間有 4GB,但是具體的操作系統(tǒng)會(huì)給一個(gè)限制，

這個(gè)限制一般是 2GB-3GB（一般來說 Windows系統(tǒng)下為 1.5G-2G， Linux系統(tǒng)下為 2G-3G）， 而 64bit以上的處理器就不會(huì)有限制了

提示：注意：如果 Xms超過了 Xmx值，或者堆最大值和非堆最大值的總和超過了物理內(nèi) 存或者操作系統(tǒng)的最大限制都會(huì)引起服務(wù)器啟動(dòng)不起來。

提示：設(shè)置 NewSize、 MaxNewSize相等， “new”的大小最好不要大于 “old”的一半，原因是 old區(qū)如果不夠大會(huì)頻繁的觸發(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。

解決方法：手動(dòng)設(shè)置 Heap size

修改 TOMCAT_HOME/bin/catalina.bat

在“ echo “Using CATALINA_BASE: $CATALINA_BASE””上面加入以下行：

四、性能檢查工具使用
定位內(nèi)存泄漏：

JProfiler 工具主要用于檢查和跟蹤系統(tǒng)（限于 Java 開發(fā)的）的性能。 JProfiler 可以通過時(shí)時(shí)的監(jiān)控系統(tǒng)的內(nèi)存使用情況，隨時(shí)監(jiān)視垃圾回收，線程運(yùn)行狀況等手段，從而很好的監(jiān)視 JVM 運(yùn)行情況及其性能。

1. 應(yīng)用服務(wù)器內(nèi)存長期不合理占用，內(nèi)存經(jīng)常處于高位占用，很難回收到低位；

2. 應(yīng)用服務(wù)器極為不穩(wěn)定，幾乎每兩天重新啟動(dòng)一次，有時(shí)甚至每天重新啟動(dòng)一次；

3. 應(yīng)用服務(wù)器經(jīng)常做 Full GC(Garbage Collection)，而且時(shí)間很長，大約需要 30-40秒，應(yīng)用服務(wù)器在做 Full GC的時(shí)候是不響應(yīng)客戶的交易請求的，非常影響系統(tǒng)性能。

因?yàn)殚_發(fā)環(huán)境和產(chǎn)品環(huán)境會(huì)有不同，導(dǎo)致該問題發(fā)生有時(shí)會(huì)在產(chǎn)品環(huán)境中發(fā)生， 通常可以使用工具跟蹤系統(tǒng)的內(nèi)存使用情況，在有些個(gè)別情況下或許某個(gè)時(shí)刻確實(shí) 是使用了大量內(nèi)存導(dǎo)致 out of memory，這時(shí)應(yīng)繼續(xù)跟蹤看接下來是否會(huì)有下降，

如果一直居高不下這肯定就因?yàn)槌绦虻脑驅(qū)е聝?nèi)存泄漏。

五、不健壯代碼的特征及解決辦法
1 、盡早釋放無用對象的引用。好的辦法是使用臨時(shí)變量的時(shí)候，讓引用變量在退出活動(dòng)域后，自動(dòng)設(shè)置為 null ，暗示垃圾收集器來收集該對象，防止發(fā)生內(nèi)存泄露。

對于仍然有指針指向的實(shí)例， jvm 就不會(huì)回收該資源 , 因?yàn)槔厥諘?huì)將值為 null 的對象作為垃圾，提高 GC 回收機(jī)制效率；

2 、我們的程序里不可避免大量使用字符串處理，避免使用 String ，應(yīng)大量使用 StringBuffer ，每一個(gè) String 對象都得獨(dú)立占用內(nèi)存一塊區(qū)域；

3 、盡量少用靜態(tài)變量，因?yàn)殪o態(tài)變量是全局的， GC 不會(huì)回收的；

4 、避免集中創(chuàng)建對象尤其是大對象， JVM 會(huì)突然需要大量內(nèi)存，這時(shí)必然會(huì)觸發(fā) GC 優(yōu)化系統(tǒng)內(nèi)存環(huán)境；顯示的聲明數(shù)組空間，而且申請數(shù)量還極大。

這是一個(gè)案例想定供大家警戒:

使用jspsmartUpload作文件上傳,現(xiàn)在運(yùn)行過程中經(jīng)常出現(xiàn)java.outofMemoryError的錯(cuò)誤，用top命令看看進(jìn)程使用情況，發(fā)現(xiàn)內(nèi)存不足2M，花了很長時(shí)間，發(fā)現(xiàn)是jspsmartupload的問題。把jspsmartupload組件的源碼文件（class文件）反編譯成Java文件，如夢方醒：

變量m_totalBytes表示用戶上傳的文件的總長度，這是一個(gè)很大的數(shù)。如果用這樣大的數(shù)去聲明一個(gè)byte數(shù)組，并給數(shù)組的每個(gè)元素分配內(nèi)存空間，而且m_binArray數(shù)組不能馬上被釋放，JVM的垃圾回收確實(shí)有問題，導(dǎo)致的結(jié)果就是內(nèi)存溢出。

jspsmartUpload為什末要這樣作，有他的原因，根據(jù)RFC1867的http上傳標(biāo)準(zhǔn)，得到一個(gè)文件流，并不知道文件流的長度。設(shè)計(jì)者如果想文件的長度，只有操作servletinputstream一次才知道，因?yàn)槿魏瘟鞫疾恢来笮　Ｖ挥兄牢募L度了，才可以限制用戶上傳文件的長度。為了省去這個(gè)麻煩，jspsmartUpload設(shè)計(jì)者直接在內(nèi)存中打開文件，判斷長度是否符合標(biāo)準(zhǔn)，符合就寫到服務(wù)器的硬盤。這樣產(chǎn)生內(nèi)存溢出，這只是我的一個(gè)猜測而已。

所以編程的時(shí)候，不要在內(nèi)存中申請大的空間，因?yàn)閣eb服務(wù)器的內(nèi)存有限，并且盡可能的使用流操作，例如

5 、盡量運(yùn)用對象池技術(shù)以提高系統(tǒng)性能；生命周期長的對象擁有生命周期短的對象時(shí)容易引發(fā)內(nèi)存泄漏，例如大集合對象擁有大數(shù)據(jù)量的業(yè)務(wù)對象的時(shí)候，可以考慮分塊進(jìn)行處理，然后解決一塊釋放一塊的策略。

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ù)據(jù)量的最大值是多少，并且設(shè)定所需最小及最大的內(nèi)存空間值。