最近在aliyun上crontab里放的一個java腳本把機器搞翻了，ssh連不上T_T 發現OOM了，真是無語。并不懂Java的內存模型，轉一篇備用吧。
轉載自：http://www.cnblogs.com/gaojing/archive/2012/10/30/2844938.html
最近查找了很多關于OOM，甚至于Java內存管理以及JVM的相關資料，發現這方面的東西太多了，竟有一種眼花繚亂的感覺，要想了解全面的話，恐非一篇文章能說清的，因此按照自己的理解整理了一篇，剩下的還需要繼續學習。
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規范沒有對dump出的文件的格式進行定義，所以不同的虛擬機產生的dump文件并不是一樣的。在分析時，需要針對不同的虛擬機的輸出采用不同的分析工具（當然，有的工具可以兼容多個虛擬機的格式）。IBM HeapAnalyzer也是分析heap的一個常用的工具。 5）小結 涉及到的虛擬機的技術或者工具，往往需要考慮到虛擬機規范以及不同的虛擬機實現。尤其是針對虛擬機調優時，往往需要針對虛擬機在某些方面的實現策略來考慮，比如，不同的虛擬機的垃圾回收算法是不一樣的，而這直接影響了虛擬機某些參數的設置，以達到虛擬機的最佳性能。
設置JVM參數-XX:+HeapDumpOnOutOfMemoryError，設定當發生OOM時自動dump出堆信息。不過該方法需要JDK5以上版本。
使用JDK自帶的jmap命令。"jmap -dump:format=b,file=heap.bin
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來的高效。
這個鏈接：http://www.ibm.com/developerworks/cn/opensource/os-cn-ecl-ma/index.html中提供了一個采用mat分析的例子 。
而針對JVM運行時的分析與診斷，則需要掌握分析基本方法，針對具體情況，運用虛擬機的原理，具體分析。一句話，水很深啊。
文章列表
留言列表
