JVM类加载机制

回到2018年的抖音哈哈.

回顾下：

1. java开发环境:

   java编译运行过程:

   • 1) 编译期：.java源文件，经过编译，生成.class字节码文件

     2) 运行期：JVM加载.class并运行.class(0和1)

     特点: 跨平台、一次编程,处处报错

   • 名词解释:

     1) JVM: java虚拟机

     加载.class并运行.class

     2) JRE: java运行环境

     除了包含JVM以外，还包含了运行java程序所必须的环境

     JRE = JVM+java系统类库(小零件)

     3) JDK: java开发工具包

     除了包含JRE以外，还包含了开发java程序所必须的命令工具

     JDK=JRE+编译、运行等命令工具

     结论:

     1) 运行java程序的最小环境为JRE

     2) 开发java程序的最小环境为JDK

Java中类加载器:

1.引导类加载器(启动类加载器):负责加载支撑JVM运行的位于JAR的lib类库.(该对象实际上是C++生成的对象)

BootstrapClassLoader

由引导类加载器负责加载创建其他类的加载器

2.扩展类加载器:负责加载支撑JVM运行的JRE的lib目录下的ext扩展目录下的jar包ExtensionClassLoader

3.应用程序类加载器:负责加载ClassPath路径下的类.主要就是自己写的类

ApplicationClassLoader

4.自定义加载器:负责加载用户自定义路径下的类

流程:

1.windows系统下,java.exe调用底层的jvm.dll文件创建java虚拟机(C++实现)

2.java虚拟机创建一个引导类加载器(C++实现）

3.引导类加载器加载sun.mis.Launcher创建其他类加载器

4.(其实加载的时候就初始化好了)通过Launcher.getLauncher()创建ExtClassLoader(扩展类加载器)和AppClassLoader(应用类加载器)

JVM启动器实例sun.mis.Launcher初始化使用单例模式,保证JVM虚拟机只有一个sun.mis.Launcher实例,在Launcher构造方法内部,创建了两个类加载器

分别是:

1.sun.misc.Launcher.ExtClassLoader(扩展类加载器)

2.sun.misc.Launcher.AppClassLoader(应用类加载器)

JVM默认使用Launcher.getClassLoader()方法返回AppClassLoader实例加载我们的应用程序

而 this.loader如下  是将ExtClassLoader做为参数给了AppClassLoader,因此也可以说ExtClassLoader是AppClassLoader生父

 大概就是这么个意思

关于双亲委派机制

 

 双亲委派机制说简单点就是，先找父亲加载，不行再由儿子自己加载

双亲委派机制的目的:

1.沙箱安全机制：防止核心 API库被随意篡改

2.避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一

次，保证被加载类的唯一性

全盘负责委托机制

全盘负责：是指当一个ClassLoder装载一个类时，除非显示的使用另外一个ClassLoder，该类

所依赖及引用的类也由这个ClassLoder载入。

关于自定类加载器:百度.自定义加载器的父加载器是AppClassLoader.是父加载器....不是父类

自定义类加载器只需要继承java.lang.ClassLoader类.

ClassLoader类有两个核心方法,一个是loadClass(String str,boolean b)

上面这个方法,实现了双亲委派机制

还有一个方法是findClass 

默认是空实现

自定义类加载器主要是重写findClass方法

如果想打破双亲委派机制,那么自定义加载器重写ClassLoader里loadClass(String str,boolean b)方法,百度一堆

Tomcat打破双亲委派机制的原因在于它可能部署不同的应用,那么不同应用可能依赖于同一个第三方,但是不同版本的依赖,这样的话,不能要求这些第三方依赖只有一份,因要要保证这些依赖的独立存在,就需要打破双亲委派机制.另外就是相同依赖的类库只需要一份,不然负担太重

其实有点相互矛盾,指定需要打破双亲委派的路径即可