Java内存区域(运行时数据区域)
Java 内存区域和内存模型是不同的东西,内存区域是指 Jvm 运行时将数据分区域存储,强调对内存空间的划分。java
而内存模型(Java Memory Model,简称 JMM )是定义了线程和主内存之间的抽象关系,即 JMM 定义了 JVM 在计算机内存(RAM)中的工做方式,若是咱们要想深刻了解Java并发编程,就要先理解好Java内存模型。算法
Java运行时数据区域
众所周知,Java 虚拟机有自动内存管理机制,若是出现内存泄漏和溢出方面的问题,排查错误就必需要了解虚拟机是怎样使用内存的。编程
下图是 JDK8 以后的 JVM 内存布局。安全
JDK8 以前的内存区域图以下:服务器
java内存区域变化图数据结构
在 HotSpot JVM 中,永久代中用于存放类和方法的元数据以及常量池,好比
Class
和Method
。每当一个类初次被加载的时候,它的元数据都会放到永久代中。 永久代是有大小限制的,所以若是加载的类太多,颇有可能致使永久代内存溢出,即万恶的 java.lang.OutOfMemoryError: PermGen ,为此咱们不得不对虚拟机作调优。 那么,Java 8 中 PermGen 为何被移出 HotSpot JVM 了?我总结了两个主要缘由:多线程
- 因为 PermGen 内存常常会溢出,引起恼人的 java.lang.OutOfMemoryError: PermGen,所以 JVM 的开发者但愿这一块内存能够更灵活地被管理,不要再常常出现这样的 OOM
- 移除 PermGen 能够促进 HotSpot JVM 与 JRockit VM 的融合,由于 JRockit 没有永久代。 根据上面的各类缘由,PermGen 最终被移除,方法区移至 Metaspace,字符串常量移至 Java Heap。
程序计数器
程序计数器(Program Counter Register)是一块较小的内存空间,它能够看做是当前线程所执行的字节码的行号指示器。jvm
因为 Java 虚拟机的多线程是经过线程轮流切换并分配处理器执行时间的方式来实现的,在任何一个肯定的时刻,一个处理器内核都只会执行一条线程中的指令。函数
所以,为了线程切换后能恢复到正确的执行位置,每条线程都须要有一个独立的程序计数器,各条线程之间计数器互不影响,独立存储,咱们称这类内存区域为“线程私有”的内存。
若是线程正在执行的是一个 Java 方法,这个计数器记录的是正在执行的虚拟机字节码指令的地址;若是正在执行的是 Native 方法,这个计数器值则为空(Undefined)。此内存区域是惟一一个在 Java 虚拟机规范中没有规定任何 OutOfMemoryError 状况的区域。
Java虚拟机栈
与程序计数器同样,Java 虚拟机栈(Java Virtual Machine Stacks)也是线程私有的,它的生命周期与线程相同。
虚拟机栈描述的是 Java 方法执行的内存模型:每一个方法在执行的同时都会建立一个栈帧(Stack Frame,是方法运行时的基础数据结构)用于存储局部变量表、操做数栈、动态连接、方法出口等信息。每个方法从调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
在活动线程中,只有位千栈顶的帧才是有效的,称为当前栈帧。正在执行的方法称为当前方法,栈帧是方法运行的基本结构。在执行引擎运行时,全部指令都只能针对当前栈帧进行操做。
1. 局部变量表
局部变量表是存放方法参数和局部变量的区域。 局部变量没有准备阶段, 必须显式初始化。若是是非静态方法,则在 index[0] 位置上存储的是方法所属对象的实例引用,一个引用变量占 4 个字节,随后存储的是参数和局部变量。字节码指令中的 STORE 指令就是将操做栈中计算完成的局部变呈写回局部变量表的存储空间内。
虚拟机栈规定了两种异常情况:若是线程请求的栈深度大于虚拟机所容许的深度,将抛出 StackOverflowError 异常;若是虚拟机栈能够动态扩展(当前大部分的 Java 虚拟机均可动态扩展),若是扩展时没法申请到足够的内存,就会抛出 OutOfMemoryError 异常。
2. 操做栈
操做栈是个初始状态为空的桶式结构栈。在方法执行过程当中, 会有各类指令往 栈中写入和提取信息。JVM 的执行引擎是基于栈的执行引擎, 其中的栈指的就是操 做栈。字节码指令集的定义都是基于栈类型的,栈的深度在方法元信息的 stack 属性中。
i++ 和 ++i 的区别:
- i++:从局部变量表取出 i 并压入操做栈,而后对局部变量表中的 i 自增 1,将操做栈栈顶值取出使用,最后,使用栈顶值更新局部变量表,如此线程从操做栈读到的是自增以前的值。
- ++i:先对局部变量表的 i 自增 1,而后取出并压入操做栈,再将操做栈栈顶值取出使用,最后,使用栈顶值更新局部变量表,线程从操做栈读到的是自增以后的值。
以前之因此说 i++ 不是原子操做,即便使用 volatile 修饰也不是线程安全,就是由于,可能 i 被从局部变量表(内存)取出,压入操做栈(寄存器),操做栈中自增,使用栈顶值更新局部变量表(寄存器更新写入内存),其中分为 3 步,volatile 保证可见性,保证每次从局部变量表读取的都是最新的值,但可能这 3 步可能被另外一个线程的 3 步打断,产生数据互相覆盖问题,从而致使 i 的值比预期的小。
3. 动态连接
每一个栈帧中包含一个在常量池中对当前方法的引用, 目的是支持方法调用过程的动态链接。
4.方法返回地址
方法执行时有两种退出状况:
- 正常退出,即正常执行到任何方法的返回字节码指令,如 RETURN、IRETURN、ARETURN 等;
- 异常退出。
不管何种退出状况,都将返回至方法当前被调用的位置。方法退出的过程至关于弹出当前栈帧,退出可能有三种方式:
- 返回值压入上层调用栈帧。
- 异常信息抛给可以处理的栈帧。
- PC计数器指向方法调用后的下一条指令。
本地方法栈
本地方法栈(Native Method Stack)与虚拟机栈所发挥的做用是很是类似的,它们之间的区别不过是虚拟机栈为虚拟机执行 Java 方法(也就是字节码)服务,而本地方法栈则为虚拟机使用到的 Native 方法服务。Sun HotSpot 虚拟机直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈同样,本地方法栈区域也会抛出 StackOverflowError 和 OutOfMemoryError 异常。
线程开始调用本地方法时,会进入 个再也不受 JVM 约束的世界。本地方法能够经过 JNI(Java Native Interface)来访问虚拟机运行时的数据区,甚至能够调用寄存器,具备和 JVM 相同的能力和权限。 当大量本地方法出现时,势必会削弱 JVM 对系统的控制力,由于它的出错信息都比较黑盒。对内存不足的状况,本地方法栈仍是会抛出 nativeheapOutOfMemory。
JNI 类本地方法最著名的应该是 System.currentTimeMillis()
,JNI使 Java 深度使用操做系统的特性功能,复用非 Java 代码。 可是在项目过程当中, 若是大量使用其余语言来实现 JNI , 就会丧失跨平台特性。
Java堆
对于大多数应用来讲,Java 堆(Java Heap)是 Java 虚拟机所管理的内存中最大的一块。Java 堆是被全部线程共享的一块内存区域,在虚拟机启动时建立。此内存区域的惟一目的就是存放对象实例,几乎全部的对象实例都在这里分配内存。
堆是垃圾收集器管理的主要区域,所以不少时候也被称作“GC堆”(Garbage Collected Heap)。从内存回收的角度来看,因为如今收集器基本都采用分代收集算法,因此 Java 堆中还能够细分为:新生代和老年代;再细致一点的有 Eden 空间、From Survivor 空间、To Survivor 空间等。从内存分配的角度来看,线程共享的 Java 堆中可能划分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer,TLAB)。
Java 堆能够处于物理上不连续的内存空间中,只要逻辑上是连续的便可,当前主流的虚拟机都是按照可扩展来实现的(经过 -Xmx 和 -Xms 控制)。若是在堆中没有内存完成实例分配,而且堆也没法再扩展时,将会抛出 OutOfMemoryError 异常。
方法区
方法区(Method Area)与 Java 堆同样,是各个线程共享的内存区域,它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。永久代是HotSpot的概念,方法区是Java虚拟机规范中的定义,是一种规范,而永久代是一种实现,一个是标准一个是实现。虽然Java 虚拟机规范把方法区描述为堆的一个逻辑部分,可是它却有一个别名叫作 Non-Heap(非堆),目的应该是与 Java 堆区分开来。
Java 虚拟机规范对方法区的限制很是宽松,除了和 Java 堆同样不须要连续的内存和能够选择固定大小或者可扩展外,还能够选择不实现垃圾收集。垃圾收集行为在这个区域是比较少出现的,其内存回收目标主要是针对常量池的回收和对类型的卸载。当方法区没法知足内存分配需求时,将抛出 OutOfMemoryError 异常。
JDK8 以前,Hotspot 中方法区的实现是永久代(Perm),JDK8 开始使用元空间(Metaspace),之前永久代中的字符串常量池移至堆内存,运行时常量池、类信息等其余内容移至元空间,元空间直接在本地内存分配。
为何要使用元空间取代永久代的实现?
- 字符串存在永久代中,容易出现性能问题和内存溢出。
- 类及方法的信息等比较难肯定其大小,所以对于永久代的大小指定比较困难,过小容易出现永久代溢出,太大则容易致使老年代溢出。
- 永久代会为 GC 带来没必要要的复杂度,而且回收效率偏低。
- 将 HotSpot 与 JRockit 合二为一。
运行时常量池
运行时常量池(Runtime Constant Pool)是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述信息外,还有一项信息是常量池(Constant Pool Table),用于存放编译期生成的各类字面量和符号引用,这部份内容将在类加载后进入方法区的运行时常量池中存放。
通常来讲,除了保存 Class 文件中描述的符号引用外,还会把翻译出来的直接引用也存储在运行时常量池中。
运行时常量池相对于 Class 文件常量池的另一个重要特征是具有动态性,Java 语言并不要求常量必定只有编译期才能产生,也就是并不是预置入 Class 文件中常量池的内容才能进入方法区运行时常量池,运行期间也可能将新的常量放入池中,这种特性被开发人员利用得比较多的即是 String 类的 intern() 方法。
既然运行时常量池是方法区的一部分,天然受到方法区内存的限制,当常量池没法再申请到内存时会抛出 OutOfMemoryError 异常。
直接内存
直接内存(Direct Memory)并非虚拟机运行时数据区的一部分,也不是 Java 虚拟机规范中定义的内存区域。
在 JDK 1.4 中新加入了 NIO,引入了一种基于通道(Channel)与缓冲区(Buffer)的 I/O 方式,它可使用 Native 函数库直接分配堆外内存,而后经过一个存储在 Java 堆中的 DirectByteBuffer 对象做为这块内存的引用进行操做。这样能在一些场景中显著提升性能,由于避免了在 Java 堆和 Native 堆中来回复制数据。
显然,本机直接内存的分配不会受到 Java 堆大小的限制,可是,既然是内存,确定仍是会受到本机总内存(包括 RAM 以及 SWAP 区或者分页文件)大小以及处理器寻址空间的限制。服务器管理员在配置虚拟机参数时,会根据实际内存设置 -Xmx 等参数信息,但常常忽略直接内存,使得各个内存区域总和大于物理内存限制(包括物理的和操做系统级的限制),从而致使动态扩展时出现 OutOfMemoryError 异常。
最后,推荐与感谢: 深刻理解Java虚拟机(第2版) 码出高效:Java开发手册 Java内存模型原理,你真的理解吗?) 深刻理解 Java 内存模型