Java中ClassLoader相关介绍汇总

最新推荐文章于 2024-09-04 22:34:45 发布

lililydia

最新推荐文章于 2024-09-04 22:34:45 发布

阅读量157

点赞数

分类专栏：面试

面试专栏收录该内容

22 篇文章 3 订阅

订阅专栏

1、ClassNotFoundExcetpion
　　我们在开发中，经常可以遇见java.lang.ClassNotFoundExcetpion这个异常，今天我就来总结一下这个问题。对于这个异常，它实质涉及到了java技术体系中的类加载。Java的类加载机制是技术体系中比较核心的部分，虽然它和我们直接打交道不多，但是对其背后的机理有一定理解有助于我们排查程序中出现的类加载失败等技术问题。
2、类的加载过程
　　一个java文件从被加载到被卸载这个生命过程，总共要经历5个阶段，JVM将类加载过程分为：
　　加载->链接（验证+准备+解析）->初始化（使用前的准备）->使用->卸载
（1）加载
　　首先通过一个类的全限定名来获取此类的二进制字节流；其次将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；最后在java堆中生成一个代表这个类的Class对象，作为方法区这些数据的访问入口。总的来说就是查找并加载类的二进制数据。
（2）链接：
　　验证：确保被加载类的正确性；
　　准备：为类的静态变量分配内存，并将其初始化为默认值；
　　解析：把类中的符号引用转换为直接引用；

（

符号引用：符号引用以一组符号来描述所引用的目标。符号引用可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可，符号引用和虚拟机的布局无关。个人理解为：在编译的时候一个每个java类都会被编译成一个class文件，但在编译的时候虚拟机并不知道所引用类的地址，多以就用符号引用来代替，而在这个解析阶段就是为了把这个符号引用转化成为真正的地址的阶段。

直接引用：直接引用和虚拟机的布局是相关的，不同的虚拟机对于相同的符号引用所翻译出来的直接引用一般是不同的。如果有了直接引用，那么直接引用的目标一定被加载到了内存中。

直接引用可以是：

1：直接指向目标的指针。（个人理解为：指向对象，类变量和类方法的指针）

2：相对偏移量。（指向实例的变量，方法的指针）

3：一个间接定位到对象的句柄。

）
（3）为类的静态变量赋予正确的初始值
3、类的初始化
（1）类什么时候才被初始化
　　1）创建类的实例，也就是new一个对象
　　2）访问某个类或接口的静态变量，或者对该静态变量赋值
　　3）调用类的静态方法
　　4）反射（Class.forName(“com.lyj.load”)）
　　5）初始化一个类的子类（会首先初始化子类的父类）
　　6）JVM启动时标明的启动类，即文件名和类名相同的那个类
（2）类的初始化顺序
　　1）如果这个类还没有被加载和链接，那先进行加载和链接
　　2）假如这个类存在直接父类，并且这个类还没有被初始化（注意：在一个类加载器中，类只能初始化一次），那就初始化直接的父类（不适用于接口）
　　3）加入类中存在初始化语句（如static变量和static块），那就依次执行这些初始化语句。
　　4）总的来说，初始化顺序依次是：（静态变量、静态初始化块）–>（变量、初始化块）–> 构造器；如果有父类，则顺序是：父类static方法 –> 子类static方法 –> 父类构造方法- -> 子类构造方法
4、类的加载
　　类的加载指的是将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个这个类的java.lang.Class对象，用来封装类在方法区类的对象。如：

这里写图片描述

　　类的加载的最终产品是位于堆区中的Class对象。Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。加载类的方式有以下几种：
　　1）从本地系统直接加载
　　2）通过网络下载.class文件
　　3）从zip，jar等归档文件中加载.class文件
　　4）从专有数据库中提取.class文件
　　5）将Java源文件动态编译为.class文件（服务器）
5、加载器
　　JVM的类加载是通过ClassLoader及其子类来完成的，类的层次关系和加载顺序可以由下图来描述：
　　这里写图片描述

这里写图片描述

