JAVA核心机制之类加载机制

不念不忘少年蓝@ 2022-03-15 10:50 290阅读 0赞

作为一个Java程序员，了解jvm即Java虚拟机是一件很有必要的事。

### 说起Java，人们首先想到的是Java编程语言，然而事实上，Java是一种技术，它由四方面组成：J**ava编程语言、Java类文件格式、Java虚拟机和Java应用程序接口(Java API)**。它们的关系如下图所示： ###

![SouthEast][]

运行期环境代表着Java平台，开发人员编写Java代码(.java文件)，然后将之编译成字节码(.class文件)，再然后字节码被装入内存，一旦字节码进入虚拟机，它就会被解释器解释执行，或者是被即时代码发生器有选择的转换成机器码执行。

以源代码文件为起点，开始整个Java程序的运行过程：

[Java代码编译过程简述][Java]

![Center][]

一般而言，我们自己写的Java程序是.Java文件，如下图这是我的贪吃蛇小游戏在计算机存储的格式，.Java文件在运行的时候，并不能被计算机所理解，换一句话来说，.java文件是我们人能够看懂的语言，二计算机只认识0和1，代码编译将本地机器码转化为字节码，也就是.class文件，Java编译器完成代码编译这项工作的时候，.class文件是计算机所能够理解的，但是不一定是计算机做能够运行的，所以需要类加载机制进行加载，然后在jvm的内存中运行，Java平台无关性的计时就在于这种字节码的运用，这篇文章我们将介绍Java的类加载机制，也就是将.class文件转化成为转化为jvm能够理解运行的语言，然后在内存分析中介绍加载后的语言怎么样在内存中进行存储和运行，最后介绍垃圾会后机制是如何将不用的变量和代码作为垃圾回收的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc5MjE2Mg_size_16_color_FFFFFF_t_70][]

### **jvm的类加载机制将Java程序的.class文件转化为加载到内存，并对数据进行校验，转换解析和初始化，最终编程能够被Java虚拟机直接使用的Java类型，** ###

![jvmä½ç³»ç»æ][jvm]

JVM的基本组成   
(1)指令集:JVM指令集   
(2)类加载器：在jvm启动时或者类在运行时将需要的class加载到JVM中   
(3)执行引擎：负责执行class文件中的字节码指令，相当于CPU   
(4)运行时数据区：将内存划分成若干个区，分别完成不同的任务   
(5)本地方法区：调用C或C++实现的本地方法代码返回的结果

### **Jvm类加载器介绍以下几个模块：** ###

*  类加载过程，加载，连接，初始化
 *  类加载器的层次结构
 *  类加载器的代理模式

### **（一）类加载全过程** ###

***（1）什么是类加载机制？***

jvm将class文件加载到内存，并对数据进行校验，解析和初始化，最终形成jvm可以直接用来使用的Java类型语言的过程。

将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的**方法区**内，然后在**堆区**创建一个java.lang.Class对象，用来封装类在方法区内的数据结构。

类的加载的最终产品是位于堆区中的Class对象，Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。

![webp][]

类加载的全过程包括：加载，连接，初始化，其中，连接包括验证，准备，解析三个过程。

![ç±»ççå½å¨æ][20150626171731434]

(1)第一阶段：找到class文件并把这个文件包含的字节码加载到内存   
(2)第二阶段：字节码验证，class类数据结构分析以及相应内存分配，符号表的链接。   
(3)第三阶段：类中静态属性初始化赋值以及静态代码块的执行

***（2）类加载机制的全过程***

**  1.加载**

1.   主要工作是：将Java字节码内容加载到内存中，并将这些静态数据转化为方法去中运行时的数据结构，在堆中生成代表这个类的Java.lang.Class对象，作为方法区类数据的访问入口。

![20190302113521638.png][]

类的加载由类加载器完成，类加载器通常由JVM提供，这些类加载器也是前面所有程序运行的基础，JVM提供的这些类加载器通常被称为系统类加载器。除此之外，开发者可以通过继承ClassLoader基类来创建自己的类加载器。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc5MjE2Mg_size_16_color_FFFFFF_t_70 1][]

2.连接

1.  将Java类的二进制代码合并到jvm的运行状态的过程， 类的二进制数据合并入JRE（Java运行时环境）中
2.  连接包括三个阶段：验证，准备，解析。

<1>验证：确保加载的类信息符合jvm规范，没有安全方面的问题。

<2>准备 : 为类静态变量分配内存并类静态变量初始化阶段。这些变量所使用的内存都需要在方法去中进行分配。

