【JVM】Java内存区域与内存溢出异常jvm内存分布以及各个内存区域的特点&异常情况。按照是否共享分为两类： 1. 线

1. 程序计数器【线程私有】

程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。字节码解释器通过改变这个计数器的值来选取下一条需要执行的字节码指令
为了线程切换后能恢复到正常的执行位置，每条线程都需要一个独立的程序计数器。
特点：
- 如果执行的是java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址
- 如果执行的是native方法，计数器的值为空。
- 在《Java虚拟机规范》中没有规定任何OutOfMemoryError的情况

生命周期与线程相同
虚拟机栈描述的是Java方法执行的线程内存模型：每个方法被执行时，虚拟机会同步创建栈帧用于存储：局部变量表、操作数栈、动态连接、方法出口等信息。方法被调用到执行结束对应着栈帧入栈出栈
局部变量表存放了编译期可知的
- 各种java虚拟机基本数据类型（ boolean,byte,char,short,int,long,double,float）,
- 对象引用(reference类型，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或者其他与此对象相关的位置)
- returnAddress类型（指向了一条字节码指令的地址）
这些数据类型在局部变量表中的存储空间以局部变量槽（SLOT）来表示，其中64位的long和double类型的数据会占用两个变量槽，其余的数据类型只占用一个。
局部变量表所需的内存空间在编译期完成分配，当进入一个方法时，所需要在栈帧中分配多大的局部变量空间时完全确定的，在方法运行期间不会改变局部变量表的大小（槽的数量，虚拟机使用多大内存空间实现变量槽由具体的虚拟机决定）
在规范中有两类异常情况
- StackOverflowError异常：线程请求的栈深度大于虚拟机所允许的深度
- OutOfMemoryError:线程申请栈空间失败，无法申请到足够的内存

与虚拟机栈发挥的作用比较相似
区别
- 虚拟机栈为虚拟机执行Java方法服务
- 本地方法栈为虚拟机调用native方法服务
在规范中有两类异常情况
- StackOverflowError异常：栈深度大于虚拟机所允许的深度
- OutOfMemoryError:申请栈空间失败，无法申请到足够的内存

虚拟机管理的内存中最大的一块
被所有线程共享、在虚拟机启动时创建
唯一目的是存放对象实例
几乎所有的对象都是在堆上分配内存
- 在规范中：所有的对象实例以及数组都应在堆上分配
- 在逃逸分析中：栈上分配和标量替换优化手段，使得java内存所有对象实例都分配在堆上不在绝对
从分配内存的角度看：所有线程共享的Java堆中可以划分出多个线程私有的分配缓冲区（TLAB） ,以提升对象分配时的效率。
将Java堆细分的目的只是为了更好的回收内存，或者更快的分配内存
如果Java堆没有内存完成实例分配且堆无法扩展，会OOM异常

存储虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码缓存等数据
虽然规范中把方法区描述为堆得一个逻辑部分，但是方法区有一个别名叫：非堆。目的是和Java堆区分开
永久代不等于方法区
- Hotspot虚拟机设计团队选择把收集器的分代设计扩展到方法区，或者说使用永久代实现方法区而已，这使得垃圾收集器能够像管理java堆一样管理这部分内存，省去专门为方法区编写内存管理代码
- 在JDK7的Hotspot把原本放在永久代的字符串常量池，静态变量等移动到Java堆中
- 在jdk8完全废弃了永久代的概念，把jdk7中剩余的内存-主要是类型信息全部移到元空间中
方法区内存回收的目标是：类型卸载，常量池的回收，一般来说方法区的回收效果比较令人难以满意
在方法区无法满足新内存的分配需求，将抛出OOM异常

运行时常量池是方法区的一部分。
Class文件除了有类的版本、字段、方法、接口等描述信息外，还有常量池表：用于存放编译器生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中
运行时常量池对class文件常量池的另外一个重要特性时具备动态性，JAVA并不要求常量一定只有编译期才产生，换句话说：并非预置入Class文件中的常量池内容才能进入方法区的运行时常量池。运行期间也可以将新的常量放入池中，比如String::intern
常量池无法再申请到内存时便会抛出OOM异常