龙空技术网

图文故事:一文带你走进JVM的世界

Java技术架构 342

前言:

此时姐妹们对“jvm相关知识”可能比较珍视,朋友们都需要知道一些“jvm相关知识”的相关知识。那么小编同时在网络上网罗了一些关于“jvm相关知识””的相关资讯,希望我们能喜欢,同学们一起来了解一下吧!

作者:flyhero 来自:码上实战

最近的业余时间基本都在写一个简单的RPC框架(附带详解以及知识点讲解那种,争取新手都能看懂),所以原创文耽搁了一些,不过也可以让你们缓冲一下,前今天发了一些不错的原创技术文章。加油!奥利给!❞

小强是一个工作3年有余的开发工程师,从他的发量你就可以知道,小强资历还尚浅。

程序员惊人发量

最近公司没什么事,他也开始无聊起来了。这天下午,同事们在激烈的讨论这业务,但他没有参与,于是他决定学习些什么知识,无聊的翻着各个网页,发现JVM是各位大神们推荐过的知识,于是决定好好看一看。

5分钟过后……

小强感到这知识有些枯燥乏味,怪不得是大神们能看的!又看了几分钟,小强倦意袭来,揉了揉睡眼惺忪的眼睛。

然而就在这一刻,他突然发现周围同事激烈讨论的声音听不到了,安静到了极致。

1. 入界

小强努力的睁开眼睛,才发现自己竟然身处一个白茫茫的空间中,吓得一跳,心想我这是怎么了,穿越了?但穿越也得穿越到一个人间如画,美女如云的地方啊……,这境地……

JVM幻境

突然前方走来一个白胡子老头,小强正想开口,老头捷足先登:你好,我是这个JVM世界的缔造者,你可以叫我 “HotSpot”,不过这无所谓,因为我所创造的这个世界,是按照 “JVM规范” 来完成的。我正在休息时,发现来了一位客人,原来是你。

小强:我是想问……

老头:不用问,我知道,你是想了解一下我创造的这个世界吧!跟我来吧。

这老头,我还没说话,这就结束了!好吧,跟你看看且说。

老头边走边道:JVM 的世界 空间是有限的,我们坚持一个原则 : 各司其职,不留无用之人!

小强:啊!好残酷。

老头:不,这不是残酷,我们这个世界生来就是为客户提供服务,为客户发光发热的,每个人奉献出了自己的能力就是圆满完成任务,退出舞台是理所应当的,也是他们最好的归宿。

小强:也是,这样这个世界才不会那么拥挤,大家才能井然有序的工作,我怎么这么不开窍呢……

2. 布局

老头前面停了下来:过来,带你先看看我们世界的整体组成和中心区如何布局。

整体布局图

先来看看我们最主要的日常工作区(运行时数据区),为了让我们工作起来更有效率,我们将世界空间划分为这几个板块。

「居住区-堆」

这里是人们工作外的居住区,居住区我们基于人们的年龄也进一步分出了,伊甸区,幸存者区,老年区。

居住区

「工作区-栈」

每个任务来临时,都会在工作区单独开辟出一个地方来用于完成这个任务。

栈帧图

「记录者-程序计数器」

由于我们同时能做的任务有限,所以我们需要为不同的任务划分出不同的时间片,我们在切换任务的时候,需要一个记录者,能够记录我们这个任务做到了哪里,下次回来能够继续做。

「仓库管理区-方法区」

这里存放着工人的模板以及常用的不变的工具等。

3. 生与死

这里工作的人们都会经历生与死,大部分人们活不到老年,但这不重要,重要的是他为我们做出了贡献。

3.1 出生

老头:这里的每个人都有一个模板(类),看到那个正在居住区休息的高个吗?他叫张三,他是根据外部客户给定的模板 “ User Class” 创造的,他可是客户最喜爱的工人了。你知道客户的这些模板(类)是如何进入的到我们的世界中的吗?

小强:这个我知道点,之前看过一点点。这个过程还是有些复杂的,客户的模板(类)是通过一个翻译工厂(编译器) 将它翻译成class 字节码,因为你们这个世界只认识字节码,然后有你们的加载系统将它们加载到这里。

加载过程中有这些阶段:

类加载过程

其中加载阶段是由加载器来完成的。

老头:是的,我们提供了三种加载器,启动类加载器,扩展类加载器,应用类加载器,当然客户也可以自定义加载器。

