运行时数据区域
Java虚拟机内存模型包括程序计数器、虚拟机栈、本地方法栈、方法区、堆
VM内存分布图:

程序计数器
程序计数器是一块较小的内存空间,可以看作当前线程所执行的字节码行号指示器。
字节码解释器工作的时候就是通过改变这个计数器的值来选取下一条需要执行的字节码的指令,分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
java虚拟机的多线程是通过线程的轮流切换并分配处理器执行时间实现的,在任何一个确定的时刻,一个处理器(对于多核的处理器就是一个)都只会执行一条线程中的指令。因此为了切换线程后能恢复到正确的执行位置,每个线程都需要一个独立的程序计数器。
如果线程正在执行的是一个Java方法,这个计数器记录的是正在执行的虚拟机字节码指令的地址;如果正在执行的是Native方法,这个计数器则为空。此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemotyError情况的区域。
Java虚拟机栈
Java虚拟机栈的生命周期和线程相同。**虚拟机栈描述的是java方法执行的内存模型。**每个方法在执行的时候都会创建一个栈桢,每个方法从调用直到执行完成,对应的栈桢在虚拟机栈中入栈到出栈。
在活动线程中,只有位于栈顶的栈帧才是有效的,称为当前栈帧,与这个栈帧相关联的方法称为当前方法。执行引擎运行的所有字节码指令都只针对当前栈帧进行操作。
栈桢结构图:

- 局部变量表存放了编辑期可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(refrence)类型和returnAddress类型(指向了一条字节码指令的地址)。
- 其中64位长度的long和double类型的数据会占用两个局部变量空间,其余的数据类型只占用1个。
- 局部变量所需的变量空间在编译期间完成分配,方法在运行期间不会改变局部变量的大小。
- 局部变量存储在局部变量表中,随着线程而生,线程而灭。并且线程间数据不共享。
但是,如果是成员变量,或者定义在方法外对象的引用,它们存储在堆中。因为在堆中,是线程共享数据的,并且栈帧里的命名就已经清楚的划分了界限 : 局部变量表!
Java虚拟机规范对这个区域规定了两种异常状况:如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError异常。如果虚拟机扩展时无法申请到足够的内存,就会跑出OutOfMemoryError异常
本地方法栈
- 本地方法栈(Native Method Stack)与虚拟机栈所发挥的作用是非常相似的,它们之间的区别不过是虚拟机栈为虚拟机执行Java方法服务(也就是字节码)服务,而本地方法栈为虚拟机使用到的Native方法服务。
- java虚拟机规范对本地方法栈使用的语言、使用方法与数据结构并没有强制规定,因此可以由虚拟机自由实现。例如:HotSpot虚拟机直接将本地方法栈和虚拟机栈合二为一。
- 同虚拟机栈相同,Java虚拟机规范对这个区域也规定了两种异常情况
StackOverflowError和OutOfMemoryError异常。
Java堆
- Java堆是被所有线程共享的一块内存区域,在虚拟机启动时创建,是虚拟机所管理的内存中最大的一块。此内存区域的唯一目的就是【存放对象实例和数组】,几乎所有的对象实例和数组都在这里分配内存。
- Java堆是垃圾收集器管理的主要区域,也称为GC
垃圾堆。 - 从内存回收的角度看,由于现在收集器基本都采用分代收集算法,所以Java堆可以细分为:新生代、老生代;
从内存分配的角度看,线程共享的Java堆可能划分出多个线程私有的分配缓冲区(TLAB);
不论如何划分,都与存放的内容无关,无论哪个区域,存储的仍然是对象实例和数组。 - Java堆可以处于物理上不连续的内存空间中,只要逻辑上是连续的即可。如果在堆中没有完成实例分配,并且堆也无法在扩展时将会抛出OutOfMemoryError异常
内存泄露和内存溢出
- 内存泄露 : 指程序中动态分配内存给一些临时对象,但是对象不会被GC所回收,它始终占用内存。即被分配的对象可达但已无用,可用内存越来越少。
- 内存溢出 : 指程序运行过程中无法申请到足够的内存而导致的一种错误。内存溢出通常发生于老年代或永久代垃圾回收后,仍然无内存空间容纳新的Java对象的情况。
内存泄露是内存溢出的一种诱因,不是唯一因素。- Eden Space(伊甸园)、
- Survivor Space(幸存者区)、
- Old Gen(老年代)。
方法区
方法区它用于储存已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
持久代中存的内容
- JVM中类的元数据在Java堆中的存储区域。
- Java类对应的HotSpot虚拟机中的内部表示也存储在这里。
- 类的层级信息,字段,名字。
- 方法的编译信息及字节码。
- 变量
- 常量池和符号解析
除了Java堆一样不需要连续的内存和可以选择固定大小或者可扩展外,还可以选择不实现垃圾收集。这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载。
在HotSpot虚拟中,把GC分代扩展至方法区,用永久代来实现方法区,使HotSpot可以像管理Java堆一样来管理这部分内存,省去了专门管理方法区的代码工作。
但是JDK8的时候便移除了“永久代(Per Gen)”,转而使用“元空间(MetaSpace)”的实现,而且很大的不同就是元空间不在共用JVM内存,而是使用的系统内存。
运行时常量池
运行时常量池(Runtime Constant Pool)是方法区的一部分。Class 文件中除了有
类的版本、字段、方法、接口等描述等信息外,还有一项信息是常量池(Constant Pool
Table),用于存放编译期生成的各种字面量和符号引用,这部分内容将在类加载后存放
到方法区的运行时常量池中。
Java语言并不要求常量一定只有编辑期才能产生,也就是可能将新的常量放入池中,这种特性被开发人员利用得比较多的便是String类的intern()方法
当常量池无法再申请到内存时会抛出OutOfMemoryError异常
直接内存
直接内存(Direct Memory)并不是虚拟机运行时数据区的一部分,也不是Java
虚拟机规范中定义的内存区域在JDK 1.4 中新加入了NIO(New Input/Output)类,引入了一种基于通道(Channel)与缓冲区(Buffer)的I/O 方式,它可以使用Native 函数库直接分配堆外内存,然
后通过一个存储在Java 堆里面的DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能,因为避免了在Java 堆和Native 堆中来回复制数据。
显然,本机直接内存的分配不会受到Java 堆大小的限制,但是,既然是内存,则肯定还是会受到本机总内存(包括RAM 及SWAP 区或者分页文件)的大小及处理器寻址空间的限制。
codeCache
Java代码在执行时一旦被编译器编译为机器码,下一次执行的时候就会直接执行编译后的代码,也就是说,编译后的代码被缓存了起来。缓存编译后的机器码的内存区域就是codeCache。这是一块独立于java堆之外的内存区域。除了jit编译的代码之外,java所使用的本地方法代码(JNI)也会存在codeCache中。不同版本的jvm、不同的启动方式codeCache的默认大小也不同。
codeCache满了
随着时间推移,会有越来越多的方法被编译,codeCache使用量会逐渐增加,直至耗尽。Jit编译器被停止了,并且不会被重新启动。已经被编译过的代码仍然以编译方式执行,但是尚未被编译的代码就只能以解释方式执行了。并且消耗大量cpu导致系统运行变慢。
在Speculative flushing开启的情况下,当codeCache将要耗尽时,最早被编译的一半方法将会被放到一个old列表中等待回收。在一定时间间隔内,如果方法没有被调用,这个方法就会被从codeCache充清除。
1万+

被折叠的 条评论
为什么被折叠?



