OOM
這個(gè)縮寫就是Java
程序開發(fā)過程中讓人最頭痛的問題：Out of Memory
。在很多開發(fā)人員的開發(fā)過程中，或多或少的都會(huì)遇到這類問題，這類問題定位比較困難，往往需要根據(jù)經(jīng)驗(yàn)來判斷可能出現(xiàn)問題的代碼。原因主要是兩個(gè)：對(duì)象沒有被釋放（多種情況引起，往往是比較隱蔽的引用導(dǎo)致被Hold
而無法被回收）。另一種就是真的Memory
不夠用了，需要增加JVM
的Heap
來滿足應(yīng)用程序的需求。最近有同事發(fā)的關(guān)于解決OOM
的問題，讓我了解了原來OOM
除了在JVM Heap
不夠時(shí)會(huì)發(fā)生，在Native Heap
不夠的時(shí)候也會(huì)發(fā)生，同時(shí)JVM Heap
和Native Heap
存在著相互影響和平衡的關(guān)系，因此就仔細(xì)的去看了關(guān)于OOM
和JVM
配置優(yōu)化的內(nèi)容。
OOM
在其他語言類似于C,Delphi等等由于內(nèi)存都是由自己分配和管理，因此內(nèi)存泄露的問題比較常見，同時(shí)也是很頭痛的一件事情。而Java的對(duì)象生命周期管理都是JVM來做的，簡化了開發(fā)人員的非業(yè)務(wù)邏輯的處理，但是這種自動(dòng)管理回收機(jī)制也是基于一些規(guī)則的，而違背了這些規(guī)則的時(shí)候，就會(huì)造成所謂的“Memory Leak”。
OOM(Java Heap)
錯(cuò)誤提示：java.lang.OutOfMemoryError。
這類OOM是由于JVM分配的給應(yīng)用的Heap Memory已經(jīng)被耗盡，可能是因?yàn)閼?yīng)用在高負(fù)荷的情況下的卻需要很大的內(nèi)存，因此可以通過修改JVM參數(shù)來增加Java Heap Memory（不過也不能無限制增加，后面那種OOM有可能就是因?yàn)檫@個(gè)原因而產(chǎn)生）。另一種情況是因?yàn)閼?yīng)用程序使用對(duì)象或者資源沒有釋放，導(dǎo)致內(nèi)存消耗持續(xù)增加，最后出現(xiàn)OOM，這類問題引起的原因往往是應(yīng)用已不需要的對(duì)象還被其他有效對(duì)象所引用，那么就無法釋放，可能是業(yè)務(wù)代碼邏輯造成的（異常處理不夠例如IO等資源），也可能是對(duì)于第三方開源項(xiàng)目中資源釋放了解不夠?qū)е率褂靡院筚Y源沒有釋放（例如JDBC的ResultSet等）。
幾個(gè)容易出現(xiàn)問題的場景：
1．應(yīng)用的緩存或者Collection：如果應(yīng)用要緩存Java對(duì)象或者是在一個(gè)Collection中保存對(duì)象，那么就要確定是否會(huì)有大量的對(duì)象存入，要做保護(hù)，以防止在大數(shù)據(jù)量下大量內(nèi)存被消耗，同時(shí)要保證Cache的大小不會(huì)無限制增加。
2．生命周期較長的對(duì)象：盡量簡短對(duì)象的生命周期，現(xiàn)在采用對(duì)象的創(chuàng)建釋放代價(jià)已經(jīng)很低，同時(shí)作了很好的優(yōu)化，要比創(chuàng)建一個(gè)對(duì)象長期反復(fù)使用要好。如果能夠設(shè)置超時(shí)的情景下，盡量設(shè)置超時(shí)。
3．類似于JDBC的Connection Pool，在使用Pool中的對(duì)象以后需要釋放并返回，不然就會(huì)造成Pool的不斷增大，在其他Pool中使用也是一樣。同樣ResultSet，IO這類資源的釋放都需要注意。
解決的方法就是查找錯(cuò)誤或者是增加Java Heap Memory。對(duì)于此類問題檢測工具相當(dāng)多，這里就不做介紹了。
OOM(Native Heap)
錯(cuò)誤提示：requested XXXX bytes for ChunkPool::allocate. Out of swap space。
Native Heap Memory是JVM內(nèi)部使用的Memory，這部分的Memory可以通過JDK提供的JNI的方式去訪問，這部分Memory效率很高，但是管理需要自己去做，如果沒有把握最好不要使用，以防出現(xiàn)內(nèi)存泄露問題。JVM 使用Native Heap Memory用來優(yōu)化代碼載入（JTI代碼生成），臨時(shí)對(duì)象空間申請，以及JVM內(nèi)部的一些操作。這次同事在壓力測試中遇到的問題就是這類OOM，也就是這類Memory耗盡。同樣這類OOM產(chǎn)生的問題也是分成正常使用耗盡和無釋放資源耗盡兩類。無釋放資源耗盡很多時(shí)候不是程序員自身的原因，可能是引用的第三方包的缺陷，例如很多人遇到的Oracle 9 JDBC驅(qū)動(dòng)在低版本中有內(nèi)存泄露的問題。要確定這類問題，就需要去觀察Native Heap Memory的增長和使用情況，在服務(wù)器應(yīng)用起來以后，運(yùn)行一段時(shí)間后JVM對(duì)于Native Heap Memory的使用會(huì)達(dá)到一個(gè)穩(wěn)定的階段，此時(shí)可以看看什么操作對(duì)于Native Heap Memory操作頻繁，而且使得Native Heap Memory增長，對(duì)于Native Heap Memory的情況我還沒有找到辦法去檢測，現(xiàn)在能夠看到的就是為JVM啟動(dòng)時(shí)候增加-verbose:jni參數(shù)來觀察對(duì)于Native Heap Memory的操作。另一種情況就是正常消耗Native Heap Memory，對(duì)于Native Heap Memory的使用主要取決于JVM代碼生成，線程創(chuàng)建，用于優(yōu)化的臨時(shí)代碼和對(duì)象產(chǎn)生。當(dāng)正常耗盡Native Heap Memory時(shí)，那么就需要增加Native Heap Memory，此時(shí)就會(huì)和我們前面提到增加java Heap Memory的情況出現(xiàn)矛盾。
應(yīng)用內(nèi)存組合
對(duì)于應(yīng)用來說，可分配的內(nèi)存受到OS的限制，不同的OS對(duì)進(jìn)程所能訪問虛擬內(nèi)存地址區(qū)間直接影響對(duì)于應(yīng)用內(nèi)存的分配，32位的操作系統(tǒng)通常最大支持4G的內(nèi)存尋址，而Linux一般為3G，Windows為2G。然而這些大小的內(nèi)存并不會(huì)全部給JVM的Java Heap使用，它主要會(huì)分成三部分：Java Heap，Native Heap，載入資源和類庫等所占用的內(nèi)存。那么由此可見，Native Heap和 Java Heap大小配置是相互制約的，哪一部分分配多了都可能會(huì)影響到另外一部分的正常工作，因此如果通過命令行去配置，那么需要確切的了解應(yīng)用使用情況，否則采用默認(rèn)配置自動(dòng)監(jiān)測會(huì)更好的優(yōu)化應(yīng)用使用情況。
同樣要注意的就是進(jìn)程的虛擬內(nèi)存和機(jī)器的實(shí)際內(nèi)存還是有區(qū)別的，對(duì)于機(jī)器來說實(shí)際內(nèi)存以及硬盤提供的虛擬內(nèi)存都是提供給機(jī)器上所有進(jìn)程使用的，因此在設(shè)置JVM參數(shù)時(shí)，它的虛擬內(nèi)存絕對(duì)不應(yīng)該超過實(shí)際內(nèi)存的大小。
待續(xù)……
JVM優(yōu)化配置
更多內(nèi)容可訪問：
http://blog.csdn.net/cenwenchu79/