1、JVM运行时数据区
-
线程共享数据区:方法区、堆
-
线程隔离数据区:虚拟机栈、本地方法栈、堆、程序计数器
-
JVM内存模型之程序计算器
a、程序计数器是一块较小的内存空间,它可以看作是当前线程所执行的字节码的行号指示器
b、线程是一个独立的执行单元,是由CPU控制执行的
c、字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令,分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成
d、为了线程切换后能恢复到正确的执行位置,每条线程都需要有一个独立的程序计数器,各条线程之间计数器互不影响,独立存储,我们称这类内存区域为“线程私有”的内存
e、内存区域中唯一一 个没有规定任何 OutOfMemoryError 情况的区域 -
JVM内存模型之java虚拟机栈
a、用于作用于方法执行的一块Java内存区域
b、每个方法在执行的同时都会创建一个栈帧(Stack Framel)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中入栈到出栈的过程
c、局部变量表存放了编译期可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)以及对象引用(reference 类型)
d、如果线程请求的栈深度大于虚拟机所允许的深度,将抛出 StackOverflowError 异常 -
JVM内存模型之本地方法栈
a、用于作用于本地方法执行的一块Java内存区域
b、与Java虚拟机栈相同,每个方法在执行的同时都会创建一个栈帧(Stack Framel)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中入栈到出栈的过程
c、Hotshot将Java虚拟机栈和本地方法栈合二为一 -
JVM内存模型之JAVA堆
a、是Java内存区域中一块用来存放对象实例的区域,【几乎所有的对象实例都在这里分配内存】
b、此内存区域的唯一目的就是存放对象实例
c、Java 堆(Java Heap)是 Java 虚拟机所管理的内存中最大的一块,是被所有线程共享的一块内存区域
d、Java 堆是垃圾收集器管理的主要区域,因此很多时候也被称做“GC 堆”
e、Java堆可以分成新生代和老年代 新生代可分为To Space、From Space、Eden -
JVM内存模型之方法区
a、是各个线程共享的内存区域,它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据(类信息:类版本号、方法、接口)
b、Hotspot使用永久代来实现方法区 JRockit、IBM J9VM Java堆一样管理这部分内存
c、并非数据进入了方法区就如永久代的名字一样“永久”存在了。这区域的内存回收目标主要是针对常量池的回收和对类型的卸载
d、方法区也会抛出OutofMemoryError,当它无法满足内存分配需求时
2、GC垃圾回收
对象是否存活判断:
堆中每个对象实例都有一个引用计数。当一个对象被创建时,且将该对象实例分配给一个变量,该变量计数设置为1。当任何其它变量被赋值为这个对象的引用时,计数加1(a = b,则b引用的对象实例的计数器+1),但当一个对象实例的某个引用超过了生命周期或者被设置为一个新值时,对象实例的引用计数器减1。任何引用计数器为0的对象实例可以被当作垃圾收集。当一个对象实例被垃圾收集时,它引用的任何对象实例的引用计数器减1
对象存活算法引用计数法
- 引用计数收集器可以很快的执行,交织在程序运行中。对程序需要不被长时间打断的实时环境比较有利。
- 无法检测出循环引用。如父对象有一个对子对象的引用,子对象反过来引用父对象。这样,他们的引用计数永远不可能为0.
- 加配置项: -verbose:gc -XX:+PrintGCDetails
对象存活算法可达性分析
- 程序把所有的引用关系看作一张图,从一个节点GC ROOT开始,寻找对应的引用节点,找到这个节点以后,继续寻找这个节点的引用节点,当所有的引用节点寻找完毕之后,剩余的节点则被认为是没有被引用到的节点,即无用的节点
- java中可作为GC Root的对象有:
a、虚拟机栈中引用的对象(本地变量表)
b、本地方法栈中引用的对象
c、方法区中静态属性引用的对象
d、方法区中常量引用的对象
垃圾回收算法之标记清除
最基础的收集算法是“标记-清除”(Mark-Sweep)算法,如同它的名字一样,算法分为“标记”和“清除”两个阶段:
- 首先标记出所有需要回收的对象,在标记完成后统一回收所有被标记的对象
- 它的主要不足有两个:
a、一个是效率问题,标记和清除两个过程的效率都不高;
b、另一个是空间问题,标记清除之后会产生大量不连续的内存碎片,空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时,无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作
垃圾回收算法之复制算法
- 为甚么出现复制算法?
a、为了解决效率问题,一种称为“复制”(Copying)的收集算法出现了,它将可用内存按量划分为大小相等的两块,每次只使用其中的一块
b、当这一块的内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收,内存分配时也就不用考虑内存碎片等复杂情况,只要移动堆顶指针,按顺序分配内存即可,实现简单,运行高效 - 现在的商业虚拟机都采用这种收集算法来回收新生代,研究表明,新生代中的对象 98%是“朝生夕死”的,所以并不需要按照 1:1 的比例来划分内存空间,而是将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间,每次使用 Eden 和其中一块 Survivor。 Survivor from 和Survivor to ,内存比例 8:1:1
- 当回收时,将 Eden 和 Survivor 中还存活着的对象一次性地复制到另外一块 Survivor 空间上,最后清理掉 Eden 和刚才用过的 Survivor 空间。HotSpot 虚拟机默认 Eden 和 Survivor 的大小比例是 8:1, 也就是每次新生代中可用内存空间为整个新生代容量的 90% (80%+10%),只有 10% 的内存会被“浪费”。当然,98%的对象可回收只是一般场景下的数据,我们没有办法保证每次回收都只有不多于 10%的对象存活,当 Survivor 空间不够用时,需要依赖其他内存(这里指老年代)进行分配担保(Handle Promotion)。
垃圾回收算法之标记整理与分代收集算法
- 标记整理算法解决了什么问题
a、复制收集算法在对象存活率较高时就要进行较多的复制操作,效率将会变低。更关键的是,如果不想浪费 50%的空间,就需要有额外的空间进行分配担保,以应对被使用的内存中所有对象都 100%存活的极端情况,所以在老年代一般不能直接选用这种算法 - 标记-整理
a、根据老年代的特点,有人提出了另外一种“标记-整理(Mark- Compact)算法,标记过程仍然与“标记-清除”算法一样,但后续步骤不是直接对可回收对象进行清理,而是让所有存活的对象都向一端移动,然后直接清理掉端边界以外的内存 - 分代收集
a、一般把 Java 堆分为新生代和老年代,这样就可以根据各个年代的特点采用最适当的收集算法
b、在新生代中,每次垃圾收集时都发现有大批对象死去,只有少量存活,那就选用复制算法,只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保,就必须使用“标记-清理”或者“标记一整理”算法来进行回收