JVM学习笔记-类加载器子系统

 学习的视频是尚硅谷的宋红康老师的jvm虚拟机

视频地址尚硅谷宋红康JVM全套教程（详解java虚拟机）_哔哩哔哩_bilibili

一、类的装载机制

1.内存结构概述

分为三部分，类加载子系统Class Loader，运行时数据区（Runtime Data Area）

，执行引擎Execution Engine,本地方法接口

图示如下

 

2.类的加载器以及加载过程

类加载器子系统分为三个阶段来处理字节码文件

加载阶段，链接阶段，初始化阶段

 

ClassLoader只负责Class文件的加载，是否可以运行 由执行引擎来决定，

加载的类信息存放于一块称为方法去的内存空间，除了类的信息外，方法区还会存放运行时的常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）

3.类的加载过程一：加载loading

1.通过一个类的全限定名获取定义此类的二进制字节流

2.将这个字节流所代表的的静态存储结构转化为方法区的运行时数据结构

3.在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

加载.class文件的方式

从本地系统中直接加载

通过网络获取，典型场景Web Applet

从zip压缩包中读取，成为日后jar。war格式的基础

运行时计算生成，使用最多的是：动态代理技术

由其他文件生成，典型场景：JSP应用

从专用数据库中提取Class文件，比较少见

从加密文件中获取，典型的放Class文件被反编译的保护措施

4.类的加载过程二：链接

链接阶段分为三部分

1验证（Verify）

目的在去报Class文件的字节流中包含信息符合当前虚拟机的要求，保证被加载类的正确性不会危害虚拟机自身安全。

主要包括四种验证

文件格式验证，元数据验证，字节码验证，符号引用验证

举例，所有class文件的字节码都是由CA FE BA BE开始的

准备（Prepare）

为类变量分配内存并且设置该类变量的默认初始值，即零值

这里不含含有用final修饰的static因为final在编译时就会分配了，准备阶段会显式初始化

这i不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到java堆中。

解析（Resolve）

将常量池内的符号引用转化为直接引用的过程。

事实上解析操作往往会伴随着jvm在执行完初始化之后再执行

符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机规范》的class文件格式中，直接引用就是直接指向目标的指针。相对偏移量或一个间接定位到目标的句柄

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等，

对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等

5.类的加载过程三：初始化

初始化阶段就是执行类构造器放法<clinit>()的过程。

此方法不需要定义，是javac编译器自动收集类中的所有类变量的复制动作和静态代码块中的语句合并而来的

构造器方法中按语句在源文件中出现的顺序执行。

<clinit>()不同于类的构造器。（构造器是虚拟机视角下的<init>()）

若该类具有父类，jvm会保证子类的方法执行前父类的已经执行完毕

虚拟机必须包含智能一个类的<clinit>()方法在多线程下被同步加锁。

二、类的加载器分类

jvm支持两种类型的类加载器，分别为引导类加载器（bootstrap Classloader）和自定义类加载器（User-Defined Classloader）

从概念上讲，自定义加载器一般指的是程序中由开发人员自定义的一类加载器，但是java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器

无论类加载器的类型如何划分，在程序中我们最常见的类加载器始终只有三个，如下所示：

 

 

 

sun.misc.Launcher被看作是一个java虚拟机入口应用，拓展类加载器跟应用类加载器都是在Launcher内部定义的一个内部类

//获取系统类加载器

ClassLoader systemClassloader= ClassLoader.getSystemClassloader（）

//sun.misc.Launcher$AppClassLoader

//获取其上层：扩展类加载器

ClassLoader extClassloader = systemClassloader.getParent（）；

//sun.misc.Launcher$ExtClassLoader

//获取其上层

ClassLoader bootstrapClassloader = extClassloader.getParent();

//null

对于用户自定义的类来说是用的AppClassLoader

对于类似String类等java的核心类库都是用引导类加载器加载的

获取的加载器类型都是null，无法访问到引导类加载器

1.启动类加载器

 

2.拓展类加载器

 

3.应用程序类加载器

 

获取bootstrapClassloader能够加载的api的路径

URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();

用户自定义类加载器

在java的日厂应用程序开发中，类的加载几乎是由上述三种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。

为设么要自定义类的加载器？

1.隔离加载类

中间件的jar包的路径可能跟框架使用的路径是一样的，框架使用自己的加载器可以避免冲突

2.修改类加载的方式

3.拓展加载源

可以设置从别的地方加载字节码文件，拓宽了字节码文件的来源

4.防止源码泄露

java代码很容易被编译篡改，需要先加密，需要加载到这个类的时候再在加载器中进行解密。

用户自定义类加载器实现步骤

把指定文件名，转化成路径，再转化成二进制流的形式

 

 

关于Classloader的常用方法

如图

 

获取ClassLoader的途径

如图

 

三、双亲委派机制

 

例子，在当前目录下新建一个由引导类加载器加载的类，比如java.lang.String这个类，在其中输入一段文件打印信息，结果证明，虚拟机并不会输出这段文字，因为，他最上面的父类系统类加载器可以完成加载，所以不会动用我们自己写的String类的应用程序加载器来执行加载，这就是双亲委派机制。

 

这个例子中需要用到核心的类，需要使用双亲委派机制来用引导类加载器来加载核心的类，但是类中有一些接口，接口的实现类是属于系统类加载器来加载的，这就需要使用系统类加载器，这就是双亲委派机制的反向委派，所以核心类是引导类加载器加载的，而接口的实现类是由线程上下文加载器来加载的

双亲委派机制的优点

1.避免了类的重复加载

一但有加载器可以加载了，就不会委托给别人加载了

2.保护程序安全，防止核心API被随意篡改

比如你自定义一个String类不可能破坏原有的String类

又比如你在java.lang包下自定义一个不存在的类，使用到引导类加载器时，发现不存在，就会直接报错

沙箱安全机制

 

其他

在jvm中两个class对象是否为同一个类的必要条件

 

类的主动式使用跟被动使用