jvm类加载器

   ClassLoader的作用：
        ClassLoader是Java的核心组件，所有的Class都是由ClassLoader进行加载的，ClassLoader负责通过各种方式将Class信息的二进制数据流读入JVM内部，转换为一个与目标类对应的java.lang.Class对象实例。然后交给Java虚拟机进行链接、初始化等操作。因此，ClassLoader在整个装载阶段，只能影响到类的加载，而无法通过ClassLoader去改变类的链接和初始化与为。至于它是否可以运行，则由Execution Engine决定。

        类加载的分类
        类的加载分类：显式加载 vs 隐式加载
        class文件的显式加载与隐式加载的方式是指JVM加载class文件到内存的方式。
显式加载指的是在代码中通过调用ClassLoader加载class对象，如直接使用Class.forName(name)或this.getClass().getClassLoader().loadClass()加载class对象。隐式加载则是不直接在代码中调用ClassLoader的方法加载class对象，而是通过虚拟机自动加载到内存中，如在加载某个类的class文件时，该类的class文件中引用了另外一个类的对象，此时额外引用的类将通过JVM自动加载到内存中。在日常开发以上两种方式一般会混合使用。

     何为类的唯一性?
        对于任意一个类，都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一性。每一个类加载器，都拥有一个独立的类名称空间：比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义。否则，即使这两个类源自同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那这两个类就必定不相等。
         命名空间
        每个类加载器都有自起的命名空间，金名空间由该加载器及所有的父加载器所加载的类组成
在同一命名空间中，不会出现类的整名字(包括类的包名)相同的两个类
在不同的命名空间中，有可能会出现类的完整名字(包括类的包名)相同的两个类
在大型应用中，我们往往借助这一特性，来运行同一个类的不同版本。

jvm支持两种类型加载器，引导类加载器和自定义类加载器。
    虚拟机自带的加载器有三种：
          1. 启动类加载器(引导类加载器)
            c/c++实现的，嵌套在JVM内部，用来加载java得核心类库，用于提供jvm自身语言的一些类,没有父类加载器
          2. 拓展类加载器
              java语言编写的，由sun.misc.launcher$ExtClassLoader实现。派生于ClassLoader类，它的父加载器实启动类加载器。加载java.ext.dirs系统属性所指定的目录中加载类库，jdk安装目录的jre/lib/ext扩展目录下加载类库。
          3.系统类加载器
              java语言编写的，由sun.misc.launcher$AppClassLoader实现，派生于ClassLoader类，父加载器为扩展类加载器，负责加载环境变量classpath下或系统属性java.class.path指定路径的类库，同时该类也是用户自定义类默认的类加载器。

        //获取系统加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader); //sun.misc.Launcher$AppClassLoader@18b4aac2


        //获取拓展类加载器
        ClassLoader parent = systemClassLoader.getParent();
        System.out.println(parent); //sun.misc.Launcher$ExtClassLoader@1b6d3586


        //获取引导类加载器
        ClassLoader parent1 = parent.getParent();
        System.out.println(parent1);  //null


        //用户自定义类默认加载器
        ClassLoader classLoader = TestHello.class.getClassLoader();
        System.out.println(classLoader); //sun.misc.Launcher$AppClassLoader@18b4aac2

        这里的引导类加载器输出为null,但是这里并非是没有,只是由于它的实现使用C/C++编写，但其实引导类加载器是存在的(Bootstrap ClassLoader),同时它也是后两者的父加载器、

      4.用户自定义类加载器:

          在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的。在必要时，我们还可以自定义类加载器，来定制类的加载方式。体现Java语言强大生喻力和巨大魅力的关键因素之一便是，Java开发者可以自定义类加载器来实现类库的动态加载，加载源可以是本地的JAR包，也可以是网络上的远程资源。通过类加载器可以实现非常绝妙的插件机制，这方面的实际应用案例举不胜举。例如，著名的OSGI组件框架，再如Eclipse的插件机制。类加载器为应用程序提供了一种动态增加新功能的机制，这种机制无须重新打包发布应用程序就能实现。
