示例

下面的代碼初始化一個map并在無限循環(huán)中不停的添加鍵值對，運行后將會拋出GC overhead limit exceeded錯誤：

public class Wrapper {
    public static void main(String args[]) throws Exception {
        Map map = System.getProperties();
        Random r = new Random();
        while (true) {
            map.put(r.nextInt(), "value");
        }
    }
}

正如你所預(yù)料的那樣，程序不能正常的結(jié)束，事實上，當(dāng)我們使用如下參數(shù)啟動程序時：

java -Xmx100m -XX:+UseParallelGC Wrapper

我們很快就可以看到程序拋出java.lang.OutOfMemoryError: GC overhead limit exceeded錯誤。但如果在啟動時設(shè)置不同的堆空間大小或者使用不同的GC算法，比如這樣：

java -Xmx10m -XX:+UseParallelGC Wrapper

我們將看到如下錯誤：

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.util.Hashtable.rehash(Unknown Source)
    at java.util.Hashtable.addEntry(Unknown Source)
    at java.util.Hashtable.put(Unknown Source)
    at cn.moondev.Wrapper.main(Wrapper.java:12)

使用以下GC算法：-XX:+UseConcMarkSweepGC 或者-XX:+UseG1GC，啟動命令如下：

java -Xmx100m -XX:+UseConcMarkSweepGC Wrapper
java -Xmx100m -XX:+UseG1GC Wrapper

得到的結(jié)果是這樣的：

Exception: java.lang.OutOfMemoryError thrown from 
the UncaughtExceptionHandler in thread "main"

錯誤已經(jīng)被默認(rèn)的異常處理程序捕獲，并且沒有任何錯誤的堆棧信息輸出。

以上這些變化可以說明，在資源有限的情況下，你根本無法無法預(yù)測你的應(yīng)用是怎樣掛掉的，什么時候會掛掉，所以在開發(fā)時，你不能僅僅保證自己的應(yīng)用程序在特定的環(huán)境下正常運行。

解決方案

首先是一個毫無誠意的解決方案，如果你僅僅是不想看到java.lang.OutOfMemoryError:GC overhead limit exceeded的錯誤信息，可以在應(yīng)用程序啟動時添加如下JVM參數(shù)：

-XX:-UseGCOverheadLimit

但是強烈建議不要使用這個選項，因為這樣并沒有解決任何問題，只是推遲了錯誤出現(xiàn)的時間，錯誤信息也變成了我們更熟悉的java.lang.OutOfMemoryError: Java heap space而已。

另一個解決方案，如果你的應(yīng)用程序確實內(nèi)存不足，增加堆內(nèi)存會解決GC overhead limit問題，就如下面這樣，給你的應(yīng)用程序1G的堆內(nèi)存：

java -Xmx1024m com.yourcompany.YourClass

但如果你想確保你已經(jīng)解決了潛在的問題，而不是掩蓋java.lang.OutOfMemoryError: GC overhead limit exceeded錯誤，那么你不應(yīng)該僅止步于此。你要記得還有profilers和memory dump analyzers這些工具，你需要花費更多的時間和精力來查找問題。還有一點需要注意，這些工具在Java運行時有顯著的開銷，因此不建議在生產(chǎn)環(huán)境中使用。

3、java.lang.OutOfMemoryError:Permgen space

Java中堆空間是JVM管理的最大一塊內(nèi)存空間，可以在JVM啟動時指定堆空間的大小，其中堆被劃分成兩個不同的區(qū)域：新生代（Young）和老年代（Tenured），新生代又被劃分為3個區(qū)域：Eden、From Survivor、To Survivor，如下圖所示。

圖片來源：并發(fā)編程網(wǎng).png

java.lang.OutOfMemoryError: PermGen space錯誤就表明持久代所在區(qū)域的內(nèi)存已被耗盡。

原因分析

