关注选择“ 「星标」 ”, 重磅干货,第一 时间送达! [如果你觉得文章对你有帮助,欢迎「关注,在看,点赞,转发」]
「《面试八股文》之 JVM 20卷」 它来了,整理大部分经常会问到的考点,整整 20 问,当然, 给出的答案也是相当丰富的,虽然只有 20 问,但是本文足足有 1W 多字,这也是想告诉大家的,就在面试的时候也需要「学会拓展」,不要面试官问什么你就只回答什么,象征性的扩展开来,要让面试官能知道,你并不是个只会背八股文的人,「知其然要知其所以然」~
JVM 内存区域
这张图就是一个 JVM 运行时数据图,「紫色区域代表是线程共享的区域」,JAVA 程序在运行的过程中会把他管理的内存划分为若干个不同的数据区域,「每一块儿的数据区域所负责的功能都是不同的,他们也有不同的创建时间和销毁时间」。
就是给对象添加一个计数器
「「当计数器的值为0的时候,那么该对象就是垃圾了」」这种方案的原理很简单,而且判定的效率也非常高,但是却可能会有其他的额外情况需要考虑。
相互引用
比如两个「「对象循环引用」」,a 对象引用了 b 对象,b 对象也引用了 a 对象,a、b 对象却没有再被其他对象所引用了,其实正常来说这两个对象已经是垃圾了,因为没有其他对象在使用了,但是计数器内的数值却不是 0,所以引用计数算法就无法回收它们。这种算法是比较「「直接的找到垃圾」」,然后去回收,也被称为"直接垃圾收集"。
这也是「「JVM 默认使用」」的寻找垃圾算法它的原理就是定义了一系列的根,我们把它称为 「「"GC Roots"」」 ,从 「「"GC Roots"」」 开始往下进行搜索,走过的路径我们把它称为 「「"引用链"」」 ,当一个对象到 「「"GC Roots"」」 之间没有任何引用链相连时,那么这个对象就可以被当做垃圾回收了。
root search
如图,「「根可达算法」」就可以「「避免」」计数器算法不好解决的「「循环引用问题」」,Object 6、Object 7、Object 8彼此之前有引用关系,但是「没有与「"GC Roots"」 相连,那么就会被当做垃圾所回收」。
在java中,有「「固定的GC Roots 对象」」和「「不固定的临时GC Roots对象」:」
「「固定的GC Roots:」」
「「临时GC Roots:」」
"Object o = new Object()" 就是一种强引用关系,这也是我们在代码中最常用的一种引用关系。无论任何情况下,只要强引用关系还存在,垃圾回收器就不会回收掉被引用的对象。
当内存空间不足时,就会回收软引用对象。
// 软引用
SoftReference<String> softRef = new SoftReference<String>(str);
软引用用来描述那些有用但是没必要的对象。
弱引用要比软引用更弱一点,它「「只能够存活到下次垃圾回收之前」」。也就是说,垃圾回收器开始工作,会回收掉所有只被弱引用关联的对象。
WeakReference<String> weakRef = new WeakReference<String>(str);
在 「ThreadLocal」 中就使用了弱引用来防止内存泄漏。
虚引用是最弱的一种引用关系,它的唯一作用是用来作为一种通知。如零拷贝(Zero Copy),开辟了堆外内存,虚引用在这里使用,会将这部分信息存储到一个队列中,以便于后续对堆外内存的回收管理。
大多数的垃圾回收器都遵循了分代收集的理论进行设计,它建立在两个分代假说之上:
这两种假说的设计原则都是相同的:垃圾收集器「「应该将jvm划分出不同的区域」」,把那些较难回收的对象放在一起(一般指老年代),这个区域的垃圾回收频率就可以降低,减少垃圾回收的开销。剩下的区域(一般指新生代)可以用较高的频率去回收,并且只需要去关心那些存活的对象,也不用标记出需要回收的垃圾,这样就能够以较低的代价去完成垃圾回收。
由于跨代引用是很少的,所以我们不应该为了少量的跨代引用去扫描整个老年代的数据,只需要在新生代对象建立一个「「记忆集」」来记录引用信息。记忆集:「「将老年代分为若干个小块,每块区域中有 N 个对象」」,在对象引用信息发生变动的时候来维护记忆集数据的准确性,这样每次发生了 「「"Minor GC"」」 的时候只需要将记忆集中的对象添加到 「「"GC Roots"」」 中就可以了。
总共有三种
这种算法的实现是很简单的,有两种方式
标记清除算法
这种算法有两个「缺点」
这种算法解决了第一种算法碎片化的问题。就是「「开辟两块完全相同的区域」」,对象只在其中一篇区域内分配,然后「「标记」」出那些「「存活的对象,按顺序整体移到另外一个空间」」,如下图,可以看到回收后的对象是排列有序的,这种操作只需要移动指针就可以完成,效率很高,「「之后就回收移除前的空间」」。
标记复制算法
这种算法的缺点也是很明显的
这种算法可以说是结合了前两种算法,既有标记删除,又有整理功能。
标记整理算法
这种算法就是通过标记清除算法找到存活的对象,然后将所有「「存活的对象,向空间的一端移动」」,然后回收掉其他的内存。
Java 中「「Stop-The-World机制简称 STW」」 ,是在执行垃圾收集算法时,Java 应用程序的其他所有线程都被挂起(除了垃圾收集帮助器之外)。「Java 中一种全局暂停现象,全局停顿」,所有 Java 代码停止,native 代码可以执行,但不能与 JVM 交互。
在 java 应用程序中「「引用关系」」是不断发生「「变化」」的,那么就会有会有很多种情况来导致「「垃圾标识」」出错。想想一下如果 Object a 目前是个垃圾,GC 把它标记为垃圾,但是在清除前又有其他对象指向了 Object a,那么此刻 Object a 又不是垃圾了,那么如果没有 STW 就要去无限维护这种关系来去采集正确的信息。再举个例子,到了秋天,道路上洒满了金色的落叶,环卫工人在打扫街道,却永远也无法打扫干净,因为总会有不断的落叶。
我们在前面说明了根可达算法是通过 GC Roots 来找到存活的对象的,也定义了 GC Roots,那么垃圾回收器是怎样寻找GC Roots 的呢?首先,「「为了保证结果的准确性,GC Roots枚举时是要在STW的情况下进行的」」,但是由于 JAVA 应用越来越大,所以也不能逐个检查每个对象是否为 GC Root,那将消耗大量的时间。一个很自然的想法是,能不能用空间换时间,在某个时候把栈上代表引用的位置全部记录下来,这样到真正 GC 的时候就可以直接读取,而不用再一点一点的扫描了。事实上,大部分主流的虚拟机也正是这么做的,比如 HotSpot ,它使用一种叫做 「「OopMap」」 的数据结构来记录这类信息。
我们知道,一个线程意味着一个栈,一个栈由多个栈帧组成,一个栈帧对应着一个方法,一个方法里面可能有多个安全点。gc 发生时,程序首先运行到最近的一个安全点停下来,然后更新自己的 OopMap ,记下栈上哪些位置代表着引用。枚举根节点时,递归遍历每个栈帧的 OopMap ,通过栈中记录的被引用对象的内存地址,即可找到这些对象( GC Roots )。使用 OopMap 可以「「避免全栈扫描」」,加快枚举根节点的速度。但这并不是它的全部用意。它的另外一个更根本的作用是,可以帮助 HotSpot 实现准确式 GC (即使用准确式内存管理,虚拟机可用知道内存中某个位置的数据具体是什么类型) 。
从线程角度看,安全点可以理解成是在「「代码执行过程中」」的一些「「特殊位置」」,当线程执行到这些位置的时候,说明「「虚拟机当前的状态是安全」」的。比如:「「方法调用、循环跳转、异常跳转等这些地方才会产生安全点」」。如果有需要,可以在这个位置暂停,比如发生GC时,需要暂停所有活动线程,但是线程在这个时刻,还没有执行到一个安全点,所以该线程应该继续执行,到达下一个安全点的时候暂停,等待 GC 结束。那么如何让线程在垃圾回收的时候都跑到最近的安全点呢?这里有「「两种方式」」:
刚刚说到了主动式中断,但是如果有些线程处于sleep状态怎么办呢?
为了解决这种问题,又引入了安全区域的概念安全区域是指「「在一段代码片中,引用关系不会发生改变」」,实际上就是一个安全点的拓展。当线程执行到安全区域时,首先标识自己已进入安全区域,那样,当在这段时间里 JVM 要发起 GC 时,就不用管标识自己为“安全区域”状态的线程了,该线程只能乖乖的等待根节点枚举完或者整个GC过程完成之后才能继续执行。
前面和大家聊了很多垃圾收集算法,所以在真正实践的时候会有多种选择,垃圾回收器就是真正的实践者,接下来就和大家聊聊10种垃圾回收器
Serial是一个「「单线程」」的垃圾回收器,「「采用复制算法负责新生代」」的垃圾回收工作,可以与 CMS 垃圾回收器一起搭配工作。
Serial
在 STW 的时候「「只会有一条线程」」去进行垃圾收集的工作,所以可想而知,它的效率会比较慢。但是他确是所有垃圾回收器里面消耗额外内存最小的,没错,就是因为简单。
ParNew 是一个「「多线程」」的垃圾回收器,**「采用复制算法负责新生代」**的垃圾回收工作,可以与CMS垃圾回收器一起搭配工作。
ParNew
它其实就是 Serial 的多线程版本,主要区别就是在 STW 的时候可以用多个线程去清理垃圾。
Pararllel Scavenge 是一个「「多线程」」的垃圾回收器,「「采用复制算法负责新生代」」的垃圾回收工作,可以与 Serial Old , Parallel Old 垃圾回收器一起搭配工作。
Pararllel Scavenge
是与 ParNew 类似,都是用于年轻代回收的使用复制算法的并行收集器,与 ParNew 不同的是,Parallel Scavenge 的「「目标是达到一个可控的吞吐量」」。吞吐量=程序运行时间/(程序运行时间+GC时间)。如程序运行了99s,GC耗时1s,吞吐量=99/(99+1)=99%。Parallel Scavenge 提供了两个参数用以精确控制吞吐量,分别是用以控制最大 GC 停顿时间的 -XX:MaxGCPauseMillis 及直接控制吞吐量的参数 -XX:GCTimeRatio.「「停顿时间越短就越适合需要与用户交互的程序」」,良好的响应速度能提升用户体验,而高吞吐量则可以高效的利用 CPU 时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务。
Serial Old 是一个「「单线程」」的垃圾回收器,「「采用标记整理算法负责老年代」」的垃圾回收工作,有可能还会配合 「「CMS」」 一起工作。
其实它就是 Serial 的老年代版本,整体链路和 Serial 大相径庭。
Parallel Old 是一个「「多线程」」的垃圾回收器,「「采用标记整理算法负责新生代」」的垃圾回收工作,可以与 Parallel Scavenge 垃圾回收器一起搭配工作。
Parallel Old 是 Pararllel Scavenge 的老年代版本,它的设计思路也是以吞吐量优先的,ps+po 是很常用的一种组合。
CMS可以说是一款具有"跨时代"意义的垃圾回收器,支持了和用户线程一起工作,做到了**「一起并发回收垃圾」**的"壮举"。
CMS
CMS的「「三个缺点」」:
G1(Garbage First):顾名思义,「「垃圾回收第一」」,官方对它的评价是在垃圾回收器技术上具有「「里程碑式」」的成果。G1 回收的目标不再是整个新生代,不再是整个老年代,也不再是整个堆了。G1 可以「「面向堆内存的任何空间来进行」」回收,衡量的标准也不再是根据年代来区分,而是哪块「「空间的垃圾最多就回收哪」」块儿空间,这也符合 G1 垃圾回收器的名字,垃圾第一,这就是 G1 的 「「Mixed GC」」 模式。当然我的意思是「「垃圾回收不根据年代来区分」」,但是 G1 还是「「根据年代来设计」」的,我们先来看下 G1 对于堆空间的划分:
G1
G1 垃圾回收器把堆划分成一个个「「大小相同的Region」」,每个 Region 都会扮演一个角色,H、S、E、O。E代表伊甸区,S代表 Survivor 区,H代表的是 Humongous(G1用来分配「「大对象的区域」」,对于 Humongous 也分配不下的超大对象,会分配在连续的 N 个 Humongous 中),剩余的深蓝色代表的是 Old 区,灰色的代表的是空闲的 region。在 HotSpot 的实现中,整个堆被划分成2048左右个 Region。每个 Region 的大小在1-32MB之间,具体多大取决于堆的大小。在并发标记垃圾时也会产生新的对象,G1 对于这部分对象的处理是这样的:将 Region 「「新增一块并发回收过程中分配对象的空间」」,并为此设计了两个 TAMS(Top at Mark Start)指针,这块区域专门用来在并发时分配新对象,有对象新增只需要将 TAMS 指针移动下就可以了,并且这些「「新对象默认是标记为存活」」,这样就「「不会干扰到标记过程」」。
但是这种方法也会有个问题,有可能「「垃圾回收的速度小于新对象分配的速度」」,这样会导致 "Full GC" 而产生长时间的 STW。在 G1 的设计理念里,「「最小回收单元是 Region」」,每次回收的空间大小都是Region的N倍,那么G1是「「怎么选择要回收哪块儿区域」」的呢?G1 会跟踪各个 Region 区域内的垃圾价值,和回收空间大小回收时间有关,然后「「维护一个优先级列表」」,来收集那些价值最高的Reigon区域。
这里我们又提到了一个概念叫做 「「SATB 原始快照」」,关于SATB会延伸出有一个概念,「「三色标记算法」」,也就是垃圾回收器标记垃圾的时候使用的算法,这里我们简单说下:将对象分为「「三种颜色」」:
我们知道在 「「并发标记」」 的时候 「「可能会」」 出现 「「误标」」 的情况,这里举两个例子:
第一种情况影响还不算很大,只是相当于垃圾没有清理干净,待下一次清理的时候再清理一下就好了。第二种情况就危险了,正在使 「「用的对象的突然被清理掉」」 了,后果会很严重。那么 「「产生上述第二种情况的原因」」 是什么呢?
当这两种情况 「「都满足」」 的时候就会出现这种问题了。所以为了解决这个问题,引入了 「「增量更新」」 (Incremental Update)和 「「原始快照」」 (SATB)的方案:
Java 栈内存溢出可能抛出两种异常,两种异常虽然都发生在栈内存,但是两者导致内存溢出的根本原因是不一样的:
「类加载机制」:
这是一张很经典的图,标明了一个类的生命周期,而很多人一眼看过去就以为明白了类的生命周期,但是这只是其中一种情况。
真实情况是「加载、验证、准备、初始化、卸载这五个阶段的顺序是确定的,是依次有序的」。但是「解析阶段有可能会在初始化之后才会进行」,这是「为了支持 Java 动态绑定」的特性。
「动态绑定」:
「双亲委派模型」:
用上图来说明就是如果应用程序类加载器收到了一个类加载的请求,会先给扩展类加载器,然后再给启动类加载器,如果启动类加载器无法完成这个类加载的请求,再返回给扩展类加载器,如果扩展类加载器也无法完成,就返回给应用类加载器。
「好处:」
如果所有对象都分配在堆中那么会给 GC 带来许多不必要的压力,比如有些对象的生命周期只是在当前线程中,为了减少临时对象在堆内分配的数量,就「可以在在栈上分配」,随着线程的消亡而消亡。当然栈上空间必须充足,否则也无法分配,在判断是否能分配到栈上的另一条件就是要经过逃逸分析,
「逃逸分析(Escape Analysis)」:
对象内存布局
觉得文章有趣好看,欢迎『点赞』、『在看』、『转发』三连支持一下,下次见~