JVM系列(二) - JVM内存区域详解

时间  2019-12-07
标签 jvm 系列 内存 区域 详解 栏目 Java 繁體版
原文   原文链接

前言

JVM内存区域包括 PC计数器、Java虚拟机栈、本地方法栈、堆、方法区、运行时常量池和 直接内存。java

本文主要介绍各个内存区域的做用和特性，同时分别阐述各个区域发生内存溢出的可能性和异常类型。编程

正文

(一). JVM内存区域

Java虚拟机执行Java程序的过程当中，会把所管理的内存划分为若干不一样的数据区域。这些内存区域各有各的用途，以及建立和销毁时间。有的区域随着虚拟机进程的启动而存在，有的区域伴随着用户线程的启动和结束而建立和销毁。后端

JVM内存区域也称为Java运行时数据区域。其中包括：程序计数器、虚拟机栈、本地方法栈、堆、静态方法区、静态常量池等。数组

注意：程序计数器、虚拟机栈、本地方法栈属于每一个线程私有的；堆和方法区属于线程共享访问的。缓存

1.1. PC计数器

程序计数器（Program Counter Register）是一块较小的内存空间，它的做用能够看作是当前线程所执行的字节码行号指示器。多线程

  1. 当前线程所执行的字节码行号指示器。
  2. 每一个线程都有一个本身的PC计数器。
  3. 线程私有的，生命周期与线程相同，随JVM启动而生，JVM关闭而死。
  4. 线程执行Java方法时，记录其正在执行的虚拟机字节码指令地址。
  5. 线程执行Native方法时，计数器记录为空(Undefined)。
  6. 惟一在Java虚拟机规范中没有规定任何OutOfMemoryError状况区域。

1.2. Java虚拟机栈

线程私有内存空间，它的生命周期和线程相同。线程执行期间，每一个方法执行时都会建立一个栈帧(Stack Frame) ，用于存储 局部变量表、操做数栈 、动态连接 、方法出口 等信息。架构

  1. 局部变量表
  2. 操做数栈
  3. 动态连接
  4. 方法出口

每个方法从调用直到执行完成的过程，就对应着一个栈帧在虚拟机栈中的入栈和出栈的全过程。框架

下面依次解释栈帧里的四种组成元素的具体结构和功能：异步

1). 局部变量表

局部变量表是一组变量值的存储空间，用于存储方法参数和局部变量。 在 Class 文件的方法表的 Code 属性的 max_locals 指定了该方法所需局部变量表的最大容量。分布式

局部变量表在编译期间分配内存空间，能够存放编译期的各类变量类型：

  1. 基本数据类型 ：boolean, byte, char, short, int, float, long, double等8种；
  2. 对象引用类型 ：reference，指向对象起始地址的引用指针；
  3. 返回地址类型 ：returnAddress，返回地址的类型。

变量槽(Variable Slot)：

变量槽是局部变量表的最小单位，规定大小为32位。对于64位的long和double变量而言，虚拟机会为其分配两个连续的Slot空间。

2). 操做数栈

操做数栈（Operand Stack）也常称为操做栈，是一个后入先出栈。在 Class 文件的 Code 属性的 max_stacks 指定了执行过程当中最大的栈深度。Java虚拟机的解释执行引擎被称为基于栈的执行引擎 ，其中所指的栈就是指－操做数栈。

  1. 和局部变量表同样，操做数栈也是一个以32字长为单位的数组。
  2. 虚拟机在操做数栈中可存储的数据类型：int、long、float、double、reference和returnType等类型 (对于byte、short以及char类型的值在压入到操做数栈以前，也会被转换为int)。
  3. 和局部变量表不一样的是，它不是经过索引来访问，而是经过标准的栈操做 — 压栈和出栈来访问。好比，若是某个指令把一个值压入到操做数栈中，稍后另外一个指令就能够弹出这个值来使用。

虚拟机把操做数栈做为它的工做区——大多数指令都要从这里弹出数据，执行运算，而后把结果压回操做数栈。

1
2
3
4
5
6
 