（1）加载器介绍
1）BootstrapClassLoader（启动类加载器）
　　负责加载$JAVA_HOME中jre/lib/rt.jar里所有的class，加载System.getProperty(“sun.boot.class.path”)所指定的路径或jar。
2）ExtensionClassLoader（标准扩展类加载器）
　　负责加载java平台中扩展功能的一些jar包，包括$JAVA_HOME中jre/lib/*.jar或-Djava.ext.dirs指定目录下的jar包。载System.getProperty(“java.ext.dirs”)所指定的路径或jar。
3）AppClassLoader（系统类加载器）
　　负责记载classpath中指定的jar包及目录中class
4）CustomClassLoader（自定义加载器）
　　属于应用程序根据自身需要自定义的ClassLoader，如tomcat、jboss都会根据j2ee规范自行实现。

（2）类加载器的顺序
1）加载过程中会先检查类是否被已加载，检查顺序是自底向上，从Custom ClassLoader到BootStrap ClassLoader逐层检查，只要某个classloader已加载就视为已加载此类，保证此类只所有ClassLoader加载一次。而加载的顺序是自顶向下，也就是由上层来逐层尝试加载此类。
2）在加载类时，每个类加载器会将加载任务上交给其父，如果其父找不到，再由自己去加载。
3）Bootstrap Loader（启动类加载器）是最顶级的类加载器了，其父加载器为null。
---------------------
作者：eff666
来源：CSDN
原文：https://blog.csdn.net/eff666/article/details/52203406
版权声明：本文为博主原创文章，转载请附上博文链接！

ClassLoader的双亲委托模式

系统中的ClassLoader在协同工作时，默认会使用双亲委托模式。即在类加载的时候，系统会判断当前类是否已经被加载，如果已经被加载，就会直接返回可用的类，否则就会尝试加载，在尝试加载时，会先请求双亲处理，如果双亲请求失败，则会自己加载。

注意：双亲为null有两种情况：第一，其双亲就是启动类加载器；第二，当前加载器就是启动类加载器。判断类是否加载时，应用类加载器会顺着双亲路径往上判断，直到启动类加载器。但是启动类加载器不会往下询问，这个委托是单向的。

双亲委托模式的弊端

前文提到，检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。

通常情况下，启动类加载器中的类为系统核心类，包括一些重要的系统接口，而在应用类加载器中，为应用类。按照这种模式，应用类访问系统类自然是没有问题，但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口，该接口需要在应用类中得以实现，该接口还绑定一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中。这时，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。

双亲委托模式的补充

在Java平台中，把核心类（rt.jar）中提供外部服务，可由应用层自行实现的接口，通常可以称为Service Provider Interface，即SPI。
为了解决启动类加载器无法访问应用类加载器加载的类的问题，Java中通过把一个ClassLoader置于一个线程实例中，这个ClassLoader叫做上下文加载器，使该ClassLoader成为一个相对共享的实例。默认情况下，上下文加载器就是应用类加载器，这样即使是在启动类加载器中的代码也可以通过这种方式访问应用类加载器的类，其示意图如下所示：

突破双亲模式

双亲模式的类加载方式是虚拟机默认的行为，但并非必须这么做，通过重载ClassLoader可以修改该行为。事实上，不少应用软件和框架都修改了这种行为，比如Tomcat和OSGi框架，都有各自独特的类加载顺序。具体的过程就不嗷述了，感兴趣的可以取查阅资料。

热替换的实现

  热替换是指在程序的运行过程中，不停止服务，只通过替换程序文件来修改程序的行为。热替换的关键需求在于服务不能中断，修改必须立即表现正在运行的系统之中。基本上大部分脚本语言都是天生支持热替换的，比图PHP，只要替换了PHP源文件，这种改动就会立即生效，而无需重启Web服务器。

  但对Java来说，热替换并非天生就支持，如果一个类已经加载到系统中，通过修改类文件，并无法让系统再来加载并重定义这个类。因此，在Java中实现这一功能的一个可行的方法就是灵活运用ClassLoader。

注意：由不同ClassLoader加载的同名类属于不同的类型，不能相互转换和兼容。即两个不同的ClassLoader加载同一个类，在虚拟机内部，会认为这2个类是完全不同的。

  根据这个特点，可以用来模拟热替换的实现，基本思路如下图所示：