這篇文章，我們來講一下JVM中最常見，也是最嚴重的性能問題OOM。

首先，我們得知道，什么是OOM。

OOM是OutOfMemoryError的英文縮寫，通俗的講，就是內(nèi)存溢出錯誤。上次，我們說到JVM中有GC資源回收機制，會對新生代、老年代、元空間這些內(nèi)存比較大的區(qū)域進行回收，提高內(nèi)存的復用率，為什么還會出現(xiàn)內(nèi)存溢出錯誤呢？

說到內(nèi)存溢出，我們得先說它的孿生兄弟內(nèi)存泄露。JAVA程序在啟動時，從內(nèi)存條中申請了一段內(nèi)存空間，程序在運行過程中，就把新對象丟到這段內(nèi)存空間中，然后，使用GC資源回收策略，釋放被占用的內(nèi)存空間，這是理想中的狀態(tài)。但是，在實際項目中，經(jīng)常會出現(xiàn)一些意外情況，如某一對象進入JVM的內(nèi)存空間后，生命周期特別長，長到成為了‘老賴’，雖然有GC資源回收，但是，對于老賴也無能為力，回收不了。如果，這樣的‘老賴’很少，還無所謂，但是，一旦多了起來，就導致，剩余可用的內(nèi)存空間越來越少，這樣一種現(xiàn)象，就稱為‘內(nèi)存泄露’。如果此時程序運行過程中，有一個比較大的對象，需要一個比較大的內(nèi)存空間來存放，此時，剩余的內(nèi)存不足夠存放這個大對象，這時，就內(nèi)存溢出就出現(xiàn)了。

所以，內(nèi)存溢出，

• 有可能是代碼問題，申請了過多對象駐留在內(nèi)存中；
• 也可能是申請的對象太大，大于剩余內(nèi)存空間；
• 也可能是程序申請的內(nèi)存空間太小；
• 也可能是JVM內(nèi)存堆棧配置參數(shù)不合理；
• 也可能是GC資源回收策略不合理；
• 也可能是操作系統(tǒng)參數(shù)限制。

這些，是從概念的理解上，就能推斷出來的可能原因，當然，實際項目，可能性會更多，但是，我們把這些先搞定，那OOM的問題就不是大問題了。

接下來，我們看下常見的OOM錯誤都有哪些？

• java.lang.OutOfMemoryError: Java heap space

這個錯誤，相信大家都不陌生，錯誤信息中，明確提示了java堆空間。堆空間不夠用了。可能是程序運行過程中，申請了很多對象放在內(nèi)存中，這些對象又都還‘活’著，不能被GC回收，導致剩余可用堆空間不夠用。或者JVM配置的堆太小，程序運行過程中，堆空間不夠用。

• java.lang.OutOfMemoryError: GC overhead limit exceeded

出現(xiàn)這個錯誤，其原因是多次GC的效率非常低。內(nèi)存空間不夠用，通過GC來回收空間，但是，多次回收的效率非常低，幾乎沒有效果，所以，就報了這個錯誤，出現(xiàn)這個錯誤，一般是堆空間配置太小。

• java.lang.OutOfMemoryError: Requested array size exceeds VM limit

這個錯誤信息比較明確，數(shù)組對象大小超過了VM的限制，也就是說新對象太大。對于這個問題，先確認下是否是代碼bug，真有必要申請這么大的對象嗎？如果確認要申請大對象，那就調(diào)大JVM的堆空間大小。

• java.lang.OutOfMemoryError: MetaSpace

提示信息中明確說了，是元空間。如果JDK低于1.8，提示的就是Permgen space永久代。永久代元空間里面存放的是類信息和常量池。一般來說，這些對象都不會特別大，所以，這個錯誤，比較少見。出現(xiàn)這個錯誤，我們可以調(diào)大JVM的MaxPermSize的值(JDK<1.8)或MaxMeteSpaceSize的值(JDK≥1.8)。

• java.lang.OutOfMemoryError: Unable to create native threads

這個錯誤，字面意思很好理解，就是不能再創(chuàng)建活躍的線程了，但是，涉及的知識面卻很廣。

