06-底层必备源码-JVM底层-JVM的发展历史、class类加载机制

JVM知识点思维导图：

https://www.processon.com/view/link/5ff6bff11e08531de8231a57#map

JVM 学习路线

尚硅谷_JVM系列：

1.内存与垃圾回收篇

2.字节码与类的加载篇

3.性能监控与调优篇

4.大厂面试篇

---

1、尚硅谷_JVM系列_01_JVM与java体系结构

虚拟机与java虚拟机介绍

jvm的位置

jvm的整体结构

jvm编译器的前端：

java代码执行流程

1.大概流程：

2.编译细节：

1.大概流程：

2.编译细节：

第一次编译：java源文件被Java编译器编译为 字节码文件（.calss）

第二次编译：字节码文件被jvm编译成 机器指令，而且还会将常用的指令缓存起来

8-JVM的架构模型

1.java编译器输入的指令流基本上是：一种基于栈的指令集架构

2.另外一种指令集架构则是：基于寄存器的指令集架构

1.将java源文件编译成字节码文件（1.run，2.build->rebuild StackStruTest.java）
2.javap - v + 字节码文件名：反编译字节码文件，编译成编译指令
3.翻阅编译指令：翻译出对应的指令的作用

JVM架构模型总结：

---

一.Java的发展历史,JVM的更迭

1.java之父:詹姆斯.高斯林

1991年4月,由James Gosling主导的团队创造了Oak语言,java的前身,1995年5月23号,Oak语言更名Java,并且提出那句注明的:”write Once,Run Anywhere”的口号.1996年1月23日,JDK1.0发布.

当时正好赶上浏览器快速崛起,发展的浪潮,大家发现java一处编译到处使用的特性和浏览器很契合,同一个页面不可能每一个操作系统我都写一遍.用现在的话说java正好站在这个风口上.导致它飞速发展才有了今天的江湖地位.

到今天java从JDk1.0发布到现在的java已经有近21年的历史,也从JDK1.0发展到现在的JDK1.8,今年九月份Oracle也说会发布JDK1.9,JAVA也从最一开始的SUN公司手中,被IBM以74亿刀的价格收购,好多人看衰Java但是直到上个月来说java还是development使用最多的开发语言,但是比例已经有下滑,可能与Go语言的崛起和前两个月google开的安卓开发大会,安卓以后不会使用java开发有一定的关系,但是对于目前有着几百万java的开发者,数不胜数的第三方类库,短时间内它还是程序员们使用频率最高的开发语言.(题外话,java在Sun公司手里面一直找不到盈利的手段,倒是卖给IBM后他们找到了盈利的手段就是不停的和google打官司,安卓是用java开发的,一直说安卓侵权,java本身也是开源的但是它的开源协议不同与Linux的开源协议,我知道Linux所使用的开源协议就是一个完全开源,我linux系统开源,你们使用我的linux开发的东西也要开源,还有一种开源协议是我开源,你基于我开发的东西,可以开源也可以商用收费,IBM大概是搞google的安卓开发团队使用了的JDK中的一些核心API什么的,有兴趣可以自行查看相关资料,像他们这样的公司打官司一打就是好久,双方各有输赢,可能google也烦了,老子不和你玩了,所以抛弃了java奔向了别人的床).

---

10.-JVM发展历程

1.SUN Classic VM

2.Exact VM

商用比较流行的3大虚拟机：

1.HotSpot VM
2.JRockit
3.J9 JVM

6. KVM和CDC/CLDC HotSpot

7.Azul

8.Liquid

9. Apache Harmony

10.Microsoft JVM

11.Taobao JVM（国产研发）

12.Dalvik JVM

13.Graal VM

执行引擎（主要三部分组成）：

1.解释器

2.即时编译器

3.垃圾回收器

主流的都会具有解释器和即时编译器

注意：Sun Classic VM 只有解释器

执行引擎剖析：

1.各种语言-》编译成字节码文件（.class结尾的文件）

2.字节码文件放入jvm中，然后执行引擎中的解释器或JIT解释字节码

注：

（1）解释器、JIT（即时编译器）都可以解释字节码，使用其中一个就可以

