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