首先，任何一個程序能創(chuàng)建的進程和線程的總數(shù)量，受操作系統(tǒng)參數(shù)限制，這個可以查看程序啟動后，內(nèi)存文件limit，在這個文件中，可以看到線程值，如果此時程序參數(shù)都進程加線程的總數(shù)達到了這個限制值，就會出現(xiàn)上面的錯誤，如果是這個限制參數(shù)的原因，可以臨時調(diào)大系統(tǒng)限制參數(shù)值，然后重啟服務解決，當然，這種概率比較低，一般只會在高并發(fā)業(yè)務中才可能出現(xiàn)；

然后，我們還得知道，進程是資源的擁有者，線程只是使用資源，但是，每個線程都有自己的線程棧，這個線程棧在JVM中是有限制的，超了也會報上面的錯誤，如果是這樣，一般還會伴隨StackOverflowError錯誤，這個就需要調(diào)整-Xss線程棧的值。

• java.lang.OutOfMemoryError: Direct buffer memory

Java 允許應用程序通過 Direct ByteBuffer 直接訪問堆外內(nèi)存，許多高性能程序通過 Direct ByteBuffer 結(jié)合內(nèi)存映射文件（Memory MApped File）實現(xiàn)高速 IO，但是它默認只有64MB，出現(xiàn)上面錯誤，可以調(diào)大-XX:MaxDirectMemorySize的大小，然后，去掉-XX:DisableExplicitGC配置

• java.lang.OutOfMemoryError: Request size bytes for reason. Out of swap space

哈哈，這個錯誤要是被你遇到了。那我可得恭喜你，準備停機接受檢查吧！這個錯誤什么意思呢，就是說一直在申請內(nèi)存空間，把交換分區(qū)的空間都用光了。啥意思？咋來了個交換分區(qū)呢？交換分區(qū)，它是磁盤虛擬出來的，用來臨時轉(zhuǎn)存內(nèi)存空間數(shù)據(jù)的，當內(nèi)存不夠用到時候，才會把內(nèi)存中的數(shù)據(jù)轉(zhuǎn)存到交換分區(qū)，以騰出內(nèi)存空間。你現(xiàn)在不但內(nèi)存空間不夠用，交換分區(qū)空間都不夠用了，哪還有內(nèi)存啊，機器隨時都可能‘嗝屁’。這種問題，要停掉一些其他程序，然后，仔細分析項目的堆棧信息，定位問題并解決。

現(xiàn)在，我們來看看怎么獲取和分析OOM堆棧信息

首先，我們要明白，OOM是程序內(nèi)存問題，出現(xiàn)這樣的錯誤，很多時候，已經(jīng)導致程序沒有足夠的內(nèi)存去打印日志，所以，程序日志中不一定會有OOM的錯誤信息。但是，在遇到OOM問題時，我們需要OOM的錯誤信息，才能判斷問題所在，所以，往往需要借助一些外部工具。

• 在JVM的配置參數(shù)中添加打印參數(shù)

在JVM的配置參數(shù)中添加-XX:+
HeapDumpOnOutOfMemoryError，添加這個參數(shù)，JVM一旦出現(xiàn)OOM問題，就會打印出錯誤信息，但是，這個參數(shù)一般在開發(fā)和測試時才用，請不要用于生產(chǎn)環(huán)境。

• 使用JDK自帶工具jmap

JDK是java開發(fā)工具包集，它自帶了jmap工具，使用jmap -dump:format=b,file=oom.bin pid的命令格式，可以dump下OOM信息。這是比較經(jīng)典的做法，但是，如果堆棧比較大時，這個命令執(zhí)行時間可能會非常長。

• 使用開源的arthas工具

arthas是阿里開源和維護的一款java分析工具集，是java程序性能分析的高效工具。使用這個工具，直接使用heapdump命令，就能方便快速的dump下OOM信息，無論堆棧多大，dump的速度都非常快。

• 使用阿里云的ARMS

如果你的云服務器是阿里的，可以付費使用ARMS監(jiān)控系統(tǒng)，這是一整套監(jiān)控系統(tǒng)，通過這個監(jiān)控系統(tǒng)，可以觀察到OOM信息。

獲取到了OOM信息之后，一般會使用MAT工具進行分析。如果你有java基礎(chǔ)，你可以自己下載MAT工具進行分析，如果沒有，也可以把dump下的OOM信息給開發(fā)人員進行分析。