双亲委派模型

小强:他们遵循着双亲委派模型,但是我一直不太理解这个词!

老头:这是由于你们语言翻译的问题导致,这个模式叫 “parents delegation”,知道了吧!它是指有你的父辈们来帮你完成。

小强:那双亲委派模式 有什么好处呢?

老头:

具有优先级层次的关系可以避免模板(类)的重复加载安全考虑可以防止Java核心api被替换

老头继续道:那连接过程中的三步,你知道是做什么吗?

小强:具体的我就不知道了哎……

老头笑了笑:对于客户定义的模板(类),我们可不是来者不拒的,为了我们这个世界的安全以及能提供更好的服务,我们会对模板做一些验证及后续操作。

验证包括格式验证,元数据验证,字节码验证,符号验证。当验证通过后,我们会为模板所依赖的东西(类变量)分配空间,最后将符号引用替换为直接引用。

老头看了看小强眉头紧皱,于是继续补充:你可能不了解什么是符号引用和直接引用!

符号引用就是在编译时,并不知道模板(类)所依赖的其他东西,会在我们的空间中的哪个位置,只能用符号来表示。

直接引用就是 所有东西被加载到这里后会有自己的真实空间地址,然后去替换符号引用。这样运行时就能找到它们所依赖的东西了。

最后就是初始化了,这个阶段主要是对类变量初始化,是执行类构造器的过程。

小强:我怎么没看到这些模板呢?

老头:这些模板我把他们隐藏在世界的后方,大多数人是见不到的,他们统称为 Klass。

小强:不对啊!你是不是搞错了?不应该叫 Class吗?

老头:哈哈!我刚才说了,大多数人见不到,你就是其中之一啊!你们平时见到的 Class只是对 Klass的一种封装而已,真正记录模板中的具体元信息的就是 Klass。这回要记住了,年轻人。

3.2 工人

小强:为什么你的工人是等量差的身高呢?

对象长度

老头:你的观察还是挺仔细的嘛!是的,他们确实是等量差的,想要知道为什么,要先了解这些工人有哪些部分组成。

对象的组成

它们头部大小是固定的,身体大小是由自己的属性数据决定的,而最后的脚部却是我来决定的,如果前面两个数据的大小没有达到 8 的倍数,那么我就会来填充,所以就是这里的填充使得他们拥有了等量的身高差(内存对齐)。

我是基于两点原因来这个缔造他们的:

平台原因:不是所有的硬件平台都能访问任意地址上的任意数据的;某些硬件平台只能在某些地址处取某些特定类型的数据,否则抛出硬件异常。性能原因:中央大脑(CPU)访问内存是有内存访问粒度的,就是每次访问内存的长度是固定的,如果不这样做,那么中央大脑起需要访问两次内存,而对齐后只需要一次。

小强:嗯,明白了!那能给我说说这些工人在居住区为什么要不断的搬迁呢?

3.3 成长

老头:经过长时间的观察,我发现每个工人的生命长短是不一样的。所以我把居住区分为新生代,老年代,然后让他们合理的搬迁,这样能有效的利用空间而且让垃圾小分队工作更有效率。

堆区分代

工人诞生后会分配到Eden区,当Eden区人员快满时,垃圾小分队会来清扫,清扫后如果工人还活着,那么他们将搬迁至Survivor区中的其中一个,当这个Survivor快满时,垃圾小分队会将还活着的工人搬迁至另一个Survivor区中,就这样重复着,每经历一次垃圾小分队的清扫,活着的工人就会长大一岁,直到工人的年龄达到15岁,到达后会将他们搬迁至老年代生活的地方。但也有例外,如果某个工人吃的太胖,新生代容不下他,那么他将直接去老年代住下。当老年代快住满时,将会有垃圾大扫除(full gc)。

小强:原来如此啊!从此我再也不是只知道堆区栈区的菜鸟啦!哈哈哈哈……

老头:小伙子,不要高兴太早!你到目前为止所了解的仍是九牛一毛。

3.4 死亡证明

小强:如何确定工人是否到达生命的尽头呢?

第一种:引用计数法

给每个工人添加一个引用计数器,就是只要有人需要这个工人帮忙,那么就给这个工人的计数加1,反之,别人不再需要这个工人的帮忙,那么计数就减1,直到这个计数为0,那么表示这个工人生命到了尽头。