（2）以前的jvm中就只存在解释器，现在的jvm同时存在解释器和JIT编译器

3.只提供解释器的缺点

（1）效率比较低，程序需要逐行去解析，比如for循环1000次，里面的东西也需要反复执行解析，效率比较低

4.如何提高解释器的效率？

（1）JIT解释器的出现

（2）JIT解释器在程序中，发现执行频率比较高的代码，会将其视为热点代码

将其及时编译成为->本地机器指令->将本地机器指令缓存起来(放在方法区的CodeCache)

当下次热点代码再次出现，不需要像解释器一样去逐行解析，去缓存里面找

5.早起的jvm（Sun Classic VM）中的解释器和JIT只能使用一个

只用JIT的缺点：

（1）暂停时间长，程序一启动，程序暂停时间就比较长

（2）最初：使用JIT的使用，初期Java程序启动时间比C和C++长，但是Java体系的壮大，更多的顶尖Java工程师参与Java的jit的优化，现在的Java启动时间，和C,C++差别不大

6.解释器和JIT的形象比较（为什么不将二者结合使用？）：

A和B都要从天津到北京天安门

（1）解释器（步行一直走，不停）：A收到从天津到北京天安门的通知之后，马上步行出发，一直走，启动时间比较快

（2）JIT（等公交车，等待时间可能比较长，上车之后又很快）：B收到从天津到北京天安门的通知之后,去公交车站台，等公交车，中途可能有很多站，每个站可能都需要等待一部分时间

可能在等待的时候，就没有步行的时候快，当时一上车之后，速度就比步行快很多了

7.如何优化解释器和JIT？为什么不将二者结合？

启动、出发的时候等公交慢（JIT），那就步行吖（解释器），走到下一个站台，步行时间小于2站台等待时间差，去坐公交车，到了下一个站，等待时间长，又不行，走到最近的一个站台，去等待坐下一班车。

HotSpot VM结合了前2个虚拟机的优点。

---

2.Exact VM

为了解决Sun Classic VM存在的问题，sun提供了此虚拟机

3.HotSpot VM（至今还在使用）

Exact vm 是雏形

HotSpot是具体实现，优化

4.BEA公司 的 JRockit（已经被Oracle公司收购了）

5.IBM 的 J9 (依然是IBM公司的)

6.Azul VM

和硬件耦合的VM

7.Liquid VM

Apache Harmony

TaobaoJVM(阿里的JVM)

jdk：

1.java文件被编译器编译为 字节码文件（.calss）

2.javac 命令 运行

二、JVM系列_类加载子系统

类加载机制

阿里P7面试官：请你简单说一下类加载机制的实现原理？

https://baijiahao.baidu.com/s?id=1715121084923879041&wfr=spider&for=pc

        简述：虚拟机把描述类的数据从class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。

 

java的类加载器：

1. 继承java.lang.ClassLoader 的 自定义的类加载器
2. 扫描classpath目录的 App ClassLoade应用类加载器
3. 扩展的Extension ClassLoader的扩展类类加载器
4. Bootstrap ClassLoader 引导类、根加载器

类加载底层详细流程：

 引导类加载器 也称为根加载器

双亲委派机制：

 从JDK源码剖析核心类加载器

 自己手写一个 java.lang.String类，定义一个main()方法，

执行main()方法，但是报错。

原因：

        因为应用类加载器 向上委托 了扩展类加载器 ，

        然后扩展类加载器 又向上委托了引导类加载器，

        然后引导类加载器在rt.jar 下找到了java.lang.String

        然后发现没有main（）方法，故而报错。

        加载的是jvm自带的rt.jar下面java.lang.String而不是自己定义的 ，所以存在这样的问题

应用类加载器 的parent引用 指向扩展类加载器

扩展类加载器 的parent引用 指向指导类（根）加载器

学习地址：https://blog.csdn.net/onewolf95/article/details/124652526

 java类加载为啥不直接从bootstrap>extension>application顺序来加载?

 

学习地址：https://www.zhihu.com/question/306903522/answer/2478331980

Tomcat还有别的类加载器吗？

 JDBC你不是知道吗，听说它也是破坏了双亲委派模型的，你怎么理解的？

---