JavaVM——Java内存区域与内存溢出异常

由于Java把内存控制的权力移交给了Java虚拟机，所以一旦出现了内存泄漏和溢出方面的问题，如果不了解虚拟机是怎么样使用内存的，那么排查错误将会成为一项异常艰难的工作。

运行时数据区域

Java虚拟机在执行Java程序的过程中，会把它所管理的内存划分为若干个不同的数据区域，这些区域都有各自的用途，以及创建和销毁的时间，有的区域随着虚拟机进程的启动而存在。有些区域则依赖用户线程的启动和结束而建立和销毁。

---

• 程序计数器

Program Counter Register 可以看做是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里（仅仅是概念模型，各种虚拟机可能会通过一些更搞笑的方式去实现），字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令、分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器去实现。

由于Java虚拟机的多线程是通过线程切换并分配处理器执行时间来实现的，在任何一个确定的时刻，一个处理器（对多核处理器来说是一个内核）都只会执行一条线程中的指令。所以，为了线程切换后能回到正确的位置，每条线程都有独立的程序计数器。

如果线程正在执行的是一个Java方法，那么计数器记录的是正在执行的虚拟机字节码指令的地址，如果正在执行的是Native方法，这个计数器值则为空（Undefined）。

---

• Java虚拟栈

与程序计数器一样，Java虚拟机栈（Java Virtual Machine Stacks）也是线程私有的，它的生命周期与线程相同。虚拟机描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧（Stack Frame），用于存储局部变量表，操作数栈，动态链接，方法出口等信息，每一个方法从调用直到执行完成的过程，就对应着一个栈帧在虚拟机中入栈到出栈的过程。

经常有人把Java内存区分为堆内存（Heap）和栈内存（Stack），这种区分的方法比较粗糙。“堆”我们以后会讲到，而所指示的“栈”则是我们现在讲的虚拟机栈，或者说是虚拟机栈中局部变量表部分。

局部变量表存放了编译时期可知的各种基本数据类型（boolean,byte,char,short,int,float,long,double）、对象引用（reference类型，可能是指向对象的指针，或者是指向一个代表对象的句柄或其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）。

在Java虚拟机规范中，这个区域规定了两种异常：如果线程请求的栈的深度大于了虚拟机所允许的深度，抛出StackOverflowError异常；如果虚拟机栈可以动态扩展（当然大部分Java虚拟机都可以动态扩展），而扩展无法申请到足够的内存，就会抛出OutOfMemoryError异常。

---

• 本地方法栈

Native Method Stack与虚拟机栈所发挥的作用非常的相似。他们之间的区别不过是虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。既然是相似，它也会抛出StackOverflowError和OutOfMemoryError两个异常。

---

• Java堆

对大多数应用来说，Java Heap是Java 虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例。几乎所有的对象实例都在这里分配内存。这一点在Java虚拟机规范中的描述是：所有的对象实例以及数组都要在堆上分配，但是随着技术的发展（IT编译器和逃逸分析技术等的逐渐成熟），栈上分配、标量替换优化技术将会导致一些微妙的变化，所以所有的对象都在堆上分配也没有那么“绝对”了。

Java堆是垃圾收集器管理的主要区域，因此很多时候也被称为“GC堆”。从内存回收的角度来看，由于现在收集器基本都采用分代收集算法，所以Java堆还可以细分为：新生代和老年代。还可以再细致下去，对此不做介绍。从内存分配的角度来看，线程共享的Java堆中可能划分出多个线程私有的分配缓冲区（Thread Local Allocation Buffer, TLAB）。不过无论如何分配，都和存放的内容无关，无论哪个区域，存储的都仍然是对象的实例，进一步划分的目的是为了更好的回收内存或者更快的分配内存。

根据Java虚拟机规范的规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可。在实现的时候，既可以是固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制）。如果在堆中没有内存完成实例分配，并且堆无法再扩展的时候，就会抛出OutOfMemoryError异常。

---

• 方法区

Method Area和Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆），目的是与Java堆区分开来。