> 为类的静态变量（static filed）在方法区分配内存，并赋默认初值（0值或null值）。如static int a = 100;
> 
> 静态变量a就会在准备阶段被赋默认值0。
> 
> 对于一般的成员变量是在类实例化时候，随对象一起分配在堆内存中。
> 
> 另外，静态常量（static final filed）会在准备阶段赋程序设定的初值，如static final int a = 666;  静态常量a就会在准备阶段被直接赋值为666，对于静态变量，这个操作是在初始化阶段进行的。  
>

<3>解析：虚拟机将常量池内的符号引用转化为直接引用的过程。

3.初始化

在准备阶段，变量已经赋过一次系统要求的初始值，在初始化阶段，根据程序员指定的主观计划去初始化类变量和其他资源，即执行类构造器<client>()中的方法，client<>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static()）的语句合并而产生的。

**类的初始化的主要工作**是为静态变量赋程序设定的初值。

如static int a = 100;在准备阶段，a被赋默认值0，在初始化阶段就会被赋值为100。

1.  编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问到定义在静态语句块之前的变量，而定义在它之后的变量，在前面的静态语句块可以赋值，但不能访问，代码解释如下：

public class Test {
        static {
            i = 0;                       //给变量赋值可以正常编译通过
            System.out.print(i);         //编译器会提示“非法向前引用”
            }
        static int i = 1;
    }

1.  初始化方法执行的顺序，虚拟机会保证在子类的初始化方法执行之前，父类的初始化方法已经执行完毕，因此在虚拟机中第一个被执行的类初始化方法一定是java.lang.Object。另外，也意味着父类中定义的静态语句块要优先于子类的变量赋值操作，例如：

static class Parent {
        public static int A = 1;
        static {
            A = 2;
            }
        }
    
    static class Sub extends Parent {
        public static int B = A;
        }
    
    public static void main(String[] args) {
        System.out.println(Sub.B);
        }

执行的结果。字段B的值将会是2而不是1。

1.  clinit ()方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成clinit()方法。
2.  接口中不能使用静态语句块，但仍然有变量初始化的操作，因此接口与类一样都会生成clinit()方法，但与类不同的是，执行接口的初始化方法之前，不需要先执行父接口的初始化方法。只有当父接口中定义的变量使用时，才会执行父接口的初始化方法。另外，接口的实现类在初始化时也一样不会执行接口的clinit()方法。
3.  虚拟机会保证一个类的clinit()方法在多线程环境中被正确的加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的clinit()方法，其他线程都需要阻塞等待，直到活动线程执行类初始化方法完毕。

Java虚拟机规范中严格规定了有且只有**五种情况必须对类进行初始化**：

1、使用new字节码指令创建类的实例，或者使用getstatic、putstatic读取或设置一个静态字段的值（放入常量池中的常量除外），或者调用一个静态方法的时候，对应类必须进行过初始化。

2、通过java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则要首先进行初始化。

3、当初始化一个类的时候，如果发现其父类没有进行过初始化，则首先触发父类初始化。

4、当虚拟机启动时，用户需要指定一个主类（包含main()方法的类），虚拟机会首先初始化这个类。

5、使用jdk1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF\_getStatic、REF\_putStatic、RE\_invokeStatic的方法句柄，并且这个方法句柄对应的类没有进行初始化，则需要先触发其初始化。

### **（二）类加载器的层次结构** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc5MjE2Mg_size_16_color_FFFFFF_t_70 2][]

类加载其包括**引导类加载器，继承类加载器，应用加载器和自定义加载器**，具体加载过程如下：

![20160523201051069][]

*  **引导(启动)类加载器**（Bootstrap Class Loader） 它用来加载Java的核心库(`JAVA_HOME/jre/lib/rt.jar` 或 `sun.boot.class.path` 路径下的内容），是用原生代码来实现的（C++）,并 不继承自`java.lang.ClassLoader`

rt.jar

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc5MjE2Mg_size_16_color_FFFFFF_t_70 3][]

加载扩展类和应用程序类加载器，并指定他们的父类加载器。

*  **扩展类加载器**（Extensions Class Loader） 用来加载Java的扩展库(`JAVA_HOME/jre/lib/ext/*.jar`或 `java.ext.dirs` 路径下的内容) .java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。由 `sun.misc.Launcher$ExtClassLoader` 实现

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc5MjE2Mg_size_16_color_FFFFFF_t_70 4][]

ext

![Image 1][]

继承结构

*  **应用程序类加载器**（Application Class Loader）它根据 Java 应用的类路径（ClassPath, java.class.path）来加载。一般来说，Java应用的类都是由它来完成加载的。由 `sun.misc.Launcher$AppClassLoader` 实现

