从内存溢出看Java 环境中的内存结构(转)

作为有个java程序员，我想大家对下面出现的这几个场景并不陌生，倍感亲切，深恶痛绝，抓心挠肝，一定会回过头来问为什么为什么为什么会这样，嘿嘿，让我们看一下我们日常在开发过程中接触内存溢出的异常：

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)

垃圾回收：

垃圾回收算法的具体实现就是SUN提供的垃圾回收器。新生代是Serial, ParNew,Parallel Scanage;老生代包括Serial Old, Parallel Old, CMS

• 标记-清除（Mark-Sweep）
  此算法执行分两阶段。第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。此算法需要暂停整个应用，同时，会产生内存碎片。
• 复制（Copying）
  
  此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。次算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不过出现"碎片"问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。
• 标记-整理（Mark-Compact）
  
  此算法结合了"标记-清除"和"复制"两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象"压缩"到堆的其中一块，按顺序排放。此算法避免了"标记-清除"的碎片问题，同时也避免了"复制"算法的空间问题。
• 增量收集（Incremental Collecting）
  
  实施垃圾回收算法，即：在应用进行的同时进行垃圾回收。不知道什么原因JDK5.0中的收集器没有使用这种算法的。
• 分代（Generational Collecting）
  
  基于对对象生命周期分析后得出的垃圾回收算法。把对象分为年青代、年老代、持久代，对不同生命周期的对象使用不同的算法（上述方式中的一个）进行回收。现在的垃圾回收器（从J2SE1.2开始）都是使用此算法的。

引用计数还有一个致命的缺陷，当程中出现序循环引用时，引用计数算法无法检测出来，被循环引用的内存对象就成了无法回收的内存。从而引起内存泄露。