Java虚拟机规范对方法区的限制非常宽松，除了和Java堆不需要连续的内存和可以选择固定大小或者可扩展之外，还可以选择不实现垃圾收集。相对而言，垃圾收集这种行为在这个区域是比较少出现的。但并非是永久存在了，这个区域内存回收的目标主要是针对常量池的回收和对类型的卸载（但一般回收的条件很苛刻，所以“成绩”难以让人满意）。如果方法区无法满足内存分配需求的时候，会抛出OutOfMemoryError异常。

---

• 运行时常量池

Runtime Constant Pool是方法区的一部分。
Class文件中除了有类的版本、方法、字段、接口等描述信息之外，还有一项信息是常量池，用于存放编译期生成的各种字面量和符号的引用，这部分内容将在类加载后进入方法区的运行时常量池中存放。

Java虚拟机对Class文件的每一部分（自然也包括常量池）的格式都有很严格的规定，每一个字节用于存储哪种数据都必须符合规范上的要求才能被虚拟机认可。但对于运行时常量池，Java虚拟机规范没有做任何细节要求。不同的提供商实现的虚拟机可以按照自己的需要来实现这个内存区域。不过，一般来说，除了保存Class文件中描述的符号引用外，还会把翻译出来的直接引用也存储在运行时常量中。

运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，所以运行期间可能有新的常量放入池中。既然运行时常量池是方法区的一部分，所以当常量池无法申请到更多的内存时，也会抛出OutOfMemoryError异常。

---

• 直接内存

Direct Memory并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域，但是这部分内存被频繁的使用，而且也可能导致OutOfMemoryError异常出现。

在JDK1.4中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O方式。它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样避免了在Java堆和Native堆中来回复制数据，从而提高性能。

HotSpot虚拟机对象探秘

以常用的虚拟机HotSpot和常用的内存区域Java堆为例，深入讨论HotSpot虚拟机在Java堆中对象分配、布局和访问的全过程。

---

对象的创建

在语言层面上，创建对象（如Clone、Deserialize）通常仅仅是一个new关键字而已。在虚拟机中，对象（这里讨论仅限于普通Java对象，不包括数组和Class对象）的创建又是怎么样的一个过程呢？

虚拟机遇到一条new指令的时候，首先会检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已经被加载、解析和初始化过。如果没有，那必须先执行相应的类加载过程（以后我们会讨论这一部分的细节）。

在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定。为对象分配空间的任务等同于把一块确定大小的内存从Java堆中划分出来。
假设Java堆是绝对规整的，所有用过的内存和空闲的内存有清晰的界限，这个界限使用指针作为分界点的指示器。那么所分配的内存就是把这个指针向着空闲的方向挪动一段与对象大小相等的距离。这种分配的方法叫做**“指针碰撞”。
如果内存并不是规整的，那虚拟机必须维护一个列表，记录哪些内存块是可用的，在分配的时候在列表中找出一块足够大的空间来划分给对象实例。这种分配方式叫“空闲列表”**。

还有一个需要考虑的问题是对象创建在虚拟机中是非常频繁的行为，即使是仅仅修改一个指针所指向的位置，在并发情况下也并**不是完全的线程安全的。**有可能正在给对象A分配内存，指针还没来得及修改，对象B同时使用了原来的指针来分配内存的情况。解决这个问题有两种方案。
一种是对分配内存空间的动作进行同步处理，实际上虚拟机采用CAS配上失败重试的方式来保证更新操作的原子性。（CAS在之前的文章中有提到过。）
另一种是把内存分配的动作按照线程划分在不同的空间中进行。

内存分配完成后，虚拟机需要将分配到内存空间都初始化为零值。接下来需要对对象进行必要的设置，譬如这个对象是那个类的实例、如何才能找到类的元数据信息、对象的hashcode等等，这些信息被存储在对象头中（Object Header，有点类似与报头）。

上述黑体的三步骤完成后，从虚拟机的视角来看，一个新的对象已经产生了。但对于Java程序来看，对象创建才刚刚开始（只完成了<new>的部分）——<init>方法还没有执行，所有字段还为零。

---

• 对象的内存布局

在HotSpot虚拟机中，对象在内存中存储的布局可以分为3块：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。

