image.png

    1ClassLoader.registerAsParallelCapable()
    https://tianshuang.me/2021/06/%E5%85%B3%E4%BA%8E-ClassLoader-registerAsParallelCapable-%E7%9A%84%E5%AE%9E%E7%8E%B0%E6%9C%BA%E5%88%B6/index.html

    2 如果试图在两个类的对象之间进行赋值操作，会抛出 java.lang.ClassCastException。这个特性为同样名称的Java类在JVM中共存创造了条件

    3 类加载传导机制
    Current ClassLoader
    当前类所属的ClassLoader，在虚拟机中类之间引用，默认就是使用这个ClassLoader。另外，当你使用Class.forName(), Class.getResource()这几个不带ClassLoader参数的方法时，默认同样使用当前类的ClassLoader。你可以通过方法XX.class.GetClassLoader()获取

    4 Bundle类加载器：每个Bundle都有自己独立的类加载器，用于加载本Bundle中的类和资源。当一个Bundle去请求加载另一个Bundle导出的Package中的类时，要把加载请求委派给导出类的那个Bundle的加载器处理，而无法自己去加载其他Bundle的类。
    5 ClassLoader
    defineClass()：这个方法用来完成从Java字节代码的字节数组到java.lang.Class的转
    换。这个方法是不能被覆写的，一般是用原生代码来实现的。
     findLoadedClass()：这个方法用来根据名称查找已经加载过的Java类。一个类加载器不会重复加载同一名称的类。
     findClass()：这个方法用来根据名称查找并加载Java类。
     loadClass()：这个方法用来根据名称加载Java类。
     resolveClass()：这个方法用来链接一个Java类。

    这里比较 容易混淆的是 findClass()方法和 loadClass()方法的作用。前面提到过，在Java 类的链接过程中，会需要对 Java 类进行解析，而解析可能会导致当前 Java 类所引用的其它 Java 类被加载。在这个时候，JVM 就是通过调用当前类的定义类加载器
    的 loadClass()方法来加载其它类的。 findClass()方法则是应用创建的类加载器的扩展点。应用自己的类加载器应该覆写 findClass()方法来添加自定义的类加载逻辑。loadClass()方法的默认实现会负责调用 findClass()方法。

    6 类加载器的代理模式默认使用的是父类优先的策略。这个策略的实现是封装在 loadClass()方法中的。如果希望修改此策略，就需要覆写 loadClass()方法。
    1 Class<?> clazz = findLoadedClass(className);这句

    对应的native源码在java_lang_VMClassLoader.cpp，对于系统加载器。在hash表里面找
    对于AppClassLoader extends URLClassLoade
    2 loadClass()会调用findClass
    **

    7 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 的核心库。它也不能代理给系统类加载器，因为它是系统类加载器的祖先类加载器。也就是说，类加载器的代理模式无法解决这个问题。

    8 线程上下文类加载器正好解决了这个问题。如果不做任何的设置，Java 应用的线程的上下文类加载器默认就是系统上下文类加载器。在 SPI 接口的代码中使用线程上下文类加载器，就可以成功的加载到 SPI 实现的类。线程上下文类加载器在很多 SPI 的实现中都会用到。

    9 JNDI，JDBC的诉求是：

    为了能让应用程序访问到这些jar包中的实现类，即用appClassLoarder去加载这些实现类。可以用getContextClassLoader取得当前线程的ClassLoader（即appClassLoarder），然后去加载这些实现类，就能让应用访问到。

    10 tomcat的诉求：
    稍微跟上面有些不同，容器不希望它下面的webapps之间能互相访问到，所以不能用appClassLoarder去加载。所以tomcat新建一个sharedClassLoader（它的parent是commonClassLoader，commonClassLoader的parent是appClassLoarder，默认情况下，sharedClassLoader和commonClassLoader是同一个UrlClassLoader实例），这是catalina容器使用的ClassLoader。对于每个webapp，为其新建一个webappClassLoader，用于加载webapp下面的类，这样webapp之间就不能相互访问了。tomcat的ClassLoader不完全遵循双亲委派，首先用webappClassLoader去加载某个类，如果找不到，再交给parent。而对于java核心库，不在tomcat的ClassLoader的加载范围。