![Image 1][]

*  **自定义类加载器 **     开发人员可以通过继承 `java.lang.ClassLoader` 类的方式实现自己的类加载器，以满足一些特殊的要求。

**注意**：除了启动类加载器是由 C++ 编写外，其他都是 Java 编写，且都继承`java.lang.ClassLoader`

![webp 1][]

public class Demo01 {
        public  static  void  main(String  []args){
        	//验证类加载器与类加载器间的父子关系
        	 
        		//获取系统/应用类加载器
        		ClassLoader appClassLoader = ClassLoader.getSystemClassLoader();
        		System.out.println("系统/应用类加载器：" + appClassLoader);
        		//获取系统/应用类加载器的父类加载器，得到扩展类加载器
        		ClassLoader extcClassLoader = appClassLoader.getParent();
        		System.out.println("扩展类加载器" + extcClassLoader);
        		System.out.println("扩展类加载器的加载路径：" + System.getProperty("java.ext.dirs"));
        		//获取扩展类加载器的父加载器，但因根类加载器并不是用Java实现的所以不能获取
        		System.out.println("扩展类的父类加载器：" + extcClassLoader.getParent());
         
        }
      }

运行结果如下  
![20190302134518251.png][]

过程分析：

![Center 1][]

引用：[ JVM类加载机制详解（二）类加载器与双亲委派模型][JVM]

### **（三）类加载器的代理模式** ###

代理模式指交给指定加载器来加载指定的类。一般而言，常用的代理模式是双亲代理模式。双亲委托机制就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归 (本质上就是loadClass函数的递归调用)。因此，所有的加载请求最终都应该传送到顶层的启动类加载器中。如果父类加载器可以完成这个类加载请求，就成功返回；只有当父类加载器无法完成此加载请求时，子加载器才会尝试自己去加载。

双亲委托机制的作用是防止系统jar包被本地替换，因为查找方法过程都是从最底层开始查找。

![è¿éåå¾çæè¿°][20160523201244304]

输出结果为“123”，为什么kkk.toString()打印出来不是”自定义string”呢，是因为java加载类的时候，默认采用双亲代理机制，即在加载类的时候，不先由本应用程序的类加载器加载，而是由父加载器加载，而父加载器加载类的时候，又由父加载器加载，一旦发现jvm堆内存中已经有该类的，则不加载该类。

引用：：

[(转)Java 详解 JVM 工作原理和流程][Java _ JVM]

[SouthEast]: /images/20220315/d996be1c5aa9402784f092df0d97cc57.png
[Java]: https://blog.csdn.net/fuzhongmin05/article/details/54880257
[Center]: /images/20220315/01c3fa8392a8448e8e447602d8957d30.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc5MjE2Mg_size_16_color_FFFFFF_t_70]: /images/20220315/53eeefed67b942db916b124dd6ffb35d.png
[jvm]: /images/20220315/185bc46bf0854af9a602af7e3993a299.png
[webp]: /images/20220315/082bb5b5e2ae4019bcec5cdb52ec86f3.png
[20150626171731434]: /images/20220315/6da93cecf98640f08cbcb3621d35b651.png
[20190302113521638.png]: /images/20220315/c1bcb37462ef45c9a55a1c0b6b924e8f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc5MjE2Mg_size_16_color_FFFFFF_t_70 1]: /images/20220315/cfcb81d7085e49bb8a861890d524a048.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc5MjE2Mg_size_16_color_FFFFFF_t_70 2]: /images/20220315/ac6f6194e03e48a38b5f04307b148d61.png
[20160523201051069]: /images/20220315/ceda0fcead034a0e9605516595b28c0a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc5MjE2Mg_size_16_color_FFFFFF_t_70 3]: /images/20220315/ab8c41c11c68440d9d585bdd62724841.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc5MjE2Mg_size_16_color_FFFFFF_t_70 4]: /images/20220315/0747204084a64ad4b5ae572a85e62f54.png
[Image 1]: 
[webp 1]: /images/20220315/edc04bdec1bc486b9de35583101e30d9.png
[20190302134518251.png]: /images/20220315/b54052624a8b4006aa71afde276e1715.png
[Center 1]: /images/20220315/24dd163f4d51452082918a0ebc19dc97.png
[JVM]: https://blog.csdn.net/zhangliangzi/article/details/51338291
[20160523201244304]: /images/20220315/feab4f87dc3c44a6af6638c5f8b87485.png
[Java _ JVM]: https://www.cnblogs.com/lishun1005/p/6019678.html