HotSpot对象头包括两部分信息。
第一部分用于存储对象自身运行时数据，如HashCode、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等等，这部分数据的长度在32位或者64位虚拟机中分别为32bit和64bit，官方称为“Mark Word”。对象需要存储的运行时数据很多，早已经超出了32或者64为bitmap结构所能存储的记录限度，但是对象头的信息是与对象自身定义的数据无关的额外存储成本。（简单来说，和数据报的报头差不多）
另一部分是类型指针，即对象指向它的类元数据的指针。虚拟机通过这个指针确定这个对象是哪个类的实例。但并不是所有虚拟机都是这样实现的，也就是说查找对象的元数据信息不一定经过对象本身。接下来的实例数据部分是对象真正存储的有效信息。（也就是数据报的报文）
第三部分对齐填充并不是必然存在的，也没有特别的意义，仅仅是占位符的作用。（与数据报的填充也相似）

---

对象的访问定位

我们的Java程序需要通过栈上的reference数据来操作堆上的具体对象。而访问堆中具体对象位置的时候，主流的访问方式有句柄和直接指针两种。
如果使用句柄访问，那么Java堆中将会划分出一块内存来作为句柄池，句柄中包含了对象实例数据与类型数据各自具体地址信息。

如果使用直接指针访问，那么Java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，而reference中存储的直接就是对象地址。

实战：OutOfMemoryError异常

在之前的叙述中，我们知道。除了程序计数器之外，虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError异常（以下简称OOM）的可能。

本节的目的有两个：第一，通过代码验证各个运行时区域存储的内容，第二，希望在实际开发过程中，知道什么样的代码会产生溢出、是什么区域的溢出、以及如何处理。

---

• java堆溢出

Java堆用于存储对象实例，只要不断的创建对象，并且保证GC Roots到对象之间有可达路径来避免垃圾回收机制来清除这些对象，即可抛出OOM异常。

首先设置VM Args。
写代码：

package oom;

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

/**
 * Author: LeesangHyuk
 * Date: 2019/1/9 15:23
 * Description:堆内存溢出的测试
 */
public class HeapOOM {
    static class OOMObject{}

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

然后运行：

java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid5068.hprof ...
Heap dump file created [28243436 bytes in 0.257 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOf(Arrays.java:3210)
	at java.util.Arrays.copyOf(Arrays.java:3181)
	at java.util.ArrayList.grow(ArrayList.java:261)
	at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:235)
	at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:227)
	at java.util.ArrayList.add(ArrayList.java:458)
	at oom.HeapOOM.main(HeapOOM.java:17)

Process finished with exit code 1

Java堆内存的OOM异常是实际应用中常见的内存溢出异常情况。当出现Java堆内存溢出时，会跟随一个"Java heap space"的提示。
要解决这个区域的异常，一般的手段是通过内存映象分析工具对Dump出来的堆转储快照进行分析。重点是确认内存中的对象是否是必要的，也就是分析到底出现了内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）。

Java内存泄露引起原因 ：

1. 静态集合类引起内存泄露：
   像HashMap、Vector等的使用最容易出现内存泄露，这些静态变量的生命周期和应用程序一致，他们所引用的所有的对象Object也不能被释放，因为他们也将一直被Vector等引用着。

Static Vector v = new Vector(10);
for (int i = 1; i<100; i++)
{
Object o = new Object();
v.add(o);
o = null;
}//

2. 当集合里面的对象属性被修改后，再调用remove（）方法时不起作用。

public static void main(String[] args)
{
Set<Person> set = new HashSet<Person>();
Person p1 = new Person("唐僧","pwd1",25);
Person p2 = new Person("孙悟空","pwd2",26);
Person p3 = new Person("猪八戒","pwd3",27);
set.add(p1);
set.add(p2);
set.add(p3);
System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:3 个元素!
p3.setAge(2); //修改p3的年龄,此时p3元素对应的hashcode值发生改变

set.remove(p3); //此时remove不掉，造成内存泄漏

set.add(p3); //重新添加，居然添加成功
System.out.println("总共有:"+set.size()+" 个元素!"); //结果：总共有:4 个元素!
for (Person person : set)
{
System.out.println(person);
}
}