但这种方法有个问题:如果A工人和B工人相互需要帮忙,但没有任何其他工人或任务需要他们两个,那么他们两个会永远活下!「所以这种方法我们不会采取的。」

第二种:可达性分析法

我们找出被称为 “GC roots”的工人作为起点,依次寻找他们工作中依赖的工人,这就可以知道哪些工人是没有必要在存在下去了。

小强:我怎么知道哪些是 “GC roots”工人呢?

老头:

工作区(栈)中的需要用到的工人仓库(方法区)中模板(类)本身需要的工人(静态,常量)世界后方(native方法)需要的工人

小强:Got it!

4. 回收

老头:下面我带你去认识一下垃圾小分队的人物吧!不过在认识他们之前你最好了解一下,垃圾清除的基本方法论。

4.1 基本方法论

收集垃圾遵循的基本方法论有以下几种:

标记-清除首先标记出所有需要回收的工人(对象),在标记完成后统一回收所有被标记的工人。但这个有两个缺点:1. 效率不高 2. 会产生许多碎片空间复制将可用的空间一分为二,每次只使用其中一块,当快使用完时,小分队回收,然后将活着的工人搬迁至另一块。这虽然解决了标记-清除的效率问题,但此种方法却缩小了一半空间。标记-整理首先标记出所有需要回收的工人(对象),然后将存活的工人移动到空间的一端,然后清理掉边界以外的工人。

小强笑了笑:原来是这三种算法啊!我知道!

老头:既然知道,那跟我来认识一下垃圾清扫队的人吧!

4.2 主要成员

垃圾清扫队有好几个小队组成,客户喜欢哪个小队可以指定让谁来工作,他们各个队伍的清扫方式各不相同也各有优劣。

我给你介绍一下两个主要成员吧,CMS,G1两个小队出列。

CMS:到,我们是CMS分队,全称叫 “Concurrent Mark Sweep”,顾名思义,我们是采用标记清除算法的并发小分队,我们以获取最短回收停顿时间为目标。

小强:那你说说你们是如何工作的?

CMS:我们主要分四个步骤工作,1. 初始标记 2.并发标记 3.重新标记 4.并发清除

小强:算啦,这么多步骤太需要时间来了解了,我现在知道你的优点了,那你的缺点有什么呢?

CMS:这怎么还带揭人伤疤的……

老头这时严肃的咳嗽了两声,其意CMS立马捕获到了,委屈的说:

我有三个缺点:

当资源不是很充足时,占用过多的资源,导致任务变慢无法处理浮动垃圾,我们清理的时候,工人同时也在工作,我们标记后,正好有些工人不在需要了我们分队遵循的是“标记-清除”算法,所以会产生大量碎片空间,导致世界大扫除(full gc)提前到来

心直口快的小强来了句:原来你的问题这么严重,老头竟然没把你们小分队辞掉……

CMS:你…… 想当年我们分队可是红极一时的……

那么我猜G1是不是可以弥补CMS的不足呢?

G1: 说实话,我们分队的目标就是替换CMS分队…… (JDK14 CMS正式落下帷幕)

小强不怀好意的笑了起来,哈哈……,CMS翻着白眼躲到一旁的角落暗自伤感去了。

CMS角落哭泣

小强:那G1说说你的能耐吧!

G1: 我们队是基于标记整理算法的,因此不会产生大量碎片空间

我们同时引入了分区的思路,弱化了分代的概念我们的停顿时间是可控的,可避免雪崩现象我们也能充分利用客户给我们的资源,减少停顿时间

这是我们队的优势,接下来我给你详细介绍下我们队的情况……

小强:好的!你继续……

回归

就在小强听的兴趣浓浓时,天空中突然出现一只巨大无比的手向他袭来,小强躲闪不开,啊……

一只大巴掌

小强捂着自己的头,有点恍惚,抬头一看,擦,技术总监……你怎么也在这?

总监:我不在这我在哪?在家睡大觉吗!

这时小强才回过神来,原来自己还在办公室,大事不妙啊!

总监:小强,回家多爽,明天就不用来了吧!

小强一慌,脑袋灵机一动:总监,知道我刚才在做什么吗?那可不是在睡觉,我有一个故事你且听听再做决定。

吧啦吧啦……

如果你觉得本文有不巧当之处,请留言告知,如果喜欢本文给个赞鼓励一下。

标签: #jvm相关知识