要理解java.lang.OutOfMemoryError: PermGen space出現(xiàn)的原因，首先需要理解Permanent Generation Space的用處是什么。持久代主要存儲的是每個類的信息，比如：類加載器引用、運行時常量池（所有常量、字段引用、方法引用、屬性）、字段(Field)數(shù)據(jù)、方法(Method)數(shù)據(jù)、方法代碼、方法字節(jié)碼等等。我們可以推斷出，PermGen的大小取決于被加載類的數(shù)量以及類的大小。

因此，我們可以得出出現(xiàn)java.lang.OutOfMemoryError: PermGen space錯誤的原因是：太多的類或者太大的類被加載到permanent generation（持久代）。

示例

①、最簡單的示例

正如前面所描述的，PermGen的使用與加載到JVM類的數(shù)量有密切關(guān)系，下面是一個最簡單的示例：

import javassist.ClassPool;
public class MicroGenerator {
    public static void main(String[] args) throws Exception {
        for (int i = 0; i < 100_000_000; i++) {
            generate("cn.moondev.User" + i);
        }
    }

    public static Class generate(String name) throws Exception {
        ClassPool pool = ClassPool.getDefault();
        return pool.makeClass(name).toClass();
    }
}

運行時請設(shè)置JVM參數(shù)：-XX:MaxPermSize=5m，值越小越好。需要注意的是JDK8已經(jīng)完全移除持久代空間，取而代之的是元空間（Metaspace），所以示例最好的JDK1.7或者1.6下運行。

代碼在運行時不停的生成類并加載到持久代中，直到撐滿持久代內(nèi)存空間，最后拋出java.lang.OutOfMemoryError:Permgen space。代碼中類的生成使用了javassist庫。

②、Redeploy-time

更復(fù)雜和實際的一個例子就是Redeploy（重新部署，你可以想象一下你開發(fā)時，點擊eclipse的reploy按鈕或者使用idea時按ctrl + F5時的過程）。在從服務(wù)器卸載應(yīng)用程序時，當(dāng)前的classloader以及加載的class在沒有實例引用的情況下，持久代的內(nèi)存空間會被GC清理并回收。如果應(yīng)用中有類的實例對當(dāng)前的classloader的引用，那么Permgen區(qū)的class將無法被卸載，導(dǎo)致Permgen區(qū)的內(nèi)存一直增加直到出現(xiàn)Permgen space錯誤。

不幸的是，許多第三方庫以及糟糕的資源處理方式（比如：線程、JDBC驅(qū)動程序、文件系統(tǒng)句柄）使得卸載以前使用的類加載器變成了一件不可能的事。反過來就意味著在每次重新部署過程中，應(yīng)用程序所有的類的先前版本將仍然駐留在Permgen區(qū)中，你的每次部署都將生成幾十甚至幾百M的垃圾。

就以線程和JDBC驅(qū)動來說說。很多人都會使用線程來處理一下周期性或者耗時較長的任務(wù)，這個時候一定要注意線程的生命周期問題，你需要確保線程不能比你的應(yīng)用程序活得還長。否則，如果應(yīng)用程序已經(jīng)被卸載，線程還在繼續(xù)運行，這個線程通常會維持對應(yīng)用程序的classloader的引用，造成的結(jié)果就不再多說。多說一句，開發(fā)者有責(zé)任處理好這個問題，特別是如果你是第三方庫的提供者的話，一定要提供線程關(guān)閉接口來處理清理工作。

讓我們想象一個使用JDBC驅(qū)動程序連接到關(guān)系數(shù)據(jù)庫的示例應(yīng)用程序。當(dāng)應(yīng)用程序部署到服務(wù)器上的時：服務(wù)器創(chuàng)建一個classloader實例來加載應(yīng)用所有的類（包含相應(yīng)的JDBC驅(qū)動）。根據(jù)JDBC規(guī)范，JDBC驅(qū)動程序（比如：com.mysql.jdbc.Driver）會在初始化時將自己注冊到java.sql.DriverManager中。該注冊過程中會將驅(qū)動程序的一個實例存儲在DriverManager的靜態(tài)字段內(nèi)，代碼可以參考：