3. 监听器
   在java 编程中，我们都需要和监听器打交道，通常一个应用当中会用到很多监听器，我们会调用一个控件的诸如addXXXListener()等方法来增加监听器，但往往在释放对象的时候却没有记住去删除这些监听器，从而增加了内存泄漏的机会。
4. 各种连接
   比如数据库连接（dataSourse.getConnection()），网络连接(socket)和io连接，除非其显式的调用了其close（）方法将其连接关闭，否则是不会自动被GC 回收的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。这种情况下一般都会在try里面去的连接，在finally里面释放连接。
5. 单例模式
   如果单例对象持有外部对象的引用，那么这个外部对象将不能被jvm正常回收，导致内存泄露。

class A{
public A(){
B.getInstance().setA(this);
}
....
}
//B类采用单例模式
class B{
private A a;
private static B instance=new B();
public B(){}
public static B getInstance(){
return instance;
}
public void setA(A a){
this.a=a;
}
//getter...
}

---

• 虚拟机栈和本地方法栈溢出

关于虚拟机栈和本地栈，Java虚拟机规范中描述了两种异常：

1. 如果线程请求的栈的深度大于虚拟机所允许的深度，将抛出StackOverflowError异常。
2. 如果虚拟机在扩展栈中无法申请到足够的空间，则抛出OOM异常。

这两种异常实际上是对同一件事情的两种描述而已。

package oom;

/**
 * Author: LeesangHyuk
 * Date: 2019/1/9 16:13
 * Description:虚拟机栈和本地方方法栈OOM测试 -Xss128k
 */
public class JavaVMStackSOF {
    private int stackLength=1;
    public void stackLeak(){
        stackLength++;
        stackLeak();
    }

    public static void main(String[] args) {
        JavaVMStackSOF javaVMStackSOF=new JavaVMStackSOF();
        try{
            javaVMStackSOF.stackLeak();
        }catch(Throwable e){
            System.out.println("栈深度："+javaVMStackSOF.stackLength);
            throw  e;
        }
    }
}

栈深度：997
Exception in thread "main" java.lang.StackOverflowError
	at oom.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:11)
	at oom.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:12)
	...

实验结果表明：在单个线程下，无论是由于栈帧太大还是虚拟机栈容量太小，当内存无法分配的时候，虚拟机抛出的都是StackOverflowError异常。

---

• 方法区和运行时常量池溢出

由于运行时常量池是方法区的一部分，因此测试放一起进行。
String.intern()是一个Native方法，它的作用是：如果字符串常量池中已经包含一个等于此String对象的字符串，则返回代表池中这个字符串的String对象，否则将此String对象加入到常量池中，并返回其引用。
javaJDK1.6运行以下代码：（而使用JDK1.7以上版本不会抛出异常）

package oom;

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

/**
 * Author: LeesangHyuk
 * Date: 2019/1/9 16:26
 * Description:VM Args -XX:PermSize=10M -XX:MaxPermSize=10M
 */
public class RuntimeConstantPoolOOM {
    public static void main(String[] args) {
        //使用List保持对常量池的引用，避免GC
        List<String> list=new ArrayList<String>();
        //10MB的PermSize在Integer范围足够产生OOM了
        int i=0;
        while (true){
            list.add(String.valueOf(i++).intern());
        }
    }
}

可以看到“PermGen space”，说明运行时常量池属于方法区（HotSpot虚拟机中的永久代（Permanant Generation））的一部分。

---

• 本机直接内存溢出

package oom;

import sun.misc.Unsafe;

import java.lang.reflect.Field;

/**
 * Author: LeesangHyuk
 * Date: 2019/1/9 16:42
 * Description:VM Args: -Xmx20M -XX:MaxDirectMemorySize=10M
 */
public class DirectMemoryOOM {
    public static final int _1MB=1025*1024;

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

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

Process finished with exit code 1

由直接内存导致的内存溢出，一个明显的特征是Heap Dump文件中不会看到明显的异常。如果读者看到OOM之后的Dump文件很小，而程序中又直接或间接使用了Native Method，就可以考虑下是不是这方面的原因。