简介

JVM 其实就是一个Java进程 , 从操作系统申请一大块内存区域, 供 java 代码使用 .

申请出的内存 , 进一步划分 , 给出不同的用途 .

JVM 内存区域划分 :

堆中存放就是 new 出来的对象. (成员变量)

栈是用来维护方法之间的调用关系 (局部变量)

元数据区(或者叫方法区) 存放的是类加载之后的类对象与静态变量

虚拟机栈是给 java 代码使用的, 本地方法栈是给 jvm 内部的本地方法(C++代码)使用的 .

可以认为虚拟机栈中包含了很多个元素, 每一个元素表示一个方法 , 每个元素称为是一个栈帧 , 每一个栈帧会包含这个方法的入口地址 , 方法参数是啥 , 放回地址是啥, 局部变量....等

堆和元素数据区 , 在一个 jvm 进程中 , 只有一份. 栈(本地方法栈和虚拟机栈) 和程序计数器则是存在多份的 (每个线程都要一份).

程序计数器用来记录当前线程执行到那个指令了.

由于函数调用, 也有了"后进先出" 的特点 .

数据结构的栈, 是一个通用的概念, 更广泛的概念, 此处的栈, 特指 JVM 上的一块内存空间 .

JVM 类加载机制

类加载就是 .class文件从文件(硬盘) 被加载到内存中(元数据区)这样一个过程.

经历这么一个过程目的是要得到类对象 .

主要分为如下 5 步骤 :

1 . 加载 (把 .class 文件找到,打开文件,将文件内容读到内存中)

2 . 验证 (检查 .class 文件格式对不对, 在官方提供的 JVM 虚拟机规范文档上详细描述了 .class 文件的格式)

3 . 准备 (给类对象分配空间)

4 . 解析 (针对字符串常量进行初始化) (常量池内的符号引用替换为直接引用的过程)

字符串常量在 .class 文件中就已经存在, 但它们只是知道彼此之间的相对位置(偏移量) , 不知道自己在内存中的实际地址 .这时候的字符串常量就是符号引用 . 直到真正加载到内存中 , 就会把字符串常量填充到内存中的特定位置上 , 但字符串常量之间的相对位置还是一样的 , 这时字符串有了自己真正的内存地址 .

5 . 初始化 (针对类对象进行初始化静态成员 , 执行静态代码块.......)

类加载采用的策略是 "懒加载" , 非必要 , 不加载

触发类加载的情况有 : 1. 创建了这个类的实例 . 2. 使用了这个类的静态方法 / 静态属性

3 . 使用子类, 会触发父类的加载 .

双亲委派模型

双亲委派模型描述的是 : 在加载的时候 找 .class 文件的这个过程 .

在 JVM 中内置了 3个类加载器 , 目的就是为了加载类.

BootStrap ClassLoader 负责加载 Java 标准库中的类.

Extension ClassLoader 负责加载一些非标准的但是 Sun / Oracle 扩展的库的类.

Application ClassLoader 负责加载项目中自己写的类以及第三方库中的类 .

首先加载一个类的时候 , 是先从Application ClassLoader 开始 , 但 Application ClassLoader 会把加载任务交给父亲 , 让父亲去进行 , 当交给 Extension ClassLoader时, 它也交给了它的父亲 BootstrapClassLoader , 交给BootstrapClassLoader 后 , 它没有父亲 , 于是自己进行加载 , 此时 BootstrapClassLoader 就会搜索自己负责的标准库目录的相关的类 , 如果找到,就加载 , 如果没有找到, 就继续有子类加载器进行加载 .

如果BootstrapClassLoader 没有加载 , 则ExtensionClassLoader 真正搜索扩展库相关的目录,如果找到就加载, 如果没找到, 就由子类加载器进行加载.

如果ExtensionClassLoader没有加载 , 则 Application ClassLoader 真正搜索用户项目相关的目录 , 如果找到就加载, 没找到,由子类加载器进行加载.

当Application ClassLoader 也没有加载 , 那么就会抛出异常.

垃圾回收机制 GC

垃圾指的就是不再使用的内存 .

垃圾回收: 就是把不用的垃圾帮我们自动释放了.

GC 的好处 : 非常省心 , 让程序猿写代码简单点 , 不容易出错 .