// com.mysql.jdbc.Driver源碼
package com.mysql.jdbc;

public class Driver extends NonRegisteringDriver implements java.sql.Driver {
    public Driver() throws SQLException {
    }
    static {
        try {
            DriverManager.registerDriver(new Driver());
        } catch (SQLException var1) {
            throw new RuntimeException("Can\'t register driver!");
        }
    }
}
// // // // // // // // // //
// 再看下DriverManager對應(yīng)代碼
private final static CopyOnWriteArrayList<DriverInfo> registeredDrivers = new CopyOnWriteArrayList<>();

public static synchronized void registerDriver(java.sql.Driver driver,DriverAction da) throws SQLException {
    if(driver != null) {
        registeredDrivers.addIfAbsent(new DriverInfo(driver, da));
    } else {
        throw new NullPointerException();
    }
}

現(xiàn)在，當(dāng)從服務(wù)器上卸載應(yīng)用程序的時候，java.sql.DriverManager仍將持有那個驅(qū)動程序的引用，進而持有用于加載應(yīng)用程序的classloader的一個實例的引用。這個classloader現(xiàn)在仍然引用著應(yīng)用程序的所有類。如果此程序啟動時需要加載2000個類，占用約10MB永久代（PermGen）內(nèi)存，那么只需要5~10次重新部署，就會將默認(rèn)大小的永久代（PermGen）塞滿，然后就會觸發(fā)java.lang.OutOfMemoryError: PermGen space錯誤并崩潰。

解決方案

① 解決初始化時的OutOfMemoryError

當(dāng)在應(yīng)用程序啟動期間觸發(fā)由于PermGen耗盡引起的OutOfMemoryError時，解決方案很簡單。 應(yīng)用程序需要更多的空間來加載所有的類到PermGen區(qū)域，所以我們只需要增加它的大小。 為此，請更改應(yīng)用程序啟動配置，并添加（或增加，如果存在）-XX：MaxPermSize參數(shù)，類似于以下示例：

java -XX:MaxPermSize=512m com.yourcompany.YourClass

② 解決Redeploy時的OutOfMemoryError

分析dump文件：首先，找出引用在哪里被持有；其次，給你的web應(yīng)用程序添加一個關(guān)閉的hook，或者在應(yīng)用程序卸載后移除引用。你可以使用如下命令導(dǎo)出dump文件：

jmap -dump:format=b,file=dump.hprof <process-id>

如果是你自己代碼的問題請及時修改，如果是第三方庫，請試著搜索一下是否存在"關(guān)閉"接口，如果沒有給開發(fā)者提交一個bug或者issue吧。

③ 解決運行時OutOfMemoryError

首先你需要檢查是否允許GC從PermGen卸載類，JVM的標(biāo)準(zhǔn)配置相當(dāng)保守，只要類一創(chuàng)建，即使已經(jīng)沒有實例引用它們，其仍將保留在內(nèi)存中，特別是當(dāng)應(yīng)用程序需要動態(tài)創(chuàng)建大量的類但其生命周期并不長時，允許JVM卸載類對應(yīng)用大有助益，你可以通過在啟動腳本中添加以下配置參數(shù)來實現(xiàn)：

-XX:+CMSClassUnloadingEnabled

默認(rèn)情況下，這個配置是未啟用的，如果你啟用它，GC將掃描PermGen區(qū)并清理已經(jīng)不再使用的類。但請注意，這個配置只在UseConcMarkSweepGC的情況下生效，如果你使用其他GC算法，比如：ParallelGC或者Serial GC時，這個配置無效。所以使用以上配置時，請配合：

-XX:+UseConcMarkSweepGC

如果你已經(jīng)確保JVM可以卸載類，但是仍然出現(xiàn)內(nèi)存溢出問題，那么你應(yīng)該繼續(xù)分析dump文件，使用以下命令生成dump文件：

jmap -dump:file=dump.hprof,format=b <process-id>

