JVM加载class文件的原理机制简单总结

港控/mmm° 2022-06-10 12:57 140阅读 0赞

Java中的所有类，必须被装载到jvm中才能运行，这个装载工作是由jvm中的类装载器完成的,类装载器所做的工作实质是把类文件从硬盘读取到内存中  
**java中的类大致分为三种：**  
1).系统类  
2).扩展类  
3).由程序员自定义的类  
**类装载方式，有两种**  
1).隐式装载， 程序在运行过程中当碰到通过new 等方式生成对象时，隐式调用类装载器加载对应的类到jvm中  
2).显式装载， 通过class.forname()等方法，显式加载需要的类  
**类加载的动态性体现**  
一个应用程序总是由n多个类组成，Java程序启动时，并不是一次把所有的类全部加载后再  
运行，它总是先把保证程序运行的基础类一次性加载到jvm中，其它类等到jvm用到的时候再加载，这样的好处是节省了内存的开销，因为java最早就是为嵌入式系统而设计的，内存宝贵，这是一种可以理解的机制，而用到时再加载这也是java动态性的一种体现  
**java类装载器**  
Java中的类装载器实质上也是类，功能是把类载入jvm中，值得注意的是jvm的类装载器并不是一个，而是三个，层次结构如下：  
Bootstrap Loader - 负责加载系统类  
|  
\- - ExtClassLoader - 负责加载扩展类  
|  
\- - AppClassLoader - 负责加载应用类  
为什么要有三个类加载器，一方面是分工，各自负责各自的区块，另一方面为了实现委托模型，下面会谈到该模型  
1) Bootstrap类加载器 – JRE/lib/rt.jar  
2) Extension类加载器 – JRE/lib/ext或者java.ext.dirs指向的目录  
3) Application类加载器 – CLASSPATH环境变量, 由-classpath或-cp选项定义,或者是JAR中的Manifest的classpath属性定义.  
**类加载器之间是如何协调工作的**  
类加载器的工作原理基于三个机制：委托、可见性和单一性  
**委托机制**  
当一个类加载和初始化的时候，类仅在有需要加载的时候被加载。假设你有一个应用需要的类叫作Abc.class，首先加载这个类的请求由 Application类加载器委托给它的父类加载器Extension类加载器，然后再委托给Bootstrap类加载器。Bootstrap类加载器 会先看看rt.jar中有没有这个类，因为并没有这个类，所以这个请求由回到Extension类加载器，它会查看jre/lib/ext目录下有没有这 个类，如果这个类被Extension类加载器找到了，那么它将被加载，而Application类加载器不会加载这个类；而如果这个类没有被 Extension类加载器找到，那么再由Application类加载器从classpath中寻找。记住classpath定义的是类文件的加载目 录，而PATH是定义的是可执行程序如javac，java等的执行路径。  
**可见性机制**  
可见性的原理是子类的加载器可以看见所有的父类加载器加载的类，而父类加载器看不到子类加载器加载的类。  
**单一性机制**  
根据这个机制，父加载器加载过的类不能被子加载器加载第二次。虽然重写违反委托和单一性机制的类加载器是可能的，但这样做并不可取。  
  
  
线程上下文类加载器（context class loader）是从 JDK 1.2 开始引入的。类 Java.lang.Thread中的方法 getContextClassLoader()和 setContextClassLoader(ClassLoader cl)用来获取和设置线程的上下文类加载器。如果没有通过 setContextClassLoader(ClassLoader cl)方法进行设置的话，线程将继承其父线程的上下文类加载器。Java 应用运行的初始线程的上下文类加载器是系统类加载器。在线程中运行的代码可以通过此类加载器来加载类和资源。  
　　前面提到的类加载器的代理模式并不能解决 Java 应用开发中会遇到的类加载器的全部问题。Java 提供了很多服务提供者接口（Service Provider Interface，SPI），允许第三方为这些接口提供实现。常见的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。这些 SPI 的接口由 Java 核心库来提供，如 JAXP 的 SPI 接口定义包含在 javax.xml.parsers包中。这些 SPI 的实现代码很可能是作为 Java 应用所依赖的 jar 包被包含进来，可以通过类路径（CLASSPATH）来找到，如实现了 JAXP SPI 的 Apache Xerces所包含的 jar 包。SPI 接口中的代码经常需要加载具体的实现类。如 JAXP 中的 javax.xml.parsers.DocumentBuilderFactory类中的 newInstance()方法用来生成一个新的 DocumentBuilderFactory的实例。这里的实例的真正的类是继承自 javax.xml.parsers.DocumentBuilderFactory，由 SPI 的实现所提供的。如在 Apache Xerces 中，实现的类是 org.apache.xerces.jaxp.DocumentBuilderFactoryImpl。而问题在于，SPI 的接口是 Java 核心库的一部分，是由引导类加载器来加载的；SPI 实现的 Java 类一般是由系统类加载器来加载的。引导类加载器是无法找到 SPI 的实现类的，因为它只加载 Java 的核心库。它也不能代理给系统类加载器，因为它是系统类加载器的祖先类加载器。也就是说，类加载器的代理模式无法解决这个问题。  
　　线程上下文类加载器正好解决了这个问题。如果不做任何的设置，Java 应用的线程的上下文类加载器默认就是系统上下文类加载器。在 SPI 接口的代码中使用线程上下文类加载器，就可以成功的加载到 SPI 实现的类。线程上下文类加载器在很多 SPI 的实现中都会用到。  
  
  
**类的加载过程**

JVM将类加载过程分为三个步骤：装载（Load），链接（Link）和初始化(Initialize)链接又分为三个步骤，如下图所示：

![Center][]

1) 装载：查找并加载类的二进制数据；  
2)链接：  
验证：确保被加载类的正确性；  
准备：为类的静态变量分配内存，并将其初始化为默认值；  
解析：把类中的符号引用转换为直接引用；  
3)初始化：为类的静态变量赋予正确的初始值；  
那为什么我要有验证这一步骤呢？首先如果由编译器生成的class文件，它肯定是符合JVM字节码格式的，但是万一有高手自己写一个class文件，让JVM加载并运行，用于恶意用途，就不妙了，因此这个class文件要先过验证这一关，不符合的话不会让它继续执行的，也是为了安全考虑吧。  
准备阶段和初始化阶段看似有点牟盾，其实是不牟盾的，如果类中有语句：private static int a = 10，它的执行过程是这样的，首先字节码文件被加载到内存后，先进行链接的验证这一步骤，验证通过后准备阶段，给a分配内存，因为变量a是static的，所以此时a等于int类型的默认初始值0，即a=0,然后到解析（后面在说），到初始化这一步骤时，才把a的真正的值10赋给a,此时a=10。  
**类的初始化**  
类什么时候才被初始化：  
1）创建类的实例，也就是new一个对象  
2）访问某个类或接口的静态变量，或者对该静态变量赋值  
3）调用类的静态方法  
4）反射（Class.forName("com.lyj.load")）  
5）初始化一个类的子类（会首先初始化子类的父类）  
6）JVM启动时标明的启动类，即文件名和类名相同的那个类  
只有这6中情况才会导致类的类的初始化。  
类的初始化步骤：  
1）如果这个类还没有被加载和链接，那先进行加载和链接  
2）假如这个类存在直接父类，并且这个类还没有被初始化（注意：在一个类加载器中，类只能初始化一次），那就初始化直接的父类（不适用于接口）  
3)加入类中存在初始化语句（如static变量和static块），那就依次执行这些初始化语句。

[Center]: /images/20220610/dcf4a2aaaf8a4a20b5bf0d34b062a8ee.png