同时，自定义加载器能够实现应用隔离，例如Tomcat， Spring等中间件和组件框架都在内部实现了自定义的加载器，并通过自定义加载器隔离不同的组件模块。这种机制比C/C++程序要好太多，想不修改C/C++程序就能为其新增功能，几乎是不可能的，仅仅一个兼容性便能阻挡住所有美好的设想。
        自定义类加载器通常需要继承于ClassLoader。

为什么要自定义类加载器？
        隔离加载类某些框架内进行中间件与应用的模块隔离，把类加载到不同的环境。比如：阿里内某容器框架通过自定义类加载器确应用中依赖的jar包不会影响到中间件运行时使用的jar包。再比如：Tomcat这类Web应用服务器，内部自定义了好几类加载器，用于隔离同一个Web应用服务器上的不同应用程序。修改类加载的方式的加载模型并非强制，除Bootstrap外，其他的加载并非一定要引入，或者根据实际情况在某个时间点进行按需进行态加载扩展加载源从数据库、网络、甚至是电视机机顶盒进行加载防止源码泄漏代码容易被编译和篡改，可以进行编译加密。那么类加载也需要自定义，还原加密的字节码。
常见的场景
        实现类似进程内隔离，类加载器实际上用作不同的命名空间，以提供类似容器、模块化的效果。例如，两个模块依赖于某个类库的不同版本，如果分别被不同的容器加载，就可以互不干扰。这个方面的集大成者是Java EE和OSGI、JPMS等框架。
应用需要从不同的数据源获取类定义信息，例如网络数据源，而不是本地文件系统。或者是需要自己操纵字节码，动态修改或者生成类型。

   注意：
        在一般情况下，使用不同的类加载器去加载不同的功能模块，会提高应用程序的安全性。但是，如果涉发ava类型转换，则加载器反而容易产生不美好的事情。在做Java类型转换时，只有两个类型都是由同一个加载器所加载，才能进行类型转换，否则转换时会发生异常。

1.实现方式
        Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类。在自定义 ClassLoader的子类时候，我们常见的会有两种做法：
方式一：重写loadClass()方法
方式二：重写findClass()方法-->推荐
2.对比
        这两种方法本质上差不多，毕竟loadClass()也会调用findClass()，但是从逻辑上讲我们最好不要直接修改loadClass()的内部逻辑。建议的做法是只在findClass()里重写自定义类的加载方法，根据参数指定类的名字，返回对应的Class对象的引用。
loadClass()这个方法是实现双亲委派模型逻辑的地方，擅自修改这个方法会导致模型被破坏，容易造成问题。因此我们最好是在双亲委派模型框架内进行小范围的改动，不破坏原有的稳定结构。同时，也避免了自己重写
loadClass()方法的过程中必须写双亲委托的重复代码，从代码的复用性来看，不直接修改这个方法始终是比较好的选择。
当编写好自定义类加载器后，便可以在程序中调用1oadClass()方法来实现类加载操作。
3.说明
其父类加载器是系统类加载器
JVM中的所有类加载都会使用java.lang.ClassLoader.loadClass(String)接口(自定义类加载器并重写java.lang.ClassLoader.loadClass(String)接口的除外)，连JDK的核心类库也不能例外。

 说明:

      站在程序的角度看，引导类加载器与另外两种类加载器(系统类加载器和扩展类加载器)并不是同一个层次意义上的加载器，引导类加载器是使用C++语言编写而成的，而另外两种类加载器则是使用Java语言编写而成的。由于引导类加载器压根儿就不是一个Java类，因此在Java程序中只能打印出空值。
       数组类的Class对象，不是由类加载器去创建的，而是在Java运行期JVM根据需要自动创建的。对于数组类的类加载器来说，是通过Class.getClassLoader()返回的，与数组当中元素类型的类加载器是一样的；如果数组当中的元素类型是基本数据类型，数组类是没有类加载器的。因为基本数据类型有虚拟机预先定义,引用数据类型则需要进行类的加载.

    总结：类加载器是类加载系统中加载阶段重要的工具，类加载器之间的关系是包含(引用)关系，并非是继承(子父类)关系。

       5.补充:

   Class.forName()与ClassLoader.loadClass()区别:
        Class.forName()：是一个静态方法，最常用的是Class.forName(String className)；根据传入的类的全限定名返回一个 Class 对象。该方法在将Class 文件加载到内存的同时，会执行类的初始化。如：