當(dāng)你拿到生成的堆轉(zhuǎn)儲文件，并利用像Eclipse Memory Analyzer Toolkit這樣的工具來尋找應(yīng)該卸載卻沒被卸載的類加載器，然后對該類加載器加載的類進行排查，找到可疑對象，分析使用或者生成這些類的代碼，查找產(chǎn)生問題的根源并解決它。

4、java.lang.OutOfMemoryError:Metaspace

前文已經(jīng)提過，PermGen區(qū)域用于存儲類的名稱和字段，類的方法，方法的字節(jié)碼，常量池，JIT優(yōu)化等，但從Java8開始，Java中的內(nèi)存模型發(fā)生了重大變化：引入了稱為Metaspace的新內(nèi)存區(qū)域，而刪除了PermGen區(qū)域。請注意：不是簡單的將PermGen區(qū)所存儲的內(nèi)容直接移到Metaspace區(qū)，PermGen區(qū)中的某些部分，已經(jīng)移動到了普通堆里面。

OOM-example-metaspace，圖片來源：Plumbr

原因分析

Java8做出如此改變的原因包括但不限于：

• 應(yīng)用程序所需要的PermGen區(qū)大小很難預(yù)測，設(shè)置太小會觸發(fā)PermGen OutOfMemoryError錯誤，過度設(shè)置導(dǎo)致資源浪費。
• 提升GC性能，在HotSpot中的每個垃圾收集器需要專門的代碼來處理存儲在PermGen中的類的元數(shù)據(jù)信息。從PermGen分離類的元數(shù)據(jù)信息到Metaspace，由于Metaspace的分配具有和Java Heap相同的地址空間，因此Metaspace和Java Heap可以無縫的管理，而且簡化了FullGC的過程，以至將來可以并行的對元數(shù)據(jù)信息進行垃圾收集，而沒有GC暫停。
• 支持進一步優(yōu)化，比如：G1并發(fā)類的卸載，也算為將來做準(zhǔn)備吧

正如你所看到的，元空間大小的要求取決于加載的類的數(shù)量以及這種類聲明的大小。 所以很容易看到java.lang.OutOfMemoryError: Metaspace主要原因：太多的類或太大的類加載到元空間。

示例

正如上文中所解釋的，元空間的使用與加載到JVM中的類的數(shù)量密切相關(guān)。 下面的代碼是最簡單的例子：

public class Metaspace {
    static javassist.ClassPool cp = javassist.ClassPool.getDefault();

    public static void main(String[] args) throws Exception{
        for (int i = 0; ; i++) { 
            Class c = cp.makeClass("eu.plumbr.demo.Generated" + i).toClass();
            System.out.println(i);
        }
    }
}

程序運行中不停的生成新類，所有的這些類的定義將被加載到Metaspace區(qū)，直到空間被完全占用并且拋出java.lang.OutOfMemoryError:Metaspace。當(dāng)使用-XX：MaxMetaspaceSize = 32m啟動時，大約加載30000多個類時就會死機。

31023
31024
Exception in thread "main" javassist.CannotCompileException: by java.lang.OutOfMemoryError: Metaspace
    at javassist.ClassPool.toClass(ClassPool.java:1170)
    at javassist.ClassPool.toClass(ClassPool.java:1113)
    at javassist.ClassPool.toClass(ClassPool.java:1071)
    at javassist.CtClass.toClass(CtClass.java:1275)
    at cn.moondev.book.Metaspace.main(Metaspace.java:12)
    .....

解決方案

第一個解決方案是顯而易見的，既然應(yīng)用程序會耗盡內(nèi)存中的Metaspace區(qū)空間，那么應(yīng)該增加其大小，更改啟動配置增加如下參數(shù)：

// 告訴JVM：Metaspace允許增長到512，然后才能拋出異常
-XX：MaxMetaspaceSize = 512m

