类加载器

1.类加载器的父类(非父子继承关系)

• 启动类加载器，由C++实现，没有父类。

• 拓展类加载器(ExtClassLoader)，由Java语言实现，父类加载器为null

• 系统类加载器(AppClassLoader)，由Java语言实现，父类加载器为ExtClassLoader

• 自定义类加载器，父类加载器肯定为AppClassLoader。

2.在JVM中表示两个class对象是否为同一个类对象存在两个必要条件

• 类的完整类名必须一致，包括包名。
• 加载这个类的ClassLoader(指ClassLoader实例对象)必须相同。

3.自定义类加载器的意义(所谓自定义加载器指自己new 一个类加载器并指定类加载路径或者重新类加载器都可)

• 当class文件不在ClassPath路径下，默认系统类加载器无法找到该class文件，在这种情况下我们需要实现一个自定义的ClassLoader来加载特定路径下的class文件生成class对象。

• 当一个class文件是通过网络传输并且可能会进行相应的加密操作时，需要先对class文件进行相应的解密后再加载到JVM内存中，这种情况下也需要编写自定义的ClassLoader并实现相应的逻辑。

• 当需要实现热部署功能时(一个class文件通过不同的类加载器产生不同class对象从而实现热部署功能)，需要实现自定义ClassLoader的逻辑。

4.线程上下文类加载器--双亲委派模型的破坏者

在Java应用中存在着很多服务提供者接口（Service Provider Interface，SPI），这些接口允许第三方为它们提供实现，如常见的 SPI 有 JDBC、JNDI等，这些 SPI 的接口属于 Java 核心库，一般存在rt.jar包中，由Bootstrap类加载器加载，而 SPI 的第三方实现代码则是作为Java应用所依赖的 jar 包被存放在classpath路径下，由于SPI接口中的代码经常需要加载具体的第三方实现类并调用其相关方法，但SPI的核心接口类是由引导类加载器来加载的，而Bootstrap类加载器无法直接加载SPI的实现类，同时由于双亲委派模式的存在，Bootstrap类加载器也无法反向委托AppClassLoader加载器SPI的实现类。在这种情况下，我们就需要一种特殊的类加载器来加载第三方的类库，而线程上下文类加载器就是很好的选择。
    线程上下文类加载器（contextClassLoader）是从 JDK 1.2 开始引入的，我们可以通过java.lang.Thread类中的getContextClassLoader()和 setContextClassLoader(ClassLoader cl)方法来获取和设置线程的上下文类加载器。如果没有手动设置上下文类加载器，线程将继承其父线程的上下文类加载器，初始线程的上下文类加载器是系统类加载器（AppClassLoader）,在线程中运行的代码可以通过此类加载器来加载类和资源，如下图所示，以jdbc.jar加载为例

从图可知rt.jar核心包是有Bootstrap类加载器加载的，其内包含SPI核心接口类，由于SPI中的类经常需要调用外部实现类的方法，而jdbc.jar包含外部实现类(jdbc.jar存在于classpath路径)无法通过Bootstrap类加载器加载，因此只能委派线程上下文类加载器把jdbc.jar中的实现类加载到内存以便SPI相关类使用。显然这种线程上下文类加载器的加载方式破坏了“双亲委派模型”，它在执行过程中抛弃双亲委派加载链模式，使程序可以逆向使用类加载器，当然这也使得Java类加载器变得更加灵活

很明显了确实通过线程上下文类加载器加载的，实际上核心包的SPI类对外部实现类的加载都是基于线程上下文类加载器执行的，通过这种方式实现了Java核心代码内部去调用外部实现类。我们知道线程上下文类加载器默认情况下就是AppClassLoader，那为什么不直接通过getSystemClassLoader()获取类加载器来加载classpath路径下的类的呢？其实是可行的，但这种直接使用getSystemClassLoader()方法获取AppClassLoader加载类有一个缺点，那就是代码部署到不同服务时会出现问题，如把代码部署到Java Web应用服务或者EJB之类的服务将会出问题，因为这些服务使用的线程上下文类加载器并非AppClassLoader，而是Java Web应用服自家的类加载器，类加载器不同。，所以我们应用该少用getSystemClassLoader()。总之不同的服务使用的可能默认ClassLoader是不同的，但使用线程上下文类加载器总能获取到与当前程序执行相同的ClassLoader，从而避免不必要的问题

 

使用类加载器加载指定类A, 该类A应用的hdfs相关的jar包都是该加载器路径下的, 该类A的使用需要使用反射形式,

类加载器需要设置为当前线程上下文类加载器

类A是内外调用的桥梁,且A必须用指定的这个类加载器加载才行, 类A给外部的输出只能是jdk中加载的类, 不能是hdfs中的类, 否则会报错类找不到

反射的几种使用场景: 

a.上述类A

b.spi机制

c.回调接口实现, 并且通过配置指定

 

5.小结

• 当前类加载器（Current ClassLoader）：每一个类都会使用自己的类加载器（既加载自身的类加载器）来去加载其它类（指的是所依赖的类），如果ClassX引用了ClassY，那么ClassX的类加载器就会加载ClassY（前提是ClassY尚未被加载）
• 父类加载器所加载的类或接口是看不到子类加载器所加载的类或接口，而子类加载器所加载的类或接口是能够看到父类加载器加载的类或接口的
• 当高层提供了统一接口让低层去实现，同时又要是在高层加载（或实例化）低层的类时，必须通过线程上下文类加载器来帮助高层的ClassLoader找到并加载该类。
• 当使用本类托管类加载，然而加载本类的ClassLoader未知时，为了隔离不同的调用者，可以取调用者各自的线程上下文类加载器代为托管

 

另可联系spi机制jdbc加载过程分析学习

https://blog.csdn.net/jslcylcy/article/details/72678432?utm_source=blogxgwz4