讓我們看一下我們日常在開發過程中接觸記憶體溢位的異常：　　

Exception in thread "main" [Full GCjava.lang.OutOfMemoryError: Java heap space 
    at java.util.Arrays.copyOf(Unknown Source)
    at java.util.Arrays.copyOf(Unknown Source)
    at java.util.ArrayList.grow(Unknown Source)
    at java.util.ArrayList.ensureExplicitCapacity(Unknown Source)
    at java.util.ArrayList.ensureCapacityInternal(Unknown Source)
    at java.util.ArrayList.add(Unknown Source)
    at oom.HeapOOM.main(HeapOOM.java:
 
21)

Exception in thread "main" java.lang.StackOverflowError
    at java.nio.CharBuffer.arrayOffset(Unknown Source)
    at sun.nio.cs.UTF_8.updatePositions(Unknown Source)
    at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(Unknown Source)
    at sun.nio.cs.UTF_8$Encoder.encodeLoop(Unknown Source)
    at java.nio.charset.CharsetEncoder.encode(Unknown Source)
    at sun.nio.cs.StreamEncoder.implWrite(Unknown Source)
    at sun.nio.cs.StreamEncoder.write(Unknown Source)
    at java.io.OutputStreamWriter.write(Unknown Source)
    at java.io.BufferedWriter.flushBuffer(Unknown Source)
    at java.io.PrintStream.write(Unknown Source)
    at java.io.PrintStream.print(Unknown Source)
    at java.io.PrintStream.println(Unknown Source)
 

java.lang.OutOfMemoryError: PermGen space 

Exception in thread "main" java.lang.OutOfMemoryError
    at sun.misc.Unsafe.allocateMemory(Native Method)
    at oom.DirectMemoryOOM.main(DirectMemoryOOM.java:23)

　　是不是有大家很熟悉的，遇見這樣的問題解決起來可能不簡單，但是如果現在讓大家寫個程式，故意讓程式出現下面的異常，估計能很快寫出來的也不是很多，這就要求開發人員對於java記憶體區域以及jvm規範有比較深的瞭解。

　　既然丟擲了異常，首先我們肯定這些都是記憶體異常，只是記憶體異常中的不同種類，我們就試著瞭解一下為什麼會出現以上的異常，可以看出有兩種異常狀況：：

　　OutOfMemoryError

　　StackOverflowError

　　其中OutOfMemoryError是在程式無法申請到足夠的記憶體的時候丟擲的異常，StackOverflowError是執行緒申請的棧深度大於虛擬機器所允許的深度所丟擲的異常。 可是從上面列出的異常內容也可以看出在OutOfMemoryError型別的一場中也存在這很多異常的可能。這是為什麼？以為是在記憶體的不同結構中出現的錯誤，所以丟擲的異常也就形形色色，說道這我們不得不介紹一下java的記憶體結構，請看下圖（從網上摘的）：

　　

　　在執行時的記憶體區域有5個部分，Method Area（方法區）,Java stack（java 虛擬機器棧）,Native MethodStack（本地方法棧），Heap(堆)，Program Counter Regster(程式計數器)。從圖中看出方法區和堆用黃色標記，和其他三個區域的不同點就是，方法區和堆是執行緒共享的，所有的執行在jvm上的程式都能訪問這兩個區域，堆，方法區和虛擬機器的生命週期一樣，隨著虛擬機器的啟動而存在，而棧和程式計數器是依賴使用者執行緒的啟動和結束而建立和銷燬。

　　Program Counter Regster（程式計數器）：每一個使用者執行緒對應一個程式計數器，用來指示當前執行緒所執行位元組碼的行號。由程式計數器給文字碼直譯器提供嚇一條要執行的位元組碼的的位置。根據jvm規範，在這個區域中不會丟擲OutOfMemoryError的記憶體異常。

　　Java stack（java 虛擬機器棧）：這個區域是最容易出現記憶體異常的區域，每一個執行緒對應生成一個執行緒棧，執行緒每執行一個方法的時候，都會建立一個棧幀，用來存放方法的區域性變量表，操作樹棧，動態連線，方法入口，這和C#是不一樣的，在C#CLR中沒有棧幀的概念，都是線上程棧中通過壓棧和出棧的方式進行資料的儲存。jvm規範對這個區域定義了兩種記憶體異常，OutOfMemoryError，StackOverflowError。

　　Native MethodStack（本地方法棧）：和虛擬機器棧一樣，不同的是處理的物件不一樣，虛擬機器棧處理java的位元組碼，而本地棧則是處理的Native方法。其他方面一致。

　　Heap(堆)：前面說了堆是所有執行緒都能訪問的，隨著虛擬機器的啟動而存在，這塊區域很大，因為所有的執行緒都在這個區域儲存例項化的物件，因為每一個型別中，每個介面實現類需要的記憶體不一樣，一個方法內的多個分支需要的記憶體也不盡相同，我們只有在執行的時候才能知道要建立多少物件，需要分配多大的地址空間。GC關注的正是這樣的部分內容，所以很多時候也將堆稱為GC堆。堆中肯定不會丟擲StackOverflowError型別的異常，所以只有OutOfMemoryError相關型別的異常。

　　Method Area（方法區）：用於存放已被虛擬機器載入的類資訊，常量，靜態方法，即使編譯後的程式碼。同樣只能丟擲OutOfMemoryError相關型別的異常。

　　介紹完jvm記憶體結構中的常見區域，下面該是和我們主題呼應的時候了，在什麼情況下，在那個區域，如何才能復現開始提到的異常資訊？從第一個開始，異常資訊的內容為：　　

Exception in thread "main" [Full GCjava.lang.OutOfMemoryError: Java heap space 
    at java.util.Arrays.copyOf(Unknown Source)
    at java.util.Arrays.copyOf(Unknown Source)
    at java.util.ArrayList.grow(Unknown Source)
    at java.util.ArrayList.ensureExplicitCapacity(Unknown Source)
    at java.util.ArrayList.ensureCapacityInternal(Unknown Source)
    at java.util.ArrayList.add(Unknown Source)
    at oom.HeapOOM.main(HeapOOM.java:21)

　　可想而知是在堆中出現的問題，如何重現，由於是在堆中出現這個異常，那麼就要處理好，不能被垃圾回收器給回收了，設定一下jvm中堆的最大值（這樣才能夠更快的出現錯誤），設定jvm值的方法是通過-Xms(堆的最小值)，-Xmx(堆的最大值)。下面動手試一下：

package oom;

import java.util.ArrayList;
import java.util.List;

import testbean.UserBean;

/*** 
 * 
 * @author Think
 * 
 */
public class HeapOOM {
    static class OOMObject {
    }

    public static void main(String[] args) {
        List<UserBean> users = new ArrayList<UserBean>();
        while (true) {
            users.add(new UserBean());
        }
    }
}

　　UserBean物件定義如下：　　

package testbean;

public class UserBean {
    String name;
    int age;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    public UserBean() {
        super();
    }

}

　　然後在執行的時候設定jvm引數，如下：

　　

　　執行一下看看結果：　　

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Unknown Source)
    at java.util.Arrays.copyOf(Unknown Source)
    at java.util.ArrayList.grow(Unknown Source)
    at java.util.ArrayList.ensureExplicitCapacity(Unknown Source)
    at java.util.ArrayList.ensureCapacityInternal(Unknown Source)
    at java.util.ArrayList.add(Unknown Source)
    at oom.HeapOOM.main(HeapOOM.java:21)

　　成功在java虛擬機器堆中溢位。

　　下面看第二個關於棧的異常，內容如下：　　

Exception in thread "main" java.lang.StackOverflowError
    at java.nio.CharBuffer.arrayOffset(Unknown Source)
    at sun.nio.cs.UTF_8.updatePositions(Unknown Source)
    at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(Unknown Source)
    at sun.nio.cs.UTF_8$Encoder.encodeLoop(Unknown Source)
    at java.nio.charset.CharsetEncoder.encode(Unknown Source)
    at sun.nio.cs.StreamEncoder.implWrite(Unknown Source)
    at sun.nio.cs.StreamEncoder.write(Unknown Source)
    at java.io.OutputStreamWriter.write(Unknown Source)
    at java.io.BufferedWriter.flushBuffer(Unknown Source)
    at java.io.PrintStream.write(Unknown Source)
    at java.io.PrintStream.print(Unknown Source)
    at java.io.PrintStream.println(Unknown Source)

　　因為是與棧相關的話，那麼我們在重現異常的時候就要相應的將棧記憶體容量設定的小一些，設定棧大小的方法是設定-Xss引數，看如下實現：　　

package oom;

import testbean.Recursion;

/*** 
 * 
 * @author Think
 * 
 */
public class VMStackOOM { 

    public static void main(String[] args) {
        Recursion recursion = new Recursion();
        try {
            recursion.recursionself();
        } catch (Throwable e) {
            System.out.println("current value :" + recursion.currentValue);
            throw e;
        }
    }

}

　　Recursion的定義如下：　　

package testbean;

public class Recursion {
    public int currentValue = 0;

    public void recursionself() {
        currentValue += 1;
        recursionself();
    }
}

　　執行時jvm引數的設定如下：

　　

　　執行結果如下：　　

current value :999
Exception in thread "main" java.lang.StackOverflowError
    at testbean.Recursion.recursionself(Recursion.java:7)
    at testbean.Recursion.recursionself(Recursion.java:8)
    at testbean.Recursion.recursionself(Recursion.java:8)
    at testbean.Recursion.recursionself(Recursion.java:8)
    at testbean.Recursion.recursionself(Recursion.java:8)
    at testbean.Recursion.recursionself(Recursion.java:8)
省略下面的異常資訊

　　第三個異常是關於perm的異常內容，我們需要的是設定方法區的大小，實現方式是通過設定-XX:PermSize和-XX:MaxPermSize引數，內容如下：　　

java.lang.OutOfMemoryError: PermGen space

　　如果程式載入的類過多，例如tomcatweb容器，就會出現PermGen space異常，如果我將HeapOOM類的執行時的XX:PermSize設定為2M，如下：

　　

　　那麼程式就不會執行成功，執行的時候出現如下異常：　　

Error occurred during initialization of VM
java.lang.OutOfMemoryError: PermGen space
    at sun.misc.Launcher$ExtClassLoader.getExtClassLoader(Unknown Source)
    at sun.misc.Launcher.<init>(Unknown Source)
    at sun.misc.Launcher.<clinit>(Unknown Source)
    at java.lang.ClassLoader.initSystemClassLoader(Unknown Source)
    at java.lang.ClassLoader.getSystemClassLoader(Unknown Source)

　　第四個異常估計遇到的人就不多了，是DirectMemory記憶體相關的，內容如下：　　

Exception in thread "main" java.lang.OutOfMemoryError
    at sun.misc.Unsafe.allocateMemory(Native Method)
    at oom.DirectMemoryOOM.main(DirectMemoryOOM.java:23)

　　DirectMemoruSize可以通過設定 -XX:MaxDirectMemorySize引數指定容量大小，如果不指定的話，那麼就跟堆的最大值一致,下面是程式碼實現：　　

package oom;

import java.lang.reflect.Field;

import sun.misc.Unsafe;

/*** 
 * 
 * @author Think
 * 
 */
public class DirectMemoryOOM {

    private static final int _1MB = 1024 * 1024;

    public static void main(String[] args) throws IllegalArgumentException,
            IllegalAccessException {
        Field unsafeField = Unsafe.class.getDeclaredFields()[0];
        unsafeField.setAccessible(true);
        Unsafe unsafe = (Unsafe) unsafeField.get(null);
        while (true) {
            unsafe.allocateMemory(_1MB);
        }

    }
}

　　執行時設定的jvm引數如下：

　　

　　很容易就複線了異常資訊：　　

Exception in thread "main" java.lang.OutOfMemoryError
    at sun.misc.Unsafe.allocateMemory(Native Method)
    at oom.DirectMemoryOOM.main(DirectMemoryOOM.java:23)

下面說下OOM的常見情況：

第一類記憶體溢位，也是大家認為最多，第一反應認為是的記憶體溢位，就是堆疊溢位：

那什麼樣的情況就是堆疊溢位呢？當你看到下面的關鍵字的時候它就是堆疊溢位了：

Java.lang.OutOfMemoryError: ......Java heap space.....

也就是當你看到heap相關的時候就肯定是堆疊溢位了，此時如果程式碼沒有問題的情況下，適當調整-Xmx和-Xms是可以避免的，不過一定是程式碼沒有問題的前提，為什麼會溢位呢，要麼程式碼有問題，要麼訪問量太多並且每個訪問的時間太長或者資料太多，導致資料釋放不掉，因為垃圾回收器是要找到那些是垃圾才能回收，這裡它不會認為這些東西是垃圾，自然不會去回收了；主意這個溢位之前，可能系統會提前先報錯關鍵字為：

java.lang.OutOfMemoryError:GC over head limit exceeded

這種情況是當系統處於高頻的GC狀態，而且回收的效果依然不佳的情況，就會開始報這個錯誤，這種情況一般是產生了很多不可以被釋放的物件，有可能是引用使用不當導致，或申請大物件導致，但是java heap space的記憶體溢位有可能提前不會報這個錯誤，也就是可能記憶體就直接不夠導致，而不是高頻GC.

第二類記憶體溢位，PermGen的溢位，或者PermGen 滿了的提示，你會看到這樣的關鍵字：

關鍵資訊為:

java.lang.OutOfMemoryError: PermGen space

原因：系統的程式碼非常多或引用的第三方包非常多、或程式碼中使用了大量的常量、或通過intern注入常量、或者通過動態程式碼載入等方法，導致常量池的膨脹，雖然JDK 1.5以後可以通過設定對永久帶進行回收，但是我們希望的是這個地方是不做GC的，它夠用就行，所以一般情況下今年少做類似的操作，所以在面對這種情況常用的手段是：增加-XX:PermSize和-XX:MaxPermSize的大小。

第三類記憶體溢位：在使用ByteBuffer中的allocateDirect()的時候會用到，很多javaNIO的框架中被封裝為其他的方法

溢位關鍵字：

java.lang.OutOfMemoryError: Direct buffer memory
如果你在直接或間接使用了ByteBuffer中的allocateDirect方法的時候，而不做clear的時候就會出現類似的問題，常規的引用程式IO輸出存在一個核心態與使用者態的轉換過程，也就是對應直接記憶體與非直接記憶體，如果常規的應用程式你要將一個檔案的內容輸出到客戶端需要通過OS的直接記憶體轉換拷貝到程式的非直接記憶體（也就是heap中），然後再輸出到直接記憶體由作業系統傳送出去，而直接記憶體就是由OS和應用程式共同管理的，而非直接記憶體可以直接由應用程式自己控制的記憶體，jvm垃圾回收不會回收掉直接記憶體這部分的記憶體，所以要注意了哦。

如果經常有類似的操作，可以考慮設定引數：-XX:MaxDirectMemorySize

第四類記憶體溢位錯誤：

溢位關鍵字：

java.lang.StackOverflowError

這個引數直接說明一個內容，就是-Xss太小了，我們申請很多區域性呼叫的棧針等內容是存放在使用者當前所持有的執行緒中的，執行緒在jdk 1.4以前預設是256K，1.5以後是1M，如果報這個錯，只能說明-Xss設定得太小，當然有些廠商的JVM不是這個引數，本文僅僅針對Hotspot VM而已；不過在有必要的情況下可以對系統做一些優化，使得-Xss的值是可用的。

第五類記憶體溢位錯誤：

溢位關鍵字：

java.lang.OutOfMemoryError: unable to create new native thread

上面第四種溢位錯誤，已經說明了執行緒的記憶體空間，其實執行緒基本只佔用heap以外的記憶體區域，也就是這個錯誤說明除了heap以外的區域，無法為執行緒分配一塊記憶體區域了，這個要麼是記憶體本身就不夠，要麼heap的空間設定得太大了，導致了剩餘的記憶體已經不多了，而由於執行緒本身要佔用記憶體，所以就不夠用了，說明了原因，如何去修改，不用我多說，你懂的。

第六類記憶體溢位：

溢位關鍵字

java.lang.OutOfMemoryError: request {} byte for {}out of swap

這類錯誤一般是由於地址空間不夠而導致。

六大類常見溢位已經說明JVM中99%的溢位情況，要逃出這些溢位情況非常困難，除非一些很怪異的故障問題會發生，比如由於實體記憶體的硬體問題，導致了code cache的錯誤（在由byte code轉換為native code的過程中出現，但是概率極低），這種情況記憶體 會被直接crash掉，類似還有swap的頻繁互動在部分系統中會導致系統直接被crash掉，OS地址空間不夠的話，系統根本無法啟動，呵呵；JNI的濫用也會導致一些本地記憶體無法釋放的問題，所以儘量避開JNI；socket連線資料開啟過多的socket也會報類似：IOException: Too many open files等錯誤資訊。

相關推薦