另一個方法就是刪除此參數(shù)來完全解除對Metaspace大小的限制（默認(rèn)是沒有限制的）。默認(rèn)情況下，對于64位服務(wù)器端JVM，MetaspaceSize默認(rèn)大小是21M（初始限制值），一旦達(dá)到這個限制值，F(xiàn)ullGC將被觸發(fā)進行類卸載，并且這個限制值將會被重置，新的限制值依賴于Metaspace的剩余容量。如果沒有足夠空間被釋放，這個限制值將會上升，反之亦然。在技術(shù)上Metaspace的尺寸可以增長到交換空間，而這個時候本地內(nèi)存分配將會失?。ǜ唧w的分析，可以參考：Java PermGen 去哪里了?）。

你可以通過修改各種啟動參數(shù)來“快速修復(fù)”這些內(nèi)存溢出錯誤，但你需要正確區(qū)分你是否只是推遲或者隱藏了java.lang.OutOfMemoryError的癥狀。如果你的應(yīng)用程序確實存在內(nèi)存泄漏或者本來就加載了一些不合理的類，那么所有這些配置都只是推遲問題出現(xiàn)的時間而已，實際也不會改善任何東西。

5、java.lang.OutOfMemoryError:Unable to create new native thread

一個思考線程的方法是將線程看著是執(zhí)行任務(wù)的工人，如果你只有一個工人，那么他同時只能執(zhí)行一項任務(wù)，但如果你有十幾個工人，就可以同時完成你幾個任務(wù)。就像這些工人都在物理世界，JVM中的線程完成自己的工作也是需要一些空間的，當(dāng)有足夠多的線程卻沒有那么多的空間時就會像這樣：

image.png

出現(xiàn)java.lang.OutOfMemoryError:Unable to create new native thread就意味著Java應(yīng)用程序已達(dá)到其可以啟動線程數(shù)量的極限了。

原因分析

當(dāng)JVM向OS請求創(chuàng)建一個新線程時，而OS卻無法創(chuàng)建新的native線程時就會拋出Unable to create new native thread錯誤。一臺服務(wù)器可以創(chuàng)建的線程數(shù)依賴于物理配置和平臺，建議運行下文中的示例代碼來測試找出這些限制?？傮w上來說，拋出此錯誤會經(jīng)過以下幾個階段：

• 運行在JVM內(nèi)的應(yīng)用程序請求創(chuàng)建一個新的線程
• JVM向OS請求創(chuàng)建一個新的native線程
• OS嘗試創(chuàng)建一個新的native線程，這時需要分配內(nèi)存給新的線程
• OS拒絕分配內(nèi)存給線程，因為32位Java進程已經(jīng)耗盡內(nèi)存地址空間（2-4GB內(nèi)存地址已被命中）或者OS的虛擬內(nèi)存已經(jīng)完全耗盡
• Unable to create new native thread錯誤將被拋出

示例

下面的示例不能的創(chuàng)建并啟動新的線程。當(dāng)代碼運行時，很快達(dá)到OS的線程數(shù)限制，并拋出Unable to create new native thread錯誤。

while(true){
    new Thread(new Runnable(){
        public void run() {
            try {
                Thread.sleep(10000000);
            } catch(InterruptedException e) { }        
        }    
    }).start();
}

解決方案

有時，你可以通過在OS級別增加線程數(shù)限制來繞過這個錯誤。如果你限制了JVM可在用戶空間創(chuàng)建的線程數(shù)，那么你可以檢查并增加這個限制：

// macOS 10.12上執(zhí)行
$ ulimit -u
709

當(dāng)你的應(yīng)用程序產(chǎn)生成千上萬的線程，并拋出此異常，表示你的程序已經(jīng)出現(xiàn)了很嚴(yán)重的編程錯誤，我不覺得應(yīng)該通過修改參數(shù)來解決這個問題，不管是OS級別的參數(shù)還是JVM啟動參數(shù)。更可取的辦法是分析你的應(yīng)用是否真的需要創(chuàng)建如此多的線程來完成任務(wù)？是否可以使用線程池或者說線程池的數(shù)量是否合適？是否可以更合理的拆分業(yè)務(wù)來實現(xiàn).....

6、java.lang.OutOfMemoryError:Out of swap space?