GC 的坏处 : 需要消耗额外的系统资源 , 也有额外的性能开销 .

另外 GC还有一个关键的问题 : STW (stop the world) .

STW : 如果有时候 , 内存中的垃圾已经很多了 , 此时触发一次 GC 操作 , 开销可能非常大 , 大到把系统资源吃了大半 , 另一方法GC回收垃圾的时候可能会涉及到一些锁操作 , 导致业务代码无法正常执行 , 这样的卡顿, 极端情况下, 可能是出现几十毫秒甚至上百毫秒 .

但从Java 13 开始引入了 zgc 这个垃圾回收器 , 能使 STW 控制在 1ms 以下.

GC 主要是针对堆进行释放的

栈 : 栈帧随着方法的调用申请, 随着方法的结束而释放 , 不需要使用到 GC

程序计数器 : 随着线程销毁,不需要用到GC.

元数据区/方法区 : 存的是类对象 , 很少会 ' 卸载 '.

GC 是以对象为单位进行释放的 .

GC 的工作分为两个阶段 :

1 . 找到垃圾 (也就是判定垃圾)

2 . 再进行对象的释放 .

找到垃圾

在 Java 中 , 使用对象 , 只有通过引用来使用 !
如果一个对象 , 有引用指向它 , 则就有可能被使用到 . 不能进行释放. 如果一个对象 , 没有引用指向它 , 则认为不会再被使用了 .

1) 引用计数 [ java 没有使用]

给每个对象分配一个计数器, 每次创建一个引用指向该对象, 计数器就+1. 每次该引用被销毁了 , 计数器就 -1.

缺点 :

1) 内存空间浪费的多 (利用率低) .

如果每个对象都要分配一个计数器 , 按照4 个字节算,如果对象多了, 占用的额外空间就会很多 .

2) 存在循环引用的问题

但是 , 如果 a 和 b 引用销毁 , 此时 1 号对象和 2号对象引用计数都 -1, 但是结果都还是 1, 不是 0 , 因此不能释放内存 , 但是这两个对象已经没有办法被访问到了.

2) 可达性分析 (java 的做法)

可达性分析 : 把所有这些对象被组织的结构视为是树 , 从根节点出发 , 遍历树 , 所有能被访问到的对象 , 标记为 "可达" , 不能访问到的就是不可达 .不可达的就可以作为垃圾进行回收了.

可达性分析需要进行类似于 "树遍历" 这个操作相比于引用计数来说 . 会慢一点 , 但是可达性操作并不需要一直执行 , 只需要每隔一段时间执行一次就行了.

可达性分析遍历的起点 , 称为 GCroots . (栈上的局部变量,常量池中的对象,静态成员变量) , 因此代码中有很多这样的起点 , 把每个起点都往下遍历一遍 , 就完成了一次扫描过程 .

清理垃圾

1 . 标记清除

缺点 : 内存碎片问题 , 被释放的空间是零散的 , 不是连续的 , 申请内存要求是连续空间 .

2 . 复制算法

将内存分为两半 .

假设 2 4 6 是垃圾, 将 1 3 5 复制到另一半, 然后将左边的空间全部清除.

每次触发复制算法 , 都是向另外一侧进行赋值 , 内存中的数据拷贝过去 .

缺点 :

1) 空间利用率低

2) 如果要是垃圾少 , 有效的对象多 , 复制成本就比较大了 .

3 . 标记整理

解决了复制算法的缺点 , 类似于顺序表删除中间元素 , 会有元素搬运的操作.

假设要删除 1 2 4 , 得到如下 :

虽然说保证了空间利用率 , 也解决了内存碎片化问题 , 但是效率不高 , 如果搬运的空间比较大, 此时开销也很大 .

分代回收

上述的 3 个方法都不完美 , 都有明显的缺点 .

因此基于上述的 3 中方法 , 搞了一个复合策略 "分代回收".

基于一个经验规律 : 如果一个东西, 存在的时间比较长了 , 那么大概率还会继续的长时间的持续存在下去 .

给对象引入一个概念 : 年龄 (这里的年龄指的是熬过 GC 的轮次) , 年龄越大表示存在的时间就越久 .(经过了一轮可达性分析的遍历, 发现这个对象还不是垃圾, 这就是"熬过了一轮GC")

划分为一系列区域 :