目录
一、JVM中的内存区域划分
二、JVM的类加载机制
1、类加载的触发时机
2、双亲委派模型
1.1、向上委派
1.2、向下委派
三、JVM中的垃圾回收机制(GC)
1、确认垃圾
1.1、引用计数(Java实际上没有使用这个方案,但是Python、PHP采用了)
1.1.1、循环引用
1.2、可达性分析(被Java采用)
2、释放内存
2.1、标记清除
2.2、复制算法
2.3、标记整理
2.4、分代回收
JVM就是一个Java进程,Java进程会从操作系统中申请一大块内存区域,给Java代码使用。这里申请的一大块内存区域又被进一步划分,给出了不同的用途。
- 堆:存放new出来的对象(也就是说对象中成员变量在堆上)
- 栈:用来维护方法之间的调用关系(也就是说方法中的局部变量在栈上)
- 方法区(Java8之前的叫法)/元数据区(Java8开始的叫法):存放的是类加载之后的类对象(类名.class)。也就是存在被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码缓存等数据的。
❌❌这里需要明确的一点,我们在网上看到的有些资料中,说到内置类型的变量是在栈上,引用类型的变量是在栈上。这个说法是错误的。
- 这里变量在堆上还是在栈上,与这个变量是什么类型无关,如果你在类中定义了一个内置类型的变量,通过new关键字,创建这个类的对象,那么这个内置类型的变量,就是在堆上。
- 判断一个变量在堆上还是在栈上,需要关注的是这个变量是局部变量还是在成员变量,如果是局部变量则这个变量在栈上。如果是成员变量则这个变量在堆上。
public class Test{ public int a; public String b; } class Test1{ public static void main(String[] args){ Test s = new Test(); } } //通过上述的代码,可以看见定义的int类型的变量a是一个内置类型的变量,但是他是一个成员变量,所以它在堆上。 //在main方法中的s变量是对象的引用,他是一个引用类型的变量,他在main方法内部是一个局部变量,所以变量s在栈上。
- 虚拟机栈:早期也叫Java栈,每个线程在创建时都会创建一个虚拟机栈,其内部保存一个个的栈帧,对应这一次次的Java方法调用。虚拟机栈是给Java代码使用的。主管Java程序的运行,它保存方法的局部变量。部分结果,并参与方法的调用和返回。
- 本地方法栈:是给jvm内部的本地方法使用的。(jvm内部是通过C++代码实现的方法)。
- 程序计数器:是用来记录当前程序执行到那个字节码指令了。
堆和元数据区(方法区)在一个JVM进程中只有一份。但是栈(本地方法栈和虚拟机栈)和程序计数器则是存在多份,每个线程中都会存在一份(栈和程序计数器)。
把.class文件加载到内存得到类对象的过程称为类加载。因为程序要执行,就需要把依赖的"指令和数据"加载到内存中。类加载的过程有5个步骤:加载、验证、准备、解析、初始化。
1️⃣加载阶段(Loading)
这个阶段是找到.class文件,并且读取文件内容。这里找class文件的方法中最常问到的是双亲委派模型。
2️⃣验证阶段(Verification)
这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求,保证这些信息被当作代码运行后不会危害虚拟机自身的安全。
3️⃣准备阶段(Preparation)
给类对象分配内存空间,这里分配的内存空间是未初始化的空间,内存空间中的数据是全0的。
4️⃣解析阶段(Resolution)
针对字符串常量进行初始化。也就是Java虚拟机将常量池内的符号引用替换为直接引用的过程。
- 符号引用:字符串常量本身在class文件中存在,但是因为他是在文件中,还没有在内存中,并不直到自己的地址,只能使用一些特殊符号来占位。这就得到了符号引用。
- 直接引用:将字符串常量加载到了内存中,就会把字符串常量填充到内存中的特定地址上,但是字符串在内存中的相对位置与class文件中相对位置还是不变的。
5️⃣初始化阶段(Initialization)
针对类对象进行初始化。初始化静态成员变量、执行静态代码块、如果一个类存在父类,还需要加载父类。
类加载不是JVM一启动,就会把所有的.class文件都在加载了,他是一个"懒加载"的策略,也就是非必要不加载。
只有在下面的情况下才会触发类加载
- 创建了这个类的实例,这个时候就会触发类加载
- 虽然没有创建这个类的实例,但是使用了这个类的静态方法或者静态属性就会触发类加载
- 使用子类,会触发父类的加载
双亲委派模型正对的是Java虚拟机中三个类加载器的,这三个加载器分别是:
- 启动类加载器(BootStrap ClassLoader):负责加载Java标准库中的类
- 扩展类加载器(Extension ClassLoader):负责加载一些非标准库的类,是由Sun/Oracle扩展的库的类。(因为Java最初是是属于Sun公司的但是最后被Oracle公司收购)
- 应用程序类加载器(Application ClassLoader):负责加载项目中自己写的类以及第三方库中的类。
当具体加载一个类的时候,它的过程是:需要先给定一个类的权限定类名"java.lang.String"(字符串)。然后是向上委派,在然后是向下委派
然后从Application ClassLoader这个类加载器开始,收到类加载的请求后,不会自己记载这个类,而是把这个类加载请求向上委派给它的父类去完成,父类收到这个请求后又继续向上委派给自己的父类,一次类推,直到所有的请求委派到启动类加载器中。
BootStrap ClassLoader接收到类加载请求后,先是在自己负责的范围内查找,如果搜索到,就直接进行后续加载步骤(验证、准备、解析、初始化),如果没有搜索到这个类,父类会把这个信息返回交给孩子(Extension ClassLoader)来处理,直到这个请求被成功加载,但是一直到自定义加载器都没有找到,JVM就会抛出ClassNotFund异常
JVM的垃圾回收机制是帮助程序员自动释放内存的。内存释放这是一个比较难把控的事情,因为申请内存的时机是明确的,使用到了就必须申请,释放的时候是模糊的,彻底不使用了才能释放。这就特别依赖程序员的水平,就像C/C++程序员他们释放内存就需要自己手动释放。但是Java通过JVM自动判定,基于一系列策略,就可以让这个准确性比较高。这里我们说的释放内存空间指的就是释放堆上的申请的空间。
垃圾回收主要分为两个阶段:
- 确认垃圾:找没有被引用的对象
- 释放垃圾:将找到的对象释放掉
如何判断一个对象是否有引用指向,这里有两个方法:引用计数和可达性分析。
✨这个引用计数的方法存在两个缺陷。
- 浪费内存空间,空间利用率不高,引用计数占用内存空间。
- 存在循环引用的情况 ,会导致引用计数的判断逻辑出错
当new了两个对象,正常情况下两个对象的引用各自指向引用的对象,但是这个两个对象中的成员变量相互指向对方对象,这个时候,两个对象中的计数器在各自加1.
这个时候,t和t1不在指向之前的引用,两个对象的引用计数都减1,但是这两个对象的引用计数并没有被清空,实际上这两个对象已经不被使用了,但是无法被当作垃圾,无法释放。这两个对象也无法再次被使用,想要使用一个对象,就需要找到另一个对象,这就在逻辑上形成了循环。
把对象之间的引用关系理解成了一个树形结构,从一些特殊的起点出发,进行遍历,只要能遍历访问到的对象,就是"可达的",再把"不可达的"当作垃圾即可。
✨可达性分析的关键要点,进行上述遍历,需要有"起点"被称为gcroots
- 栈上的局部变量(每个栈的每个局部变量,都是起点)
- 常量池中引用的对象
- 方法区中,静态成员引用的对象
可达性分析,总的来所,就是从所有的gcroots的起点出发,看看该对象里又通过引用能访问那些对象,依次遍历,把所有可以访问的对象都给遍历一遍(遍历的同时把对象标记成"可达"),剩下的遍历不到的对象就是"不可达".
可达性分析的特点:可达性分析克服了引用计数的两个缺点,但是也有自己的问题
- 消耗的时间更多,因此某个对象成了垃圾,也不一定能第一时间发现,因为扫描的过程,需要消耗时间
- 在进行可达性分析的时候,依次遍历,一旦这个过程中,当前代码中的对象引用关系发生了变化,这就会使情况变得更加复杂。比如,当一个对象指向下一个对象,刚遍历完这个对象,这个对象的引用变了。因此,我们为了更准确的遍历,需要让其他的业务线程暂停工作(STW问题)。
这里存在三个典型的策略:
- 标记清除
- 复制算法
- 标记整理
- 分代回收
前三种释放内存的方式都存在一定的缺点,所以实际上JVM的实现思路,是结合了上述的几种思想方法。
这种策略,就是直接把垃圾对象的内存释放,但是这个方式的缺点就是会产生内存碎片。
我们从内存中申请空间的时候,都是整块的连续的空间,现在这里空闲的空间是离散的,独立的空间,总的空间可能很大。假如总的空闲的空间可能超过了1G,但是你想申请500MB可能都不一定申请到。
为了解决内存碎片的问题,又引入了复制算法。复制算法,十八整个内存空间,分成两半,一次只用一半。
复制算法解决了内存碎片化的问题,但是也有缺点
- 内存利用率比较低
- 如果当前的对象大部分都是要留的,垃圾很少,此时复制成本就比较高
这个方法,也可以结局内存碎片化的问题,但是他的搬运开销还是比较大的。
针对不同的情况,使用不同的策略。给对象设定"年龄"这样的概念(当然这个单位并不是年龄,这里用年龄作为类比),描述了这个对象存在多久了,如果一个对象刚创建,认为是0岁,没经过一轮扫描(可达性分析),没有被标记成垃圾,这个时候对象就涨一岁,通过这个年龄来区分这个对象的存活时间。
根据年龄的大小来区分采用什么样的策略
- 新城建的对象,放到伊甸区,当垃圾回收扫描到伊甸区之后,绝大部分对象都会在第一轮GC中被回收
- 如果伊甸区的对象,在第一轮的GC中没有被回收,就会通过复制算法,拷贝到幸存区,幸存区分成了大小均等的两部分,一次只使用其中的一半。垃圾回收扫描幸存区的对象,发现垃圾,通过复制算法,将不是垃圾的对象复制到生存区的另一半空间中,然后将前一半的空间全部释放。
- 当这个对象在生存区,经过了若干轮GC之后,年龄增长到一定的程度,就会通过复制算法拷贝到到年代。
- 进入老年代的对象,年龄都很大了,在消亡的概率就比前面的新生代中的对象小了很多,针对老年代GC的扫描频次就会降低很多。如果老年代中出现了垃圾对象,就会使用标记整理的算法进行清理,因为老年代中消亡的对象就很少了,所以使用标记整理的算法开销还不是很大。
- 特殊情况:如果对象非常大,直接进入老年代(大对象进行复制算法,成本比较高,而且大对象也不是很多)
根据经验规律:如果一个对象存活的时间很长了,他将继续存在更长的时间。