Java應(yīng)用程序在啟動時會指定所需要的內(nèi)存大小，可以通過-Xmx和其他類似的啟動參數(shù)來指定。在JVM請求的總內(nèi)存大于可用物理內(nèi)存的情況下，操作系統(tǒng)會將內(nèi)存中的數(shù)據(jù)交換到磁盤上去。

圖片來源：plumbr

Out of swap space?表示交換空間也將耗盡，并且由于缺少物理內(nèi)存和交換空間，再次嘗試分配內(nèi)存也將失敗。

原因分析

當(dāng)應(yīng)用程序向JVM native heap請求分配內(nèi)存失敗并且native heap也即將耗盡時，JVM會拋出Out of swap space錯誤。該錯誤消息中包含分配失敗的大?。ㄒ宰止?jié)為單位）和請求失敗的原因。

Native Heap Memory是JVM內(nèi)部使用的Memory，這部分的Memory可以通過JDK提供的JNI的方式去訪問，這部分Memory效率很高，但是管理需要自己去做，如果沒有把握最好不要使用，以防出現(xiàn)內(nèi)存泄露問題。JVM 使用Native Heap Memory用來優(yōu)化代碼載入（JTI代碼生成），臨時對象空間申請，以及JVM內(nèi)部的一些操作。

這個問題往往發(fā)生在Java進程已經(jīng)開始交換的情況下，現(xiàn)代的GC算法已經(jīng)做得足夠好了，當(dāng)時當(dāng)面臨由于交換引起的延遲問題時，GC暫停的時間往往會讓大多數(shù)應(yīng)用程序不能容忍。

java.lang.OutOfMemoryError:Out of swap space?往往是由操作系統(tǒng)級別的問題引起的，例如：

• 操作系統(tǒng)配置的交換空間不足。
• 系統(tǒng)上的另一個進程消耗所有內(nèi)存資源。

還有可能是本地內(nèi)存泄漏導(dǎo)致應(yīng)用程序失敗，比如：應(yīng)用程序調(diào)用了native code連續(xù)分配內(nèi)存，但卻沒有被釋放。

解決方案

解決這個問題有幾個辦法，通常最簡單的方法就是增加交換空間，不同平臺實現(xiàn)的方式會有所不同，比如在Linux下可以通過如下命令實現(xiàn)：

# 原作者使用，由于我手里并沒有Linux環(huán)境，所以并未測試
# 創(chuàng)建并附加一個大小為640MB的新交換文件
swapoff -a 
dd if=/dev/zero of=swapfile bs=1024 count=655360
mkswap swapfile
swapon swapfile

Java GC會掃描內(nèi)存中的數(shù)據(jù)，如果是對交換空間運行垃圾回收算法會使GC暫停的時間增加幾個數(shù)量級，因此你應(yīng)該慎重考慮使用上文增加交換空間的方法。

如果你的應(yīng)用程序部署在JVM需要同其他進程激烈競爭獲取資源的物理機上，建議將服務(wù)隔離到單獨的虛擬機中

但在許多情況下，您唯一真正可行的替代方案是：

• 升級機器以包含更多內(nèi)存
• 優(yōu)化應(yīng)用程序以減少其內(nèi)存占用

當(dāng)您轉(zhuǎn)向優(yōu)化路徑時，使用內(nèi)存轉(zhuǎn)儲分析程序來檢測內(nèi)存中的大分配是一個好的開始。

7、java.lang.OutOfMemoryError:Requested array size exceeds VM limit

Java對應(yīng)用程序可以分配的最大數(shù)組大小有限制。不同平臺限制有所不同，但通常在1到21億個元素之間。

圖片來源：plumbr

當(dāng)你遇到Requested array size exceeds VM limit錯誤時，意味著你的應(yīng)用程序試圖分配大于Java虛擬機可以支持的數(shù)組。

原因分析

該錯誤由JVM中的native code拋出。 JVM在為數(shù)組分配內(nèi)存之前，會執(zhí)行特定于平臺的檢查：分配的數(shù)據(jù)結(jié)構(gòu)是否在此平臺中是可尋址的。