begin
iload_0 // push the int in local variable 0 onto the stack
iload_1 // push the int in local variable 1 onto the stack
iadd // pop two ints, add them, push result
istore_2 // pop int, store into local variable 2
end

在这个字节码序列里，前两个指令 iload_0 和 iload_1 将存储在局部变量表中索引为0和1的整数压入操做数栈中，其后iadd指令从操做数栈中弹出那两个整数相加，再将结果压入操做数栈。第四条指令istore_2则从操做数栈中弹出结果，并把它存储到局部变量表索引为2的位置。

下图详细表述了这个过程当中局部变量表和操做数栈的状态变化(图中没有使用的局部变量表和操做数栈区域以空白表示)。

3). 动态连接

每一个栈帧都包含一个指向运行时常量池中所属的方法引用，持有这个引用是为了支持方法调用过程当中的动态连接。

Class文件的常量池中存在有大量的符号引用，字节码中的方法调用指令就以常量池中指向方法的符号引用为参数。这些符号引用：

  1. 静态解析：一部分会在类加载阶段或第一次使用的时候转化为直接引用（如final、static域等），称为静态解析，
  2. 动态解析：另外一部分将在每一次的运行期间转化为直接引用，称为动态连接。
4). 方法返回地址

当一个方法开始执行之后，只有两种方法能够退出当前方法：

  1. 正常返回：当执行遇到返回指令，会将返回值传递给上层的方法调用者，这种退出的方式称为正常完成出口(Normal Method Invocation Completion)，通常来讲，调用者的PC计数器能够做为返回地址。
  2. 异常返回：当执行遇到异常，而且当前方法体内没有获得处理，就会致使方法退出，此时是没有返回值的，称为异常完成出口(Abrupt Method Invocation Completion)，返回地址要经过异常处理器表来肯定。

当一个方法返回时，可能依次进行如下3个操做：

  1. 恢复上层方法的局部变量表和操做数栈。
  2. 把返回值压入调用者栈帧的操做数栈。
  3. 将PC计数器的值指向下一条方法指令位置。

小结：

注意：在Java虚拟机规范中，对这个区域规定了两种异常。
其一：若是当前线程请求的栈深度大于虚拟机栈所容许的深度，将会抛出 StackOverflowError 异常（在虚拟机栈不容许动态扩展的状况下）；其二：若是扩展时没法申请到足够的内存空间，就会抛出 OutOfMemoryError 异常。

1.3. 本地方法栈

本地方法栈和Java虚拟机栈发挥的做用很是类似，主要区别是Java虚拟机栈执行的是Java方法服务，而本地方法栈执行Native方法服务(一般用C编写)。

有些虚拟机发行版本(譬如Sun HotSpot虚拟机)直接将本地方法栈和Java虚拟机栈合二为一。与虚拟机栈同样，本地方法栈也会抛出StackOverflowError和OutOfMemoryError异常。

1.4. 堆

Java堆是被全部线程共享的最大的一块内存区域，在虚拟机启动时建立。此内存区域的惟一目的就是存放对象实例，几乎全部的对象实例都在这里分配内存。

在Java中，堆被划分红两个不一样的区域：新生代 (Young Generation) 、老年代 (Old Generation) 。新生代 (Young) 又被划分为三个区域：一个Eden区和两个Survivor区 - From Survivor区和To Survivor区。

简要概括：新的对象分配是首先放在年轻代 (Young Generation) 的Eden区，Survivor区做为Eden区和Old区的缓冲，在Survivor区的对象经历若干次收集仍然存活的，就会被转移到老年代Old中。

这样划分的目的是为了使JVM可以更好的管理堆内存中的对象，包括内存的分配以及回收。

1.5. 方法区

方法区和Java堆同样，为多个线程共享，它用于存储类信息、常量、静态常量和即时编译后的代码等数据。

1.6. 运行时常量池

运行时常量池是方法区的一部分，Class文件中除了有类的版本、字段、方法和接口等描述信息外，
还有一类信息是常量池，用于存储编译期间生成的各类字面量和符号引用。

1.7. 直接内存

