深入理解JVM之-Java内存区域与内存溢出

Java 与 C++之间有一度有内存动态分配和垃圾收集技术所谓成的“高墙”,墙外的人想进去,墙里面的人却想出来

概述

对于从事C、C++程序开发的开发人员来说,在内存管理领域,他们即是拥有最高权利的“皇帝”又是从事最基础工作的“劳作人吗”————既拥有每一个对象的所有权,又担负着每一个对象声明开会到总结的维护责任。 对于Java程序员来说,在虚拟机的自动内存管理机制的帮助下,不再需要为诶一个new操作去写配对的delete/free代码,不容易出现内存泄露和内存溢出的问题,有虚拟机管理内存这一切看起来很美好。不过,也正是因为java程序员把内存控制的权利交给了jvm,一旦出现内存泄露和溢出方面的问题,如果不了解虚拟机是怎么样使用内存的,那么排查错误将会成为一项异常艰难的工作。 下面我们来介绍一下java虚拟机内存的各个区域。

运行时数据区域

我们看一下java虚拟机在运行时数据区 jvm runtime jvm在执行java程序时,它所管理的内存区域会被划分为以上几个不同的数据区域。这些区域我们分别做如下介绍:

程序计数器

程序计数器(Program Counter Register)是一块较小的内存空间,它可以看做当前线程所执行的字节码的行号指示器(即记录当前线程执行到了哪里)。在虚拟机的概念模型里,字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令,分支、循环、跳转、异常处理、线程恢复等基础功都需要以来这个计数器来完成。

  • 线程私有:为了线程切换后能够恢复到正确的执行位置,没条线程都需要有一个独立的程序计数器。因此线程之间技术器互不影响,独立存储。

异常

此内存区域区域是唯一一个在jvm规范中没有规顶任何OutofMemoryErro情况的区域(试想一下,每个计数器的存储非常小,每个线程一个计数器,得起多少线程才能把内存撑爆)

Java虚拟机栈(JVM Stacks)

与程序计数器一样,栈也是线程私有的,它的生命周期与线程相同。它描述的是java方法执行的内存模型: 每个方法执行是都会创建一个栈帧(Stack Frame),用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程,就对于这一个栈帧在虚拟机栈中到出栈的过程。 局部变量表存放了编译期可知的各种基本数据类型(boolean,byte,char,short,int,float,long,double)、对象引用(reference类型,它不等同于对象本身,可能是一个纸箱对象起始地址的引用指针,也可能是纸箱一个代表对象的句柄或者其他与此对象的相关位置)和returnAddress类型(指向了一条字节码指令的地址)

  • 局部变量表在编译期间完成分配,当进入一个方法时,这个方法需要在帧中分配多大的局部变量空间是完全确定的,在方法运行期间不会改变局部变量表的大小。
  • 其中64位长度的long和double类型的数据会占用2个局部变量空间(slot),其余的数据类型占1个

异常

  • 如果线程请求栈的深度大于虚拟机所允许的深度,将抛出StackOverflowError异常(递归时常见)
  • 如果jvm的栈空间可以动态扩展,当jvm的栈申请更多空间时,无法得到足够的内存,会抛出OutOfMemoryError异常 例子:
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    /**
    * VM Args: -Xss128k
    *
    * @author armysheng
    */
    public class JavaVMStackSOF {
    private int stackLength = 1;
    public void stackLeak() {
    stackLength++;
    stackLeak();
    }
    public static void main(String[] args) throws Throwable {
    JavaVMStackSOF oom = new JavaVMStackSOF();
    try {
    oom.stackLeak();
    } catch (Throwable e) {
    System.out.println("stack length:" + oom.stackLength);
    throw e;
    }
    }
    }

运行结果:

1
2
3
4
5
6
stack length:1151
Exception in thread "main" java.lang.StackOverflowError
at udacity.storm.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:13)
at udacity.storm.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:13)
at udacity.storm.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:13)
...

实验结果表明:在单个线程下,无论是由于栈帧太大还是虚拟机栈容量太小,当内存无法分配的时候,抛出的都是StackOverFlow异常。 如果测试时不限于单线程,通过不断的建立线程的方式倒是可以产生内存溢出异常。

本地方法栈(Native Method Stack)

本地方法栈与虚拟机所发挥的作用是非常相似的,他们之间的区别不过是虚拟机方法栈为虚拟机执行java方法服务,而本地方法栈则为虚拟机使用到Native。

  • 虚拟机规范对本地方法栈使用的语言、使用发式与数据结构并没有强制规定,因此具体的虚拟机可以自由实现它;
  • 甚至有的虚拟机(譬如Sun HotSpot)直接把本地方法栈和虚拟机栈合二为一
  • 异常同虚拟机栈

Java 堆(Heap)

  • 对于大多数应用来说,java堆是java虚拟机所管理的内存中最大的一块。
  • 线程共享: java堆是被所有线程共享的一块内存区域,在虚拟机启动事创建。
  • java 堆是垃圾收集器管理的主要区域,因此很多时候被称作“GC堆“
  • java堆还可以细分为:新生代和老生代;在细一点的有Eden空间、From Survivor空间、ToSurvivor空间。
  • 堆内存可以通过-Xms 和 -Xms控制

异常

如果在堆内存没有内存完成实例分配,并且也无法再拓展时,将会抛出OutOfMemoryError异常,见下例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
import java.util.ArrayList;
import java.util.List;
/**
* Created by armysheng on 17/7/16.
* VM Args: -Xms20m -Xms20m -XX:+HeapDumpOnOutOfMemoryError
*/
public class HeapOOM {
public static void main(String[] args) {
List<OOMObject> list = new ArrayList<>();
while (true) {
list.add(new OOMObject());
}
}
static class OOMObject {
}
}


运行结果:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid17073.hprof ...
Heap dump file created [2313984338 bytes in 19.357 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:2245)
at java.util.Arrays.copyOf(Arrays.java:2219)
at java.util.ArrayList.grow(ArrayList.java:242)
at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:216)
at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:208)
at java.util.ArrayList.add(ArrayList.java:440)
at udacity.storm.HeapOOM.main(HeapOOM.java:14)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)

方法区(Method Area)

  • 线程共享:方法区和Java堆一样,是各个线程共享的内存区域,它用于存储已被加载的类信息常量静态变量即时编译器编译后的代码等数据
  • 方法区很多人愿意把它称之为“永久代”,仅仅是因为HotSpot虚拟机GC分带收集拓展至方法区,这样jvm就可以像管理java堆一样管理这部分内存

运行时常量池

运行时常来是方法去的一部分,Class文件中出了有类的版本、字段、方法、接口等描述信息外,还有一项信息是常量池,用于存放编译器的生成的各种字面量和符号引用。

直接内存

直接内存不是虚拟机运行时数据区的一部分,也不是java虚拟机规范中定义的内存区域。但这部分内存也被频繁的实验,而且也可能导致OutOfMemoryError异常出现。 在JDK1.4中新加入了NIO(New Input/Output)类,引入了一种基于通道(Channel)与缓冲区(Buffer)的I/O方式,它可以使用Native函数库直接分配堆外内存,然后通过一个存储在java队中的DirectByteBuffer对象,作为这块内存的引用进行操作。这样能在一些场景中显著提高性能,因为避免了在java堆和Native堆中来回复制数据。

总结

本文的总结了虚拟机中的内存是如何划分,哪部分区域、什么样的代码和操作可能导致内存溢出异常。

请我喝杯咖啡吧!