Class.forName("com.atguigu.java.HelloWorld");
        ClassLoader.loadClass()：这是一个实例方法，需要一个ClassLoader 对象来调用该方法。该方法将Class文件加载到内存时，并不会执行类的初始化，直到这个类第一次使用时才进行初始化。该方法因为需要得到一个ClassLoader 对象，所以可以根据需要指定使用哪个类加载器.如：ClassLoader cl=.......；cl.loadClass("com.atguigu.java.HelloWorld");

    6.双亲委派机制的优势和劣势

        类加载器用来把类加载到Java虚拟机中。从JDK1.2版本开始，类的加载过程采用双亲委派机制，这种机制能更好地保证Java平台的安全。
1.定义
        如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就成功返回。只有父类加载器无法完成此加载任务时，才自己去加载。
2.本质
        规定了类加载的顺序是：引导类加载器先加载，若加载不到，由扩展类加载器加载，若还加载不到，才会由系统类加载器或自定义的类加载器进行加载。

 1.双亲委派机制优势
        避免类的重复加载，确保一个类的全局唯一性Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。
        保护程序安全，防止核心API被随意篡改
2.代码支持
双亲委派机制在java.lang.ClassLoader.loadClass(String，boolean)接口中体现。该接口的逻辑如下：
        (1)先在当前加载器的缓存中查找有无目标类，如果有，直接返回。
        (2)判断当前加载器的父加载器是否为空，如果不为空，则调用parent.loadClass(name， false)接口进行加载。
        (3)反之，如果当前加载器的父类加载器为空，则调用findBootstrapClass0rNu11(name)接口，让引导类加载器进行加载。
        (4)如果通过以上3条路径都没能成功加载，则调用findClass(name)接口进行加载。该接口最终会调用java.lang.ClassLoader接口的defineClass系列的native接口加载目标Java类。双亲委派的模型就隐藏在这第2和第3步中。

      3.思考
        如果在自定义的类加载器中重写java.lang.ClassLoader.loadClass(String)或
java.lang.ClassLoader.loadClass(String，boolean)方法，抹去其中的双亲委派机制，仅保留上面这4步中的第1步与第4步，那么是不是就能够加载核心类库了呢？
这也不行！因为JDK还为核心类库提供了一层保护机制。不管是自定义的类加载器，还是系统类加载器抑或扩展类加载器，最终都必须调用 java.lang.ClassLoader.defineClass(String，byte[], int, int,ProtectionDomain)方法，而该方法执行preDefineClass()接口，该接口中提供了对JDK核心类库的保护。
4.双亲委托模式的弊端
        检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。
        通常情况下，启动类加载器中的类为系统核心类，包括一些重要的系统接口，而在应用类加载器中，为应用类。按照这种模式，应用类访问系统类自然是没有问题，但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口，该接口需要在应用类中得以实现，该接口还绑定一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中。这时，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。
     结论：
               由于Java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型，只是建议采用这种方式而已。比如在Tomcat中，类加载器所采用的加载机制就和传统的双亲委派模型有一定区别，当缺省的类加载器接收到一个类的加载任务时，首先会由它自行加载，当它加载失败时，才会将类的加载任务委派给它的超类加载器去执行，这同时也是Servlet规范推荐的一种做法  

           破坏双亲委派机制:

           第一次破坏双亲委派机制：
                双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前——即JDK 1.2面世以前的“远古”时代。由于双亲委派模型在JDK 1.2之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就已经存在，面对已经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些已有代码，无法再以技术手段避免loadClass()被子类覆盖的可能性，只能在JDK1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码。上节我们已经分析过loadClass()方法，双亲委派的具体逻辑就实现在这里面，按照loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的findClass()方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的。

        第二次破坏双亲委派机制：线程上下文类加载器
         双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题(越基础的类由越上层的加载器进行加载)，基础类型之所以被称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户的代码，那该怎么办呢？
