Java内存区域

最新推荐文章于 2024-08-06 13:13:22 发布

Egypt_nova

最新推荐文章于 2024-08-06 13:13:22 发布

阅读量114

点赞数

分类专栏： jvm

本文链接：https://blog.csdn.net/wangaiji/article/details/102746420

版权

jvm 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

运行时数据区域

Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。

程序计数器

可以看作是当前线程所执行的字节码的行号指示器，是一块较小的内存空间。（线程私有）

如果线程正在执行的是java方法，计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是native方法，这个计数器值则为空
字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令
分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器完成
为了线程切换后能恢复到正确的执行位置，每条线程都需要一个独立的计数器，各条线程中的计数器互不影响，独立存储
此内存区域是唯一一个在java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。

Java虚拟机栈

描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。

是线程私有的，它的生命周期与线程相同
每一个方法从调用直至执行完成的过程，就对应着一个栈帧（方法运行时的基础数据结构）在虚拟机栈中入栈到出栈的过程
粗糙划分内存为堆和栈，栈指的是虚拟机栈（或者说是其中局部变量表部分）
局部变量表存放了编译期可知的各种基本数据类型、对象引用（reference类型）和returnAddress类型（指向了一条字节码指令的地址）
局部变量表所需的内存空间在编译期间完成分配，方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小（64位 long和double类型占用2个局部变量空间）
这个区域规定了两种异常情况：
- 线程请求的栈深度大于虚拟机所允许的深度，抛出StackOverflowError异常
- 如果虚拟机栈可以动态扩展（规范中也允许固定长度），而扩展时无法申请到足够的内存，抛出OutOfMemoryError异常

本地方法栈

与虚拟机栈的作用非常相似，它们之间的区别是虚拟机栈为虚拟机执行Java方法（字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。（Native方法就是一个Java调用非Java代码的接口）

规范中对本地方法栈中的方法（语言、使用方式、数据结构）没有强制规定，可以自由实现它。有的虚拟机直接把两个栈合二为一
也会抛出StackOverflowError和OutOfMemoryError异常

Java堆

唯一目的就是存放对象实例，几乎所有对象实例都在这里分配（还有数组）。管理的内存中最大的一块。

所有线程共享，在虚拟机启动时创建
是垃圾收集器管理的主要区域，被称作GC堆
从内存回收的角度：Java堆可细分为新生代和老生代（收集器基本都采用分代收集算法），再细致一点：Eden空间、From Survivor空间、To Survivor空间等，为了更好的回收内存
从内存分配的角度：Java堆中可能划分出多个线程私有的分配缓冲区（用来临时存储数据），更快的分配内存
Java堆可以处于物理上不连续的内存空间中，只要逻辑上连续
可实现成固定大小的，也可是可扩展的（主流都是）
如果在堆中没有内存来完成实例分配，并且堆也无法再扩展时，就会抛出OutOfMemoryError异常

直接内存

并不是运行时数据区的一部分，也不是规范中定义的内存区域，但是被频繁使用，也可能导致OutOfMemoryError异常

JDK1.4加入的NIO引入一种基于通道与缓冲区的I/O方式，它可以使用Native函数库直接分配堆外内存，通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作（避免在Java堆和Native堆来回复制数据）
直接内存的分配不会受到Java堆大小的限制，但是会受到本机总内存大小以及处理器寻址空间的限制
配置虚拟机参数时，经常忽略直接内存，使各个内存区域总和大于物理内存限制，动态扩展时出现OutOfMemoryError异常

方法区

用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。虚拟机规范把方法区描述为堆的一个逻辑部分，但是它有一个别名叫做非堆。

对于HotSpot虚拟机，方法区被称为永久代，本质两者并不等价，只是使用永久代来实现方法区，这样垃圾收集器可以像管理Java堆一样管理这部分内存，对于其他虚拟机不存在永久代
使用永久代更容易遇到内存溢出问题，永久代有-XX:MaxPermSize的上限，其他虚拟机只要没有触碰到进程可用内存的上限。因此HotSpot改为采用Native Memory对方法区规划，JDK1.7把放在永久代的字符串常量池移出
和Java堆一样不需要连续的内存和可以选择固定大小或者可扩展，还可以不实现垃圾收集
- 垃圾收集行为在这个区域比较少出现，内存回收的目标主要是针对常量池的回收和对类型的卸载
- 回收效率低，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是必要的
当方法区无法满足内存分配需求，抛出OutOfMemoryError异常

运行时常量池

是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（存放编译期生成的各种字面量和符号引用）。常量池会在类加载后进入方法区的运行时常量池中存放。

运行时常量池中除了保存Class文件中描述的符号引用，还有翻译出来的直接引用
具有动态性，不要求常量一定只有编译期才能产生，并非预置入Class文件中常量池的内容才能进入运行时常量池，运行期间也可能把新的常量放入池中
受到方法区内存的限制，当常量池无法申请到内存会抛出OutOfMemoryError异常

HotSpot虚拟机对象

探讨HotSpot在Java堆中对象分配、布局和访问的全过程

对象的创建

对象限于普通Java对象，不包括数组和Class对象等

1. 先检查new指令的参数是否能在常量池中定位到一个类的符号引用

检查这个符号引用代表的类是否已被加载、解析和初始化过，如果没有先执行相应的类加载

2. 类加载检查完后，为新生对象分配内存

对象所需内存的大小在类加载完成后便可完全确定，分配空间就是把一块确定大小的内存从Java堆中划分出来。Java堆是否规整由采用的垃圾收集器是否带有压缩整理功能

如果堆中内存是绝对规整的，使用指针碰撞
用过的内存放一边，空闲内存放另一边，中间一个指针作为分界点。分配内存就是把指针向空闲空间那边挪动一段与对象大小相等的距离。
问题是对象创建非常频繁，仅仅修改指针指向的位置，并发情况下不是线程安全的。解决方案：
- 对分配内存空间的动作进行同步处理（虚拟机采用CAS配上失败重试）
- 把内存分配的动作按照线程划分在不同的空间之中进行，即每个线程在堆中预先分配一小块内存（本地线程分配缓冲）
  哪个线程要分配内存就在哪个线程的TLAB上分配，只有TLAB用完并分配新的TLAB才需要同步锁定
如果堆中内存不是规整的，使用空闲列表
已使用和空闲内存相互交错，必须维护一个列表，记录哪些内存块是可用的。分配时在列表中找到一块足够大的空间划分给对象实例，并更新列表上的记录。