简介
Java虚拟机(即JVM)在Java程序运行的过程中,会将它所管理的内存划分为若干个不同的数据区域,这些区域有的随着JVM的启动而创建,有的随着用户线程的启动和结束而建立和销毁。
除此之外,JVM的内存管理机制使得不需要再为每一个新的操作去删除/免费代码,由机器代替程序员这样就不容易出现内存泄露和内存溢出的问题了,但是一旦出现了这种问题如果不了解JVM是怎样使用内存的,那么排查错误将会非常困难。一个基本的JVM运行时内存模型如下所示:
程序运行时可能只有一个线程,也可能有多个线程共同执行,而方法区和堆是程序的所有线程所共享的内存区域,而程序寄存器、虚拟机栈和本地方法栈则是每个线程独占的内存区域。
一、程序计数器(Program Counter Register)
1.什么是程序计数器
程序计数器是一个记录着当前线程所执行的字节码的行号指示器。
JAVA代码编译后的字节码在未经过JIT(实时编译器)编译前,其执行方式是通过“字节码解释器”进行解释执行。简单的工作原理为解释器读取装载入内存的字节码,按照顺序读取字节码指令。读取一个指令后,将该指令“翻译”成固定的操作,并根据这些操作进行分支、循环、跳转等流程。
从上面的描述中,可能会产生程序计数器是否是多余的疑问。因为沿着指令的顺序执行下去,即使是分支跳转这样的流程,跳转到指定的指令处按顺序继续执行是完全能够保证程序的执行顺序的。假设程序永远只有一个线程,这个疑问没有任何问题,也就是说并不需要程序计数器。但实际上程序是通过多个线程协同合作执行的。
首先我们要搞清楚JVM的多线程实现方式。JVM的多线程是通过CPU时间片轮转(即线程轮流切换并分配处理器执行时间)算法来实现的。也就是说,某个线程在执行过程中可能会因为时间片耗尽而被挂起,而另一个线程获取到时间片开始执行。当被挂起的线程重新获取到时间片的时候,它要想从被挂起的地方继续执行,就必须知道它上次执行到哪个位置,在JVM中,通过程序计数器来记录某个线程的字节码执行位置。因此,程序计数器是具备线程隔离的特性,也就是说,每个线程工作时都有属于自己的独立计数器。
2.程序计数器的特点
- 线程隔离性,每个线程工作时都有属于自己的独立计数器,即程序计数器是线程私有的
- 执行Java方法时,程序计数器是有值的,且记录的是正在执行的字节码指令的地址
-
执行native本地方法时,程序计数器的值为空(Undefined)。因为native方法是java通过JNI直接调用本地C/C++库,可以近似的认为native方法相当于C/C++暴露给java的一个接口,java通过调用这个接口从而调用到C/C++方法。由于该方法是通过C/C++而不是java进行实现。那么自然无法产生相应的字节码,并且C/C++执行时的内存分配是由自己语言决定的,而不是由JVM决定的。
- 程序计数器占用内存很小,在进行JVM内存计算时,可以忽略不计。
- 程序计数器,是唯一一个在java虚拟机规范中没有规定任何OutOfMemoryError的区域。
二、Java虚拟机栈(VM Stack)
1、什么是Java虚拟机栈
- 用于作用于方法执行的一块Java内存区域
- 虚拟机栈是用于描述java方法执行的内存模型。
-
每个java方法在执行时,会创建一个“栈帧(stack frame)”,栈帧的结构分为“局部变量表、操作数栈、动态链接、方法出口”几个部分(具体的作用会在字节码执行引擎章节中讲到,这里只需要了解栈帧是一个方法执行时所需要数据的结构)
2、特点
Java虚拟机栈也是线程私有的,它的生命周期与线程相同(随线程而生,随线程而灭)
如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError异常
如果虚拟机栈可以动态扩展,如果扩展时无法申请到足够的内存,就会抛出OutOfMemoryError异常
Java虚拟机栈描述的是Java方法执行的内存模型:每个方法执行的同时会创建一个栈帧
对于我们来说,主要关注的stack栈内存,就是虚拟机栈中局部变量表部分。
3、栈帧
- 栈帧(Stack Frame)是用于支持虚拟机进行方法调用和方法执行的数据结构,它是虚拟机运行时数据区中的java虚拟机栈的栈元素。
- 栈帧存储了方法的局部变量表、操作数栈、动态连接和方法返回地址等信息
- 每一个方法从调用开始至执行完成的过程,都对应着一个栈帧在虚拟机里面从入栈到出栈的过程
注意:
在编译程序代码的时候,栈帧中需要多大的局部变量表内存,多深的操作数栈都已经完全确定了。
因此一个栈帧需要分配多少内存,不会受到程序运行期变量数据的影响,而仅仅取决于具体的虚拟机实现。
#######栈帧结构如下:
4、局部变量表
1.局部变量表(Local Variable Table)是一组变量值存储空间,用于存放方法参数和方法内部定义的局部变量。并且在Java编译为Class文件时,就已经确定了该方法所需要分配的局部变量表的最大容量。
2.局部变量表存放了编译期可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)「String是引用类型」,对象引用(reference类型) 和 returnAddress类型(它指向了一条字节码指令的地址)
注意:
很多人说:基本数据和对象引用存储在栈中。
当然这种说法虽然是正确的,但是很不严谨,只能说这种说法针对的是局部变量。
局部变量存储在局部变量表中,随着线程而生,线程而灭。并且线程间数据不共享。但是,如果是成员变量,或者定义在方法外对象的引用,它们存储在堆中。
因为在堆中,是线程共享数据的,并且栈帧里的命名就已经清楚的划分了界限 : 局部变量表!
5、reference(对象实例的引用)
个人感觉和指针类似
一般来说,虚拟机都能从引用中直接或者间接的查找到对象的以下两点 :
a.在Java堆中的数据存放的起始地址索引。
b.所属数据类型在方法区中的存储类型。
例如:我们在创建一个Student对象时的数据存储结构:
6、案例
来段代码试求程序运行时虚拟机栈的内存长度,抛出StackOverflowError异常
package yzl.swu.practice;
/** 测试代码设计思路
* 修改默认堆栈大小后,利用递归调用一个方法,达到栈深度过大的异常目的,同时在递归调用过程中记录调用此次,得出最大深度的数据
* jvm参数
* -Xss 180k:设置每个线程的堆栈大小(最小180k),默认是1M
*/
public class TestStackOverflowErrorDemo {
//栈深度统计值
private int stackLength = 1;
/**
* 递归方法,导致栈深度过大异常
*/
public void stackLeak() {
stackLength++;
stackLeak();
}
/**
* 启动方法
* 测试结果:当-Xss 180k为180k时,stackLength~=1544,随着-Xss参数变大时stackLength值随之变大
* @param args
*/
public static void main(String[] args) {
TestStackOverflowErrorDemo demo = new TestStackOverflowErrorDemo();
try {
demo.stackLeak();
} catch (Throwable e) {
System.out.println("当前栈深度:stackLength=" + demo.stackLength);
e.printStackTrace();
}
}
}
三、本地方法栈(Native Method Stack)
- 用于作用域本地方法执行的一块Java内存区域
- 本地方法栈的功能和特点类似于虚拟机栈,均具有线程隔离的特点以及都能抛出StackOverflowError和OutOfMemoryError异常。
- 不同的是,本地方法栈服务的对象是JVM执行的native方法(java代码中使用native关键字标记的方法),而虚拟机栈服务的是JVM执行的java方法。如何去服务native方法?native方法使用什么语言实现?怎么组织像栈帧这种为了服务方法的数据结构?虚拟机规范并未给出强制规定,因此不同的虚拟机实可以进行自由实现,我们常用的HotSpot虚拟机选择合并了虚拟机栈和本地方法栈。
四、堆(Heap)
1、什么是Java堆
对于大多数应用来说,堆是JVM所管理的内存中最大的一块,也是被所有线程共享的一块内存区域,在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例,几乎所有的对象实例都在这里分配内存,可谓是对象的大本营。此外,堆也是垃圾收集器(GC)管理的主要区域。
2、堆的特点
- 一个jvm实例只存在一个堆内存,堆也是java内存管理的核心区域
- Java堆区在JVM启动的时候即被创建,其空间大小也就确定了。是JVM管理的最大一块内存空间(堆内存的大小是可以调节的)
- 《Java虚拟机规范》规定,堆可以处于物理上不连续的内存空间中,但在逻辑上它应该被视为连续的
- 《Java虚拟机规范》中对java堆的描述是:所有的对象实例以及数组都应当在运行时分配在堆上。从实际使用的角度看,“几乎”所有的对象的实例都在这里分配内存
- 数组或对象永远不会存储在栈上,因为栈帧中保存引用,这个引用指向对象或者数组在堆中的位置(String也是引用对象哦)
- 在方法结束后,堆中的对象不会马上被移除,仅仅在垃圾收集的时候才会被移除
- 堆在逻辑上划分为“新生代”和“老年代”。由于JAVA中的对象大部分是朝生夕灭,还有一小部分能够长期的驻留在内存中,为了对这两种对象进行最有效的回收,将堆划分为新生代和老年代,并且执行不同的回收策略。不同的垃圾收集器对这2个逻辑区域的回收机制不尽相同。
3、堆的OutOfMemoryError异常
- 当堆无法分配对象内存且无法再扩展时,会抛出OutOfMemoryError异常。
- 一般来说,堆无法分配对象时会进行一次GC,如果GC后仍然无法分配对象,才会报内存耗尽的错误。
代码测试一下:
public class Test {
public static void main(String[] args) {
List list = new ArrayList();
while (true) {
//重复的向list内添加1MB大小的数据,由于list内元素不符合GC回收条件进而导致OOM。
list.add(new byte[1024 * 1024]);
}
}
}
五、Java方法区(Method Area)
1、什么是Java方法区
方法区,也称非堆(Non-Heap,与Java堆一样,是各个线程共享的内存区域,它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
方法区结构图如下:
2、运行时常量池
首先需要知道常量池和运行时常量池的区别。
-
常量池
即指class文件常量池,是class文件的一部分。java文件被编译成class文件之后,除了包含了类的版本、字段、方法、接口等描述信息,还有一项信息叫做class文件常量池。其用于存放编译期生成的各种字面量和符号引用。 -
运行时常量池
Java语言并不要求常量一定只能在编译期产生,运行期间也可能产生新的常量,这些常量被放在运行时常量池中。
类加载后,常量池中的数据会在运行时常量池中存放!
这里所说的常量包括:基本类型包装类(包装类不管理浮点型,整形只会管理-128到127)和String(也可以通过String.intern()方法可以强制将String放入常量池) -
字符串常量池
HotSpot VM里,记录interned string的一个全局表叫做StringTable,它本质上就是个HashSet<String>。注意它只存储对java.lang.String实例的引用,而不存储String对象的内容
注意:jdk 1.7后,移除了方法区间,运行时常量池和字符串常量池都在堆中。
3、方法区的实现
具体放在哪里,不同的实现可以放在不同的地方。永久代是HotSpot虚拟机特有的概念,是对方法区的实现,别的JVM没有永久代的概念。(虽然去除了永久代,但是方法区作为概念上的区域仍然存在)
方法区的实现,虚拟机规范中并未明确规定,目前有2种比较主流的实现方式:
- HotSpot虚拟机1.7-:在JDK1.6及之前版本,HotSpot使用“永久代(permanent generation)”的概念作为实现,即将GC分代收集扩展至方法区。这种实现比较偷懒,可以不必为方法区编写专门的内存管理,但带来的后果是容易碰到内存溢出的问题(因为永久代有-XX:MaxPermSize的上限)。在JDK1.7+之后,HotSpot逐渐改变方法区的实现方式,如1.7版本移除了方法区中的字符串常量池。
- HotSpot虚拟机1.8+:1.8版本中移除了方法区并使用metaspace(元数据空间)作为替代实现。metaspace占用系统内存,也就是说,只要不碰触到系统内存上限,方法区会有足够的内存空间。但这不意味着我们不对方法区进行限制,如果方法区无限膨胀,最终会导致系统崩溃。
JDK1.8+ JVM
4、方法区的OutOfMemoryError
- 首先,为什么使用“永久代”并将GC分代收集扩展至方法区这种实现方式不好,会导致OOM?首先要明白方法区的内存回收目标是什么,方法区存储了类的元数据信息和各种常量,它的内存回收目标理应当是对这些类型的卸载和常量的回收。但由于这些数据被类的实例引用,卸载条件变得复杂且严格,回收不当会导致堆中的类实例失去元数据信息和常量信息。因此,回收方法区内存不是一件简单高效的事情,往往GC在做无用功。另外随着应用规模的变大,各种框架的引入,尤其是使用了字节码生成技术的框架,会导致方法区内存占用越来越大,最终OOM。
- 因为方法区最终都会有一个最大值上限,因此若方法区(含运行时常量池)占用内存到达其最大值,且无法再申请到内存时,便会抛出OutOfMemoryError。