直接内存不属于虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域。
Java NIO容许Java程序直接访问直接内存，一般直接内存的速度会优于Java堆内存。所以，对于读写频繁、性能要求高的场景，能够考虑使用直接内存。

(二). 常见内存溢出异常

除了程序计数器外，Java虚拟机的其余运行时区域都有可能发生OutOfMemoryError的异常，下面分别给出验证：

2.1. Java堆溢出

Java堆可以存储对象实例。经过不断地建立对象，并保证GC Roots到对象有可达路径来避免垃圾回收机制清除这些对象。
当对象数量到达最大堆的容量限制时就会产生OutOfMemoryError异常。

设置JVM启动参数：-Xms20M设置堆的最小内存为20M，-Xmx20M设置堆的最大内存和最小内存同样，这样能够防止Java堆在内存不足时自动扩容。
-XX:+HeapDumpOnOutOfMemoryError参数可让虚拟机在出现内存溢出异常时Dump出内存堆运行时快照。

HeapOOM.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
/**
 * VM Args: -Xms20M -Xmx20M -XX:+HeapDumpOnOutOfMemoryError
 */
public class HeapOOM {
 public static class OOMObject {
 }

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

测试运行结果：

打开Java VisualVM导出Heap内存运行时的dump文件。


HeapOOM对象不停地被建立，堆内存使用达到99%。垃圾回收器不断地尝试回收但都以失败了结。

分析：遇到这种状况，一般要考虑内存泄露和内存溢出两种可能性。

  • 若是是内存泄露：

    进一步使用Java VisualVM工具进行分析，查看泄露对象是经过怎样的路径与GC Roots关联而致使垃圾回收器没法回收的。

  • 若是是内存溢出：

    经过Java VisualVM工具分析，不存在泄露对象，也就是说堆内存中的对象必须得存活着。就要考虑以下措施：

    1. 从代码上检查是否存在某些对象生命周期过长、持续状态时间过长的状况，尝试减小程序运行期的内存。
    2. 检查虚拟机的堆参数(-Xmx与-Xms)，对比机器的物理内存看是否还能够调大。

2.2. 虚拟机和本地方法栈溢出

关于虚拟机栈和本地方法栈，分析内存异常类型可能存在如下两种：

  • 若是现场请求的栈深度大于虚拟机所容许的最大深度，将抛出StackOverflowError异常。
  • 若是虚拟机在扩展栈时没法申请到足够的内存空间，可能会抛出OutOfMemoryError异常。

能够划分为两类问题，当栈空间没法分配时，到底时栈内存过小，仍是已使用的栈内存过大。

StackOverflowError异常

测试方案一：

  • 使用-Xss参数减小栈内存的容量，异常发生时打印栈的深度。
  • 定义大量的本地局部变量，以达到增大栈帧中的本地变量表的长度。

设置JVM启动参数：-Xss128k设置栈内存的大小为128k。

JavaVMStackSOF.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
/**
 * VM Args: -Xss128k
 */
public class JavaVMStackSOF {
 private int stackLength = 1;

 private void stackLeak() {
 stackLength++;
 stackLeak();
 }

 public static void main(String[] args) {
 JavaVMStackSOF oom = new JavaVMStackSOF();
 try {
 oom.stackLeak();
 } catch (Throwable e) {
 System.out.println("Stack length: " + oom.stackLength);
 throw e;
 }
 }
}

测试结果：

分析：在单个线程下，不管是栈帧太大仍是虚拟机栈容量过小，当没法分配内存的时候，虚拟机抛出的都是StackOverflowError异常。

测试方案二：

  • 不停地建立线程并保持线程运行状态。

JavaVMStackOOM.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
/**
 * VM Args: -Xss2M
 */
public class JavaVMStackOOM {
 private void running() {
 while (true) {
 }
 }

 public void stackLeakByThread() {
 while (true) {
 new Thread(new Runnable() {
 @Override
 public void run() {
 running();
 }
 }).start();
 }
 }

