Java OOM原因以及解決方案
1）什麼是OOM？ OOM，全稱“Out Of Memory”，翻譯成中文就是“內存用完瞭”，來源於java.lang.OutOfMemoryError。看下關於的官方說明： Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector. 意思就是說，當JVM因為沒有足夠的內存來為對象分配空間並且垃圾回收器也已經沒有空間可回收時，就會拋出這個error（註：非exception，因為這個問題已經嚴重到不足以被應用處理）。
2）為什麼會OOM？
為什麼會沒有內存瞭呢？原因不外乎有兩點：
1）分配的少瞭：比如虛擬機本身可使用的內存（一般通過啟動時的VM參數指定）太少。
2）應用用的太多，並且用完沒釋放，浪費瞭。此時就會造成內存泄露或者內存溢出。
內存泄露：申請使用完的內存沒有釋放，導致虛擬機不能再次使用該內存，此時這段內存就泄露瞭，因為申請者不用瞭，而又不能被虛擬機分配給別人用。
內存溢出：申請的內存超出瞭JVM能提供的內存大小，此時稱之為溢出。
在之前沒有垃圾自動回收的日子裡，比如C語言和C++語言，我們必須親自負責內存的申請與釋放操作，如果申請瞭內存，用完後又忘記瞭釋放，比如C++中的new瞭但是沒有delete，那麼就可能造成內存泄露。偶爾的內存泄露可能不會造成問題，而大量的內存泄露可能會導致內存溢出。
而在Java語言中，由於存在瞭垃圾自動回收機制，所以，我們一般不用去主動釋放不用的對象所占的內存，也就是理論上來說，是不會存在“內存泄露”的。但是，如果編碼不當，比如，將某個對象的引用放到瞭全局的Map中，雖然方法結束瞭，但是由於垃圾回收器會根據對象的引用情況來回收內存，導致該對象不能被及時的回收。如果該種情況出現次數多瞭，就會導致內存溢出，比如系統中經常使用的緩存機制。Java中的內存泄露，不同於C++中的忘瞭delete，往往是邏輯上的原因泄露。
3）OOM的類型
JVM內存模型：
按照JVM規范，JAVA虛擬機在運行時會管理以下的內存區域：
- 程序計數器：當前線程執行的字節碼的行號指示器，線程私有
- JAVA虛擬機棧：Java方法執行的內存模型，每個Java方法的執行對應著一個棧幀的進棧和出棧的操作。
- 本地方法棧：類似“ JAVA虛擬機棧 ”，但是為native方法的運行提供內存環境。
- JAVA堆：對象內存分配的地方，內存垃圾回收的主要區域，所有線程共享。可分為新生代，老生代。
- 方法區：用於存儲已經被JVM加載的類信息、常量、靜態變量、即時編譯器編譯後的代碼等數據。Hotspot中的“永久代”。
- 運行時常量池：方法區的一部分，存儲常量信息，如各種字面量、符號引用等。
- 直接內存：並不是JVM運行時數據區的一部分， 可直接訪問的內存， 比如NIO會用到這部分。
按照JVM規范，除瞭程序計數器不會拋出OOM外，其他各個內存區域都可能會拋出OOM。
最常見的OOM情況有以下三種：
- java.lang.OutOfMemoryError: Java heap space ——>java堆內存溢出，此種情況最常見，一般由於內存泄露或者堆的大小設置不當引起。對於內存泄露，需要通過內存監控軟件查找程序中的泄露代碼，而堆大小可以通過虛擬機參數-Xms,-Xmx等修改。
- java.lang.OutOfMemoryError: PermGen space ——>java永久代溢出，即方法區溢出瞭，一般出現於大量Class或者jsp頁面，或者采用cglib等反射機制的情況，因為上述情況會產生大量的Class信息存儲於方法區。此種情況可以通過更改方法區的大小來解決，使用類似-XX:PermSize=64m -XX:MaxPermSize=256m的形式修改。另外，過多的常量尤其是字符串也會導致方法區溢出。
- java.lang.StackOverflowError ——> 不會拋OOM error，但也是比較常見的Java內存溢出。JAVA虛擬機棧溢出，一般是由於程序中存在死循環或者深度遞歸調用造成的，棧大小設置太小也會出現此種溢出。可以通過虛擬機參數-Xss來設置棧的大小。
4）OOM分析–heapdump
要dump堆的內存鏡像，可以采用如下兩種方式：
- 設置JVM參數-XX:+HeapDumpOnOutOfMemoryError，設定當發生OOM時自動dump出堆信息。不過該方法需要JDK5以上版本。
- 使用JDK自帶的jmap命令。”jmap -dump:format=b,file=heap.bin <pid>” 其中pid可以通過jps獲取。
dump堆內存信息後，需要對dump出的文件進行分析，從而找到OOM的原因。常用的工具有：
- mat: eclipse memory analyzer, 基於eclipse RCP的內存分析工具。詳細信息參見：http://www.eclipse.org/mat/，推薦使用。
- jhat：JDK自帶的java heap analyze tool，可以將堆中的對象以html的形式顯示出來，包括對象的數量，大小等等，並支持對象查詢語言OQL，分析相關的應用後，可以通過http://localhost:7000來訪問分析結果。不推薦使用，因為在實際的排查過程中，一般是先在生產環境 dump出文件來，然後拉到自己的開發機器上分析，所以，不如采用高級的分析工具比如前面的mat來的高效。
這個鏈接：https://developer.ibm.com/alert-zh/中提供瞭一個采用mat分析的例子 。
註意：因為JVM規范沒有對dump出的文件的格式進行定義，所以不同的虛擬機產生的dump文件並不是一樣的。在分析時，需要針對不同的虛擬機的輸出采用不同的分析工具（當然，有的工具可以兼容多個虛擬機的格式）。IBM HeapAnalyzer也是分析heap的一個常用的工具。
到此這篇關於Java OOM原因以及解決方案的文章就介紹到這瞭,更多相關Java OOM內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！