JavaEE初阶学习:JVM(八股文)

1.JVM 中的内存区域划分

JVM 其实是一个Java进程~

java 进程会从操作系统这里申请一大块内存区域,给java代码使用~

内存区域进一步划分,给出不同的用途
1.堆 new 出来的对象 (成员变量)
2.栈维护方法之间的调用关系 (局部变量)
3.方法区(旧) / 元数据区 (新) 放的是类加载之后的类对象~~ (静态变量)

这里的考点,主要就是给你一段代码,问你某个变量处于内存的哪个区域~~

看这个变量的形态~~(局部变量,成员变量,静态变量)
和这个变量的类型是无关的

在这里插入图片描述

虚拟机栈,是给 java 代码使用的
本地方法栈,是给 JVM 内部的本地方法使用的(JVM 内部通过C++代码实现的方法)

程序计数器,用途是记录当前程序指定到那个指令了~
简单的 long 类型的变量存了一个内存地址~
内存地址就是下一个要执行的字节码所在的地址~

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

JVM 的线程和操作系统的线程是一对一的关系~~
每次在 java 代码中创建的线程,必然会在系统中有一个对应的线程~

2.JVM 的类加载机制

把 .class 文件加载到内存,得到类对象这样的过程~
程序要想运行,就需要把依赖的"指令和数据"加载到内存中

类加载的步骤非常复杂,我们把他总结成5个词~

1.类加载过程

1.加载

找到 .class 文件,并且读文件内容
找到过程涉及到一个经典的考点,双亲委派模型~

2.验证

.class 文件有明确的数据格式(二进制的)

在这里插入图片描述

3.准备

给类对象分配内存空间(未初始化的空间,内存空间中的数据是全0的)
类对象中的静态成员也是全0的

类加载,最终就是为了得到类对象~

4.解析

针对字符串常量进行初始化~

将常量池内的符号引用替换为直接引用的过程

字符串常量在 .class 文件中就存在了,但是它们只是知道彼此之间的相对位置(偏移量),不知道自己在内存中的实际地址,这个时候的字符串常量就是符号引用~

真正加载到内存中,就会把字符串常量填充到内存中的特定地址上.
字符串常量之间的相对位置还是一致的,但是这些字符串有了自己真正的内存地址

此时的字符串就是直接引用(java 中的普通的引用)

5.初始化

针对类对象进行初始化(初始化静态成员,执行静态代码块,类要是有父类还需要加载父类)

类加载这个动作,什么时候会触发?
不是JVM一启动,就把所有的 .class 都加载了!! 整体是一个"懒加载"的策略(懒汉模式)
非必要,不加载~

什么叫做"必要"
1.创建了这个类的实例
2.使用了这个类的静态方法/静态属性
3.使用子类,会触发父类的加载~

2.双亲委派模型

做的工作,就是在加载中,找 .class 文件这个过程~

在 JVM 中,加载类,需要用到一组特殊的模块,类加载器~~

在 JVM 中,内置了三个类加载器~
BootStrap ClassLoader —> 负责加载 java 标准库中的类
Extension ClassLoader —> 负责加载一些非标准的但是Sun / Oracle 扩展的库的类
Application ClassLoader —> 负责加载项目中自己写的类以及第三方库中的类~

当具体加载一个类的时候,过程是这样的~
需要先给定一个类的全限定类名 “java.lang.String”(字符串)

在这里插入图片描述

BootStrap 没有父亲类加载器了,因此就直接只能自己来搜索自己负责的片区~如果搜索到,就直接后续加载步骤,如果没搜索到,再交给孩子来处理

Extension 收到了父亲的反馈,自己来找~~
如果搜索自己负责的片区,找到了,直接进行后续加载步骤~
如果没搜索到,再交给孩子处理~

Application 收到了父亲的反馈,自己来找~~
如果搜索自己负责的片区,找到了,直接进行后续加载步骤~
如果没搜索到,也是交给孩子处理~
没有孩子了,就抛出一个 ClassNotFoundExeception

3.JVM 中的垃圾回收策略

帮助程序员自动释放内存

C语言中,malloc 的内存必须手动free,否则就容易出现内存泄漏~

java等后续的编程语言,引入了GC来解决上述问题~
能够有效的减少内存泄露的出现概率!

c/c++ 做法是完全让程序员来决定~
比较不靠谱,特别依赖程序员的水平~

java 通过 JVM 自动判定~~ 基于一系列的策略
就可以让这个准确性比较高~但是也会付出一些代价

JVM 中的内存有好几个区域,是释放哪个部分的空间呢?
堆!!!(new 出来的对象)

程序计数器,就是一个单纯存地址的整数,不需要~~随着线程一起销毁.
栈,也是随着线程一起销毁,方法调用完毕,方法的局部变量自然随着出栈操作就销毁了~
元数据区 / 方法区,存的类对象,很少会"卸载"

堆!!! GC的主要目标~
GC 也就是以对象为单位进行释放的~~(说是释放内存,其实是释放对象)

GC 中主要分成两个阶段:

1. 找,谁是垃圾

找的过程就涉及到垃圾回收算法~(基本的思想方法,不代表真实的实现方法)

一个对象,如果后续再也不用了,就可以认为是垃圾!!

如果一个对象,没有引用指向他,此时这个对象一定是无法被使用的()
如果一个对象已经不想用了,但是这个引用可能还指向着~~

java 中只是单纯通过引用没有指向这个操作,来判定垃圾的~
java对于垃圾对象的识别是比较保守的~最大程度避免误杀!!

具体来说,java 怎样知道一个对象是否有引用指向呢?

1.引用计数给对象里安排一个额外的空间,保存一个整数,表示该对象有几个引用指向~(Python,PHP)

给对象增加一个引用计数器，每当有一个地方引用它时，计数器就+1；当引用失效时，计数器就-1；任何时刻计数器为0的对象就是不能再被使用的，即对象已"死"

存在的缺陷:
1.浪费内存空间~~
2.存在循环引用的情况!!(会导致引用计数的判定逻辑出错)

2.可达性分析把对象之间的引用关系,理解成了一个树形结构.从一些特殊的起点出发,进行遍历.只要能遍历访问到的对象,就是"可达".再把"不可达的"当做垃圾即可~
(java)

可达性分析的关键要点,进行上述遍历,需要有"起点"~~
1.栈上的局部变量(每个栈的每个局部变量,都是起点)
2.常量池中引用的对象
3.方法区中,静态成员引用的对象~

可达性分析,总的来说,就是从所有的 gcroots 的起点出发.看看该对象里又通过引用能访问哪些对象,顺藤摸瓜的,把所有可以访问的对象都给遍历一遍(遍历的同时把对象标记为"可达")

剩下的自然就是"不可达"的.

可达性分析自己的缺点:
1.消耗更多的时间~~ 某个对象成了垃圾,也不一定能第一时间发现,因为扫描的过程,需要消耗时间
2.在进行可达性分析的时候,要顺藤摸瓜,一旦这个过程中,当前代码中的对象的引用关系发生变化了,就麻烦了~
因此,为了更准确的完成这个"摸瓜"的过程,需要让其他的业务线程暂停工作!!(STW问题)

2. 释放~~ 把垃圾对象的内存给释放掉

三种典型的策略
1.标记整理

在这里插入图片描述