 public static void main(String[] args) {
 JavaVMStackOOM oom = new JavaVMStackOOM();
 oom.stackLeakByThread();
 }
}

测试结果：

1
 
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread

 

上述测试代码运行时存在较大的风险，可能会致使操做系统假死，这里就不亲自测试了，引用做者的测试结果。

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

(一). 运行时常量池内存溢出测试

运行时常量和字面量都存放于运行时常量池中，常量池又是方法区的一部分，所以两个区域的测试是同样的。
这里采用String.intern()进行测试：

String.intern()是一个native方法，它的做用是：若是字符串常量池中存在一个String对象的字符串，那么直接返回常量池中的这个String对象；
不然，将此String对象包含的字符串放入常量池中，而且返回这个String对象的引用。

设置JVM启动参数：经过-XX:PermSize=10M和-XX:MaxPermSize=10M限制方法区的大小为10M，从而间接的限制其中常量池的容量。

RuntimeConstantPoolOOM.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
/**
 * VM Args: -XX:PermSize=10M -XX:MaxPermSize=10M
 */
public class RuntimeConstantPoolOOM {

 public static void main(String[] args) {
 // 使用List保持着常量池的引用，避免Full GC回收常量池
 List<String> list = new ArrayList<>();
 // 10MB的PermSize在Integer范围内足够产生OOM了
 int i = 0;
 while (true) {
 list.add(String.valueOf(i++).intern());
 }
 }
}

测试结果分析：

JDK1.6版本运行结果：

1
2
 
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
 at java.lang.String.intern(Native Method)

 

JDK1.6版本运行结果显示常量池会溢出并抛出永久带的OutOfMemoryError异常。
而JDK1.7及以上的版本则不会获得相同的结果，它会一直循环下去。

(二). 方法区内存溢出测试

方法区存放Class相关的信息，好比类名、访问修饰符、常量池、字段描述、方法描述等。
对于方法区的内存溢出的测试，基本思路是在运行时产生大量类字节码区填充方法区。

这里引入Spring框架的CGLib动态代理的字节码技术，经过循环不断生成新的代理类，达到方法区内存溢出的效果。

JavaMethodAreaOOM.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
/**
 * VM Args: -XX:PermSize=10M -XX:MaxPermSize=10M
 */
public class JavaMethodAreaOOM {

 public static void main(String[] args) {
 while (true) {
 Enhancer enhancer = new Enhancer();
 enhancer.setSuperclass(OOMObject.class);
 enhancer.setUseCache(false);
 enhancer.setCallback(new MethodInterceptor() {
 @Override
 public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
 return proxy.invokeSuper(obj, args);
 }
 });

 enhancer.create();
 }
 }

 private static class OOMObject {
 public OOMObject() {
 }
 }
}

JDK1.6版本运行结果：

1
2
3
4
 
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
 at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
 at java.lang.ClassLoader.defineClass(ClassLoader.java:616)

 

测试结果分析：

JDK1.6版本运行结果显示常量池会溢出并抛出永久带的OutOfMemoryError异常。
而JDK1.7及以上的版本则不会获得相同的结果，它会一直循环下去。

2.4. 直接内存溢出

本机直接内存的容量可经过-XX:MaxDirectMemorySize指定，若是不指定，则默认与Java堆最大值(-Xmx指定)同样。

测试场景：

直接经过反射获取Unsafe实例，经过反射向操做系统申请分配内存：

设置JVM启动参数：-Xmx20M指定Java堆的最大内存，-XX:MaxDirectMemorySize=10M指定直接内存的大小。

DirectMemoryOOM.java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
/**
 * VM Args: -Xmx20M -XX:MaxDirectMemorySize=10M
 */
public class DirectMemoryOOM {

 private static final int _1MB = 1024 * 1024;

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

测试结果：

测试结果分析：

由DirectMemory致使的内存溢出，一个明显的特征是Heap Dump文件中不会看到明显的异常信息。
若是OOM发生后Dump文件很小，而且程序中直接或者间接地使用了NIO，那么就能够考虑一下这方面的问题。

欢迎关注技术公众号： 零壹技术栈

零壹技术栈零壹技术栈

本账号将持续分享后端技术干货，包括虚拟机基础，多线程编程，高性能框架，异步、缓存和消息中间件，分布式和微服务，架构学习和进阶等学习资料和文章。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程