这并非是不可能出现的事情，一个典型的例子便是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载(在JDK 1.3时加入到rt.jar的)，肯定属于Java中很基础的类型了。但JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的JNDI服务提供者接口(
Service Provider Interface, SPI)的代码，现在问题来了，启动类加载器是绝不可能认识、加载这些代码的，那该怎么办？(SPI：在Java平台中，通常把核心类rt.jar中提供外部服务、可由应用层自行实现的接口称为SPI)
为了解决这个困境，Java的设计团队只好引入了一个不太优雅的设计：线程上下文类加载器(Thread ContextClassLoader)。这个类加载器可以通过iava.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。
有了线程上下文类加载器，程序就可以做一些“舞弊”的事情了。JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则，但也是无可奈何的事情。Java中涉及SPI的加载基本上都采用这种方式来完成，例如JNDI、JDBC、JCE、JAXB和JBI等。不过，当SPI的服务提供者多于一个的时候，代码就只能根据具体提供者的类型来硬编码判断，为了消除这种极不优雅的实现方式，在JDK 6时，JDK提供了
java.util.ServiceLoader类，以META-INF/services中的配置信息，辅以责任链模式，这才算是给SPI的加载提供了一种相对合理的解决方案。

 第三次破坏双亲委派机制：
        双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的。如：代码热替换(Hot Swap)、模块热部署(Hot Deployment)等IBM公司主导的JSR-291(即OSGi R4.2)实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块(OSGi中称为Bundle)都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构。当收到类加载请求时，OSGi将按照下面的顺序进行类搜索：
1)将以java.*开头的类，委派给父类加载器加载。
2)否则，将委派列表名单内的类，委派给父类加载器加载。
3)否则，将Import列表中的类，委派给Export这个类的Bundle的类加载器加载。
4)否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。
5)否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。
6)否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。
7)否则，类查找失败。
说明：只有开头两点仍然符合双亲委派模型的原则，其余的类查找都是在平级的类加载器中进行的

    jdk9之后发生的变化:
        1. 扩展机制被移除，扩展类加载器由于向后兼容性的原因被保留，不过被重命名为平台类加载器(platform classloader)。可以通过ClassLoader的新方法getPlatformClassLoader()来获取。
JDK 9 时基于模块化进行构建(原来的 rt.jar 和tools.jar 被拆分成数十个MOD 文件)， I其中的Java 类库就已天然地满足了可扩展的需求，那自然无须再保留<JAVA_HOME>\lib\ext 目录，此前使用这个目录或者 java.ext.dirs 系统变量来扩展 JDK 功能的机制已经没有继续存在的价值了。
        2. 平台类加载器和应用程序类加载器都不再继承自java.net.URLClassLoader。
现在启动类加载器、平台类加载器、应用程序类加载器全都继承于jdk.internal.loader.BuiltinClassLoader。

       3. 在Java 9中，类加载器有了名称。该名称在构造方法中指定，可以通过getName()方法来获取。平台类加载器的名称是platform，应用类加载器的名称是app。类加载器的名称在调试与类加载器相关的问题时会非常有用。
        4. 启动类加载器现在是在jvm内部和java类库共同协作实现的类加载器(以前是C++实现)，但为了与之前代码兼容，在获取启动类加载器的场景中仍然会返回null，而不会得到BootClassLoader实例。
5.类加载的委派关系也发生了变动。
        当平台及应用程序类加载器收到类加载请求，在委派给父加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器完成加载。