你很少見到這個錯誤是因為Java數(shù)組的索引是int類型。 Java中的最大正整數(shù)為2 ^ 31 - 1 = 2,147,483,647。 并且平臺特定的限制可以非常接近這個數(shù)字，例如：我的環(huán)境上(64位macOS，運行Jdk1.8)可以初始化數(shù)組的長度高達(dá)2,147,483,645（Integer.MAX_VALUE-2）。如果再將數(shù)組的長度增加1到Integer.MAX_VALUE-1會導(dǎo)致熟悉的OutOfMemoryError：

Exception in thread "main" java.lang.OutOfMemoryError: Requested array size exceeds VM limit

但是，在使用OpenJDK 6的32位Linux上，在分配具有大約11億個元素的數(shù)組時，您將遇到Requested array size exceeded VM limit的錯誤。 要理解你的特定環(huán)境的限制，運行下文中描述的小測試程序。

示例

for (int i = 3; i >= 0; i--) {
    try {
        int[] arr = new int[Integer.MAX_VALUE-i];
        System.out.format("Successfully initialized an array with %,d elements.\n", Integer.MAX_VALUE-i);
    } catch (Throwable t) {
        t.printStackTrace();
    }
}

該示例重復(fù)四次，并在每個回合中初始化一個長原語數(shù)組。 該程序嘗試初始化的數(shù)組的大小在每次迭代時增加1，最終達(dá)到Integer.MAX_VALUE。 現(xiàn)在，當(dāng)使用Hotspot 7在64位Mac OS X上啟動代碼片段時，應(yīng)該得到類似于以下內(nèi)容的輸出：

java.lang.OutOfMemoryError: Java heap space
    at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)
java.lang.OutOfMemoryError: Java heap space
    at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)
java.lang.OutOfMemoryError: Requested array size exceeds VM limit
    at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)
java.lang.OutOfMemoryError: Requested array size exceeds VM limit
    at eu.plumbr.demo.ArraySize.main(ArraySize.java:8)

注意，在出現(xiàn)Requested array size exceeded VM limit之前，出現(xiàn)了更熟悉的java.lang.OutOfMemoryError: Java heap space。 這是因為初始化2 ^ 31-1個元素的數(shù)組需要騰出8G的內(nèi)存空間，大于JVM使用的默認(rèn)值。

解決方案

java.lang.OutOfMemoryError:Requested array size exceeds VM limit可能會在以下任一情況下出現(xiàn)：

• 數(shù)組增長太大，最終大小在平臺限制和Integer.MAX_INT之間
• 你有意分配大于2 ^ 31-1個元素的數(shù)組

在第一種情況下，檢查你的代碼庫，看看你是否真的需要這么大的數(shù)組。也許你可以減少數(shù)組的大小，或者將數(shù)組分成更小的數(shù)據(jù)塊，然后分批處理數(shù)據(jù)。

在第二種情況下，記住Java數(shù)組是由int索引的。因此，當(dāng)在平臺中使用標(biāo)準(zhǔn)數(shù)據(jù)結(jié)構(gòu)時，數(shù)組不能超過2 ^ 31-1個元素。事實上，在編譯時就會出錯：error：integer number too large。

8、Out of memory:Kill process or sacrifice child

為了理解這個錯誤，我們需要補充一點操作系統(tǒng)的基礎(chǔ)知識。操作系統(tǒng)是建立在進程的概念之上，這些進程在內(nèi)核中作業(yè)，其中有一個非常特殊的進程，名叫“內(nèi)存殺手（Out of memory killer）”。當(dāng)內(nèi)核檢測到系統(tǒng)內(nèi)存不足時，OOM killer被激活，然后選擇一個進程殺掉。哪一個進程這么倒霉呢？選擇的算法和想法都很樸實：誰占用內(nèi)存最多，誰就被干掉。如果你對OOM Killer感興趣的話，建議你閱讀參考資料2中的文章。

OOM Killer，圖片來源：plumbr

