文中涉及JVM底层知识大多来自《深入理解Java虚拟机》第2版,内容枯燥乏味,如果看,认真看。跟着撸一遍也可以受益良多。
1、JVM:是运行在操作系统之上的,它与硬件没有直接的交互。
运行过程:
我们都知道 Java 源文件,通过编译器,能够生产相应的.Class 文件,也就是字节码文件,
而字节码文件又通过 Java 虚拟机中的解释器,编译成特定机器上的机器码 。
Java 源文件—->编译器—->字节码文件—->JVM—->机器码 |
JVM 内存区域主要分为线程私有区域【程序计数器、虚拟机栈、本地方法区】、线程共享区域【JAVA 堆、方法区】。
- 程序计数器(Program Counter Register)( 线程私有)
一块较小的内存空间, 是当前线程所执行的字节码的行号指示器,每条线程都要有一个独立的程序计数器,这类内存也称为“线程私有”的内存。正在执行 java 方法的话,计数器记录的是虚拟机字节码指令的地址(当前指令的地址)。
取下一条需要执行的字节码指令,分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
2)虚拟机栈(Java Virtual Machine Stacks)(线程私有)
是描述java方法执行的内存模型,每个方法在执行的同时都会创建一个栈帧,用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
栈帧( Frame)是用来存储数据和部分过程结果的数据结构,同时也被用来处理动态链接(Dynamic Linking)、 方法返回值和异常分派( Dispatch Exception)。栈帧随着方法调用而创建,随着方法结束而销毁——无论方法是正常完成还是异常完成(抛出了在方法内未被捕获的异常)都算作方法结束。
局部变量表,就是通常说的栈内存(Stack),局部变量表所需的内存空间在编译期间完成分配,在方法运行期间不会改变局部变量表的大小。
当前大部分的虚拟机栈可以动态扩展(也允许固定长度的虚拟机栈),如果扩展时无法申请到足够的内存,就会抛出OutOfMemoryError异常。另外如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError异常;
3)本地方法栈(Native Method Stack)( 线程私有)
本地方法区和虚拟机栈作用类似, 区别是虚拟机栈为执行 Java 方法服务, 而本地方法栈则为Native 方法服务。
虚拟机规范中对本地方法栈中方法使用的语言、使用方式与数据结构并没有强制规定,因此具体的虚拟机可以自由实现它。
有的虚拟机(譬如Sun HotSpot虚拟机)直接就把本地方法栈和虚拟机栈合二为一。
同样,本地方法栈区域也会抛出StackOverflowError和OutOfMemoryError异常。
4)java堆(Heap)线程共享)- 运行时数据区
是被线程共享的一块内存区域,是Java虚拟机所管理的内存中最大的一块区域,可以处于物理上不连续的内存空间中,只要逻辑上是连续的即可。通过-Xmx和-Xms控制Java堆大小。
几乎所有的对象实例和数组都保存在 Java 堆内存中。(在Java虚拟机规范中的描述是:所有的对象实例以及数组都要在堆上分配)。
也是垃圾收集器进行垃圾收集的最重要的内存区域。由于现代 VM 采用分代收集算法, 因此 Java 堆从 GC 的角度还可以细分为: 新生代( Eden 区 、 From Survivor 区 和 To Survivor 区 )和老年代(简单提一下垃圾回收,下次再进行垃圾回收的学习)。
虚拟机中有非常频繁的对象创建的行为,new一个对象实例的时候jvm就会在java堆内存中为对象实例分配一块内存空间(这里涉及到对象创建时的内存分配问题,以后再进行学习)。如果在堆中没有内存完成实例分配,并且堆也无法再扩展时,将会抛出OutOfMemoryError异常。
5)方法区(Method Area)(线程共享)
很多人都更愿意把方法区称为“永久代”(Permanent Generation),本质上两者并不等价。
方法区用于存储被 JVM 加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
HotSpot VM把GC分代收集扩展至方法区, 即使用Java堆的永久代来实现方法区, 这样 HotSpot 的垃圾收集器就可以像管理 Java 堆一样管理这部分内存,而不必为方法区开发专门的内存管理器(永久代的内存回收的主要目标是针对常量池的回收和类型的卸载, 因此收益一般很小)。
运行时常量池(Runtime Constant Pool)是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述等信息外,还有一项信息是常量池(Constant Pool Table),用于存放编译期生成的各种字面量和符号引用,这部分内容将在类加载后存放到方法区的运行时常量池中。Java 虚拟机对 Class 文件的每一部分(自然也包括常量池)的格式都有严格的规定,每一个字节用于存储哪种数据都必须符合规范上的要求,这样才会被虚拟机认可、装载和执行。
2、JVM 运行时内存
Java 堆从 GC 的角度还可以细分为: 新生代( Eden 区 、 From Survivor 区 和 To Survivor 区 )和老年代。
![57a73805686162b9e8ce863f65427494.png](https://i-blog.csdnimg.cn/blog_migrate/e40cc1574aff79ecc8ead9bd3cb8c21e.png) |
2.1、新生代:
是用来存放新生的对象。一般占据堆的1/3空间。由于频繁创建对象,所以新生代会频繁触发MinorGC 进行垃圾回收。新生代又分为 Eden 区、ServivorFrom、ServivorTo 三个区。
1)Eden 区:
Java新对象的出生地(如果新创建的对象占用内存很大,则直接分配到老年代)。当Eden区内存不够的时候就会触发MinorGC,对新生代区进行一次垃圾回收。
2)、ServivorFrom
上一次 GC 的幸存者,作为这一次 GC 的被扫描者。
3)、ServivorTo
保留了一次 MinorGC 过程中的幸存者。
MinorGC 的过程(
复制->清空->互换
);MinorGC 采用
复制算法
。
1:eden、servicorFrom复制到ServicorTo,年龄+1
首先,把 Eden和 ServivorFrom区域中存活的对象复制到 ServicorTo区域(如果有对象的年龄以及达到了老年的标准,则赋值到老年代区),同时把这些对象的年龄+1(如果 ServicorTo 不够位置了就放到老年区);
2:清空 eden 、servicorFrom
然后,清空 Eden 和 ServicorFrom 中的对象;
3:ServicorTo和ServicorFrom 互换
最后,ServicorTo 和 ServicorFrom 互换,原 ServicorTo 成为下一次 GC 时的 ServicorFrom区。
2.2、老年代:
主要存放应用程序中生命周期长的内存对象。
老年代的对象比较稳定,所以 MajorGC 不会频繁执行。在进行 MajorGC 前一般都先进行了一次 MinorGC,使得有新生代的对象晋身入老年代,导致空间不够用时才触发。当无法找到足够大的连续空间分配给新创建的较大对象时也会提前触发一次 MajorGC 进行垃圾回收腾出空间。
MajorGC 采用标记清除算法
:首先扫描一次所有老年代,标记出存活的对象,然后回收没有标记的对象。MajorGC 的耗时比较长,因为要扫描再回收。MajorGC 会产生内存碎片,为了减少内存损耗,我们一般需要进行合并或者标记出来方便下次直接分配。当老年代也满了装不下的时候,就会抛出 OOM(Out of Memory)异常。
2.3、永久代:
指内存的永久保存区域
主要存放 Class 和 Meta(元数据)的信息,Class 在被加载的时候被放入永久区域,它和存放实例的区域不同,GC 不会在主程序运行期对永久区域进行清理。所以这也导致了永久代的区域会随着加载的 Class 的增多而胀满,最终抛出 OOM 异常。
3、垃圾回收与算法
![edf7e6408f1683c02cc9f069a1e30f45.png](https://i-blog.csdnimg.cn/blog_migrate/2ab7ab3b30fa4cd1a9b4be772cf3eb1e.png) |
3.1、如何确定垃圾
1)引用计数法
在 Java 中,引用和对象是有关联的。如果要操作对象则必须用引用进行。因此,很显然一个简单的办法是通过引用计数来判断一个对象是否可以回收。简单说,即一个对象如果没有任何与之关联的引用,即他们的引用计数都不为 0,则说明对象不太可能再被用到,那么这个对象就是可回收对象。但是,主流的Java虚拟机里面没有选用引用计数算法来管理内存,其中最主要的原因是它
很难解决对象之间相互循环引用的问题
。
2)可达性分析
为了解决引用计数法的循环引用问题,Java 使用了可达性分析的方法。通过一系列的“
GC roots
”对象作为起点搜索,搜索所走过的路径称为引用链。如果在“GC roots”和一个对象之间没有可达路径(引用链),则称该对象是不可达的。
如图所示,对象object 5、object 6、object 7虽然互相有关联,但是它们到GC Roots是不可达的,所以它们将会被判定为是可回收的对象。
要注意的是,不可达对象不等价于可回收对象,不可达对象变为可回收对象至少要经过两次标记过程。两次标记后仍然是可回收对象,则将面临回收。
扩展:在Java语言中,可作为GC Roots的对象包括下面几种(但你还要知道为什么这些对象可以作为GC Roots,可以把你的理解写在下方的评论里面):
3.2、垃圾如何回收1--( 标记清除算法Mark-Sweep )
标记清除算法,分为两个阶段,标注和清除。标记阶段标记出所有需要回收的对象,清除阶段回收被标记的对象所占用的空间。如图(未使用
、存活对象
、可回收对象
)
![3e559d0b92092f970e5f979652556912.png](https://i-blog.csdnimg.cn/blog_migrate/44d0fbd3fc1bccd46055d900f99ba39a.png) | 从图中我们就可以发现,该算法最大的问题是内存碎片化严重,后续可能发生大对象不能找到可利用空间的问题。 |
3.3、垃圾如何回收2--( 复制算法copying )
为了解决 Mark-Sweep 算法内存碎片化的缺陷而被提出的算法。按内存容量将内存划分为等大小的两块。每次只使用其中一块,当这一块内存满后将尚存活的对象复制到另一块上去,把已使用的内存清掉,如图(未使用 、存活对象 、可回收对象 )
![0bcc651318a094c3133408a392bbc1bc.png](https://i-blog.csdnimg.cn/blog_migrate/8d8f09a082637fcac643878a11c92f3e.png) | 这种算法虽然实现简单,内存效率高,不易产生碎片,但是最大的问题是可用内存被压缩到了原本的一半。且存活对象增多的话,Copying 算法的效率会大大降低。 |
3.4、垃圾如何回收3--( 分代收集算法 )
分代收集法是目前大部分 JVM 所采用的方法
,其核心思想是根据对象存活的不同生命周期将内存划分为不同的域。
一般情况下将 GC 堆划分为老生代(Tenured/Old Generation)和新生代(YoungGeneration)。老生代的特点是每次垃圾回收时只有少量对象需要被回收,新生代的特点是每次垃圾回收时都有大量垃圾需要被回收,因此可以根据不同区域选择不同的算法。
- 新生代MinorGC采用复制算法
每次垃圾收集都能发现大批对象已死, 只有少量存活。因此选用复制算法, 只需要付出少量存活对象的复制成本就可以完成收集。
- 老年代MajorGC采用标记清除算法
因为对象存活率高、没有额外空间对它进行分配担保, 就必须采用“
标记-清除
”算法来进行回收, 不必进行内存复制, 且直接腾出空闲内存。