目录
JVM 也就是启动的时候,会申请到一整个很大的内存区域
JVM 是一个应用程序,要从操作系统这里申请内存(相当于租了个写字楼)
JVM 就根据需要,把整个空间,分成几个部分,每个部分各自有不同的功能作用
堆,是整个 JVM 空间最大的区域
new 出来的对象,都是在 堆 上,类的成员变量,也是在堆上面
堆是一个进程只有一份的,栈是每个线程有一份,一个进程有多个
堆,多个线程用的都是同一个堆,栈,每个线程用自己的栈
每个 jvm ,就是一个 java 进程,如果弄两个 java 进程,就是两个 jvm 了
类对象,常量池,静态成员等都存放在这里
如何判断某个变量在哪个区域上?
1、局部变量:在 栈 上
2、普通成员变量:在 堆 上
3、静态成员变量:在 方法区 / 元数据区
准确的来说,类加载就是 .class 文件,从文件(硬盘)被加载到内存中(元数据区)这样的一个过程
加载:把 .class 文件找到(找的过程),打开文件,读文件,把文件内容读到内存中
验证:根据 jvm 虚拟机规范,检查下 .class 文件格式是否正确
准备:给类对象分配内存空间(现在元数据区占个位),此时内存初始化成全为0,也会使静态成员设置成 0 值
解析:初始化字符串常量,把符号引用转为直接引用
初始化:调用构造方法,进行成员的初始化,执行代码块,静态代码块,加载父类 .....
把符号引用转为直接引用:字符串常量,得有一块内存空间,来存这个字符的实际内容,还得有一个引用,来保存这个内存空间的起始地址
在类加载之前,字符串常量,此时是处在 .class 文件中的,此时 “引用” 记录的并非字符串常量的真正的地址,而是它在文件中的 “偏移量” 这个东西(或者是个占位符)
类加载之后,才真正把这个字符串常量给放到内存中,此时才有 “内存地址”,这个引用才能真正被赋值成指定内存地址(直接引用)
类加载到底什么时候会触发?
不是 java 程序一运行,就把所有的类都加载的,而是真正用到才加载(懒汉模式)
1、构造 类 的实例
2、调用这个类的静态方法 / 使用静态属性
3、加载子类,就会先加载其父类
一旦加载过之后,后续再使用,就不必重复加载了
双亲委派模型,描述的是这个加载,找 .class 文件的基本过程
JVM 默认提供了三个类加载器,他们三个各有分工
1、BootstrapClassLoader ,负责加载标准库中的类(Java 规范,要求提供哪些类,无论是哪种 JVM 的实现,都会提供一样的类)
2、ExtensionClassLoader ,负责加载 JVM 扩展库中的内容(规范之外,由实现 JVM 的厂商 / 组织,提供的额外的功能)
3、ApplicationClassLoader ,负责加载用户提供的第三方库 / 用户项目代码中的类
上述三个类,存在 “父子关系”,(不是父类子类,相当于每个 classLoader 有一个 parent 属性,指向自己的父 类加载器)
上述三个类加载器如何配合工作?
首先,加载一个类的时候,是先从 ApplicationClassLoader 开始,但是 ApplicationClassLoader 会把加载任务交给父亲,让父亲去进行
于是 ExtensionClassLoader 要去加载了,但是也不是真加载,而是再委托自己的父亲
于是 BootstrapClassLoader 要去加载了,也是想委托自己的父亲,结果发现自己的父亲是 null,没有父亲 / 父亲加载完了,没找着类,才由自己进行加载
此时,BootstrapClassLoader 就会搜索自己负责的标准库目录相关的类,如果找到就加载,如果没找到,就继续由子 类加载器 进行加载,于是 ExtensionClassLoader 真正搜索扩展库相关的墓库,如果找到就加载,如果没找到就还是由子 类加载器 进行加载
ApplicationClassLoader 真正搜索用户项目相关的目录,没找到就由子类加载器进行加载(由于当前没有 子 了,就只能抛出 类找不到 这样的异常)
为什么要有上述这个顺序?
上述这套顺序,其实出自于 jvm 实现代码的逻辑,这段代码大概是类似于 “递归” 的方式写的
这个顺序,最主要的目的就是为了保证 BootstrapClassLoader 能够先加载,ApplicationClassLoader 能够后加载,这就可以避免用户创建了一些奇怪的类,引起不必要的 bug
假设用户在自己的代码中,写了个 java.lang.String 这个类,按照上述加载流程, jvm 加载的还是标准库的类,不会加载到用户自己写的类
这样就能保证,即使出现上述问题,也不会让 jvm 已有代码混乱,最多是用户自己写的类不生效罢了
再另一方面,类加载器其实是可以用户自定义的,上述三个类加载器是 jvm 自带的,用户自定义的类加载器,也可以加入到上述流程,就可以和先有的加载器配合使用
站在 jvm 的角度,类加载的核心应该是:解析 .class 文件,解析每个字节是干什么的
破坏双亲委托模型:
自己写的类加载器,可以去遵守也可以不遵守,是否遵守,主要是看需求
tomcat ,,去加载 webapp 这里就是单独的类加载器,不遵守双亲委派模型
什么是垃圾?
垃圾指的是不再使用的内存
垃圾回收就是把不用的内存帮我们自动释放了
C 语言中有 malloc ,C++ 有 new ,这些属于动态申请内存(在堆上申请一块内存空间)
上述内存空间需要手动方式进行释放:free,delete
如果不手动释放,这块内存的空间就会一直存在,一直存在到进程结束(堆上的内存生命周期比较长,不像 栈,栈的空间会随着方法的执行结束,栈帧自动销毁而自动释放,堆则默认不能自动释放)
这可能会导致一个很严重的问题:内存泄露
如果内存一直占着,又不释放,就会导致剩余空间越来越少,进一步导致后续的内存申请操作申请失败
因为内存泄露是一个很严重的问题,因此大佬们就想了一些办法来解决这个问题,垃圾回收(GC)是其中最主流的一种方式
GC 的好处:非常省心,让程序员写代码简单点,不容易出错
GC 的坏处:需要消耗额外的系统资源,也有额外的性能开销
另外,GC 这里还有一个比较关键的问题:STW 问题(stop the world)
1、如果有时候,内存中的垃圾已经很多了,此时触发一次 GC 操作,开销可能非常大,大到可能就把系统资源吃了很多
2、另一方面,GC 回收垃圾的时候,可能会涉及一些 锁 操作,导致业务代码无法正常执行
JVM 里面有很多块内存区域,GC 主要是针对其中的 堆 进行释放
GC 是以 “对象” 为基本单位进行回收的!!!(而不是字节)
GC 回收的是整个对象都不在使用的情况,而一部分使用,一部分不使用的对象,暂时先不回收
要回收,就是回收整个对象,而不会回收半个对象,因此我们说 GC 是以对象为基本单位进行回收的
这样设定,目的就是 “简单”
判定哪个对象以后一定不用了,哪个对象后面还可能使用
关键思路:抓住这个对象,看看到底有没有 “引用” 指向它
在 java 中,只有一条路:通过引用来使用!!!
如果一个对象,有引用指向它,就可能被使用到,如果一个对象没有引用指向,就一定不会再被使用了
具体如何知道对象是否有引用指向?
两种典型实现:
(1)引用计数 [不是 java 的做法]
给每个对象,都分配了一个计数器(整数)
每次创建引用指向该对象,计数器就 +1,每次该引用被销毁了,计数器就 -1
缺点:
1、内存空间浪费的多(利用率低)
每个对象都得分配一个计数器,如果对象特别多,占用的额外空间就会很多(尤其是对象特别小的情况)
2、循环引用的问题
接下来,如果 a 和 b 引用销毁,此时 1 号对象和 2 号对象引用计数都 -1,但是结果都还是 1,不是 0
虽然不是 0,不能释放内存,但是实际上这两个对象已经没有办法被访问到了
(2)可达性分析 [ java 的做法]
java 中的对象,都是通过引用来指向并访问的
经常,是一个引用指向一个对象,这个对象里的成员,又指向别的对象
整个 java 中所有的对象,就通过类似于上述的关系,通过这种 链式 / 树形 结构,整体给串起来
可达性分析,就是把所有这些对象被组织的结构,视为是 树,从树根节点出发,遍历树,所有能被访问到的对象,标记为 “可达”,不能被访问到的,就是不可达
每次你 new 一个对象,jvm 都会记录下来,jvm 会知道一共哪些对象,每个对象的地址...
相当于 jvm 自己捏着一个所有对象的名单,通过上述遍历,把可达的标记出来,剩下的不可达的就可以作为垃圾进行回收了
可达性分析,需要进行类似于 “树遍历” 这个操作,相比于引用计数来说,肯定要更慢一些,但是空间利用率提高了,同时解决了循环引用的问题
但是速度慢没关系,上述可达性分析遍历操作,并不需要一直执行,只需要每隔一段时间,分析一遍就可以了(虽迟,但到)
进行可达性分析遍历的起点,称为:GCroots,主要有以下几种:
1、栈上的局部变量
2、常量池中的对象
3、静态成员变量
一个代码中有很多这样的起点,把每个这样的起点都往下遍历一遍即可,就完成了一次扫描过程
如何清理垃圾?,主要是三种基本方法
1、标记清除
简单粗暴,但是存在内存碎片问题
被释放的内存空间是零散的,不是连续的,而申请空间要求的是连续空间
这就可能会导致总的空闲空间很大,但是每一个具体空间都很小,此时申请大一点的空间就会失败了
2、复制算法
复制算法,就是把不是垃圾的对象,复制到另外一半,然后把整个空间删除掉
每次触发算法,都是向另一侧复制,内存中的数据拷贝过去
缺点:空间利用率低,如果垃圾少,有效对象多,复制成本就比较大了
3、标记整理
类似于顺序表删除中间元素,会有元素搬运的操作,保证了空间利用率,同时也解决了内存碎片的问题
缺点:效率不高,如果要搬运的空间比较大,开销也很大
上述做法,并不完美,基于上述这些基本策略,我们又有了一个复合策略:“分代回收”
把垃圾回收,分成不同的常见,有的常见使用这个算法,有的场景使用那个算法,各展所长
分代是怎么分的?
基于一个经验规律:如果一个东西存在的时间比较长了,大概率会继续长时间持续存在下去
java 对象,要么就是生命周期特别短,要么就是特别长,我们就根据生命周期的长短,分别使用不同的算法
我们给对象引入一个概念:年龄(熬过 GC 的轮次)
我们可以认为:年龄越大,对象存在的时间就越久
伊甸区:刚 new 出来的,年龄是 0 的对象
熬过一轮 GC,对象就要被放到幸存区了
虽然看起来幸存区很小,伊甸区很大,但是一般够放(根据经验规律,大部分的 java 对象都是 “朝生夕死”,生命周期特别短)
伊甸区 => 幸存区 使用的是 “复制算法”
到了幸存区域之后,也要周期性的接受 GC 的考验,如果变成垃圾,就要被释放,如果不是垃圾,就拷贝到另一个幸存区(这两个幸存区同一时刻只存在一个,两个之间使用复制算法来回拷贝)
由于幸存区体积不大,此处的空间浪费,也能接受
如果这个对象,已经在两个幸存区中,来回拷贝很多次,就要进入老年代
老年代,都是年纪大的对象,生命周期普遍更长
针对老年代,也要周期性GC 扫描,但是频率更低了,如果老年代的对象是垃圾了,使用标记整理的方式进行释放
上述是 GC 中典型的垃圾回收算法
实际上,JVM 在实现的时候,会有一些差异,事实上,JVM 有很多的 “垃圾回收实现”,称为 垃圾回收器
回收期具体的实现做法,会按照上述算法思想展开,但是会有一些 变化 / 改进,不同的垃圾回收器,侧重点不同,这里就不再介绍了