當(dāng)可用虛擬虛擬內(nèi)存(包括交換空間)消耗到讓整個操作系統(tǒng)面臨風(fēng)險時，就會產(chǎn)生Out of memory:Kill process or sacrifice child錯誤。在這種情況下，OOM Killer會選擇“流氓進程”并殺死它。

原因分析

默認(rèn)情況下，Linux內(nèi)核允許進程請求比系統(tǒng)中可用內(nèi)存更多的內(nèi)存，但大多數(shù)進程實際上并沒有使用完他們所分配的內(nèi)存。這就跟現(xiàn)實生活中的寬帶運營商類似，他們向所有消費者出售一個100M的帶寬，遠(yuǎn)遠(yuǎn)超過用戶實際使用的帶寬，一個10G的鏈路可以非常輕松的服務(wù)100個(10G/100M)用戶，但實際上寬帶運行商往往會把10G鏈路用于服務(wù)150人或者更多，以便讓鏈路的利用率更高，畢竟空閑在那兒也沒什么意義。

Linux內(nèi)核采用的機制跟寬帶運營商差不多，一般情況下都沒有問題，但當(dāng)大多數(shù)應(yīng)用程序都消耗完自己的內(nèi)存時，麻煩就來了，因為這些應(yīng)用程序的內(nèi)存需求加起來超出了物理內(nèi)存（包括 swap）的容量，內(nèi)核（OOM killer）必須殺掉一些進程才能騰出空間保障系統(tǒng)正常運行。就如同上面的例子中，如果150人都占用100M的帶寬，那么總的帶寬肯定超過了10G這條鏈路能承受的范圍。

示例

當(dāng)你在Linux上運行如下代碼：

public static void main(String[] args){
    List<int[]> l = new java.util.ArrayList();
    for (int i = 10000; i < 100000; i++) {
        try {
            l.add(new int[100000000]);
        } catch (Throwable t) {
            t.printStackTrace();
        }
    }
}

在Linux的系統(tǒng)日志中/var/log/kern.log會出現(xiàn)以下日志：

Jun  4 07:41:59 plumbr kernel: [70667120.897649] Out of memory: Kill process 29957 (java) score 366 or sacrifice child
Jun  4 07:41:59 plumbr kernel: [70667120.897701] Killed process 29957 (java) total-vm:2532680kB, anon-rss:1416508kB, file-rss:0kB

注意：你可能需要調(diào)整交換文件和堆大小，否則你將很快見到熟悉的Java heap space異常。在原作者的測試用例中，使用-Xmx2g指定的2g堆，并具有以下交換配置：

# 注意：原作者使用，由于我手里并沒有Linux環(huán)境，所以并未測試
swapoff -a 
dd if=/dev/zero of=swapfile bs=1024 count=655360
mkswap swapfile
swapon swapfile

解決方案

解決這個問題最有效也是最直接的方法就是升級內(nèi)存，其他方法諸如：調(diào)整OOM Killer配置、水平擴展應(yīng)用，將內(nèi)存的負(fù)載分?jǐn)偟饺舾尚嵗?.... 我們不建議的做法是增加交換空間，具體原因已經(jīng)在前文說過。參考資料②中詳細(xì)的介紹了怎樣微調(diào)OOM Killer配置以及OOM Killer選擇進程算法的實現(xiàn)，建議你參考閱讀。

參考資料：

① 想要了解更多PermGen與Metaspace的內(nèi)容推薦你閱讀：

• Java 8會解決PermGen OutOfMemoryError問題嗎?
• Java PermGen 去哪里了?

② 如果你對OOM Killer感興趣的話，強烈建議你閱讀這篇文章：

• 理解和配置 Linux 下的 OOM Killer

備注：水平有限，難免疏漏，如果問題請留言
本文已經(jīng)同步更新到微信公眾號：輕描淡寫CODE ? Java內(nèi)存溢出(OOM)異常完全指南

轉(zhuǎn)自Java內(nèi)存溢出(OOM)異常完全指南