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.标记整理

直接把垃圾对象的内存进行释放
这种方式会产生内存碎片!!(申请的空间都是申请的"整块的连续空间",现在这里空闲的空间是离散的,独立的空间,)

2.复制算法
把整个内存空间,分成两段~~
一次只用一半~

复制算法,就把不是垃圾的对象.拷贝到另外一边.
然后再统一释放整个区域!!

复制算法,解决了内存碎片的问题,也有缺点!!
1.内存利用率比较低!
2.如果当前的对象大部分都是要保留的,垃圾很少,此时复制成本就比较高~

3.标记整理

类似于顺序表删除中间元素,有一个搬运过程~

1.解决了内存碎片问题
2.但是搬运的开销也比较大

因此,实际的 JVM 的实现思路,是结合了上述几种思想方式~

分代回收思想

分代算法和上面讲的 3 种算法不同，分代算法是通过区域划分，实现不同区域和不同的垃圾回收策略，从而实现更好的垃圾回收

给对象设定了"年龄"这样的概念~描述了这个对象存在多久了.
如果一个对象刚诞生,认为是0岁
每次经过一轮扫描(可达性分析),没被标记成垃圾,这个时候对象就长一岁!
通过对象来区分这个对象的存活时间~

针对不同年龄的对象采取不同的回收策略~

1.新创建的对象,放到伊甸区.
当垃圾回收扫描到伊甸区之后,绝大部分对象都会在第一轮gc 中就被干掉~~大部分对象是活不过一岁的(经验规律)
朝生夕死~

2.如果伊甸区的对象,熬过第一轮GC,就会通过复制算法,拷贝到生存区~~

生存区分成两半(大小均等),一次只使用其中一半~

垃圾回收扫描伊甸区的对象,也是发现垃圾就淘汰,不是垃圾的,通过复制算法,复制到生存区的另外一半 ~

3.当这个对象在生存区，熬过若干轮gc之后,年龄增长到一定程度了，就会通过复制算法拷贝到老年代(多年的媳妇熬成婆了)

4.进入老年代的对象,年龄都挺大了，再消亡的概率比前面新生代中的对象小不少,针对老年代的gc 的扫描频次就会降低很多

如果老年代中发现某个对象是垃圾了，使用标记整理的方式清除~~

5.特殊情况:如果对象非常大,直接进入老年代(大对象进行复制算法，成本比较高,而且大对象也不会很多.…)