jvm专题(1）：类加载机制，类加载器讲解,自定义类加载器的应用

以下知识点如有不同意见或者觉得个人讲错了的，欢迎留言纠正，共同进步，我将不胜感激！

类加载的流程图

类加载器与双亲委派机制

类加载器：

启动类加载器（引导类加载器）（BootstrapClassLoader）：负责加载jvm运行的处于jre/lib目录下的核心库，如rt.jar,charsets.jar等以java.*开头的类文件

扩展类加载器（ExtClassLoader）：负责加载位于jre/lib/ext目录下的扩展库jar包，以javax.*开头的类文件

应用程序类加载器（AppClassLoader）：负责加载项目classpath目录的class类文件

自定义类加载器：负责加载用户自定义目录下的类文件

jvm最开始运行的时候只会加载应用程序运行必须的类，其他类只有等程序用到的时候才加载，减少因为加载了无用的类而导致耗费了宝贵了内存空间。
一般以下情况会去加载类：
new一个对象；
读取或者设置一个类的静态字段；
调用类的静态方法的时候；
一般一个类加载的时候把其父类一起加载！！

双亲委派机制

双亲委派机制流程图如下：

双亲委派机制的大致流程：加载一个类时先委托当前类加载器的父类加载器加载，父类加载器又委托更上一层的父类加载该类，如果父类加载器在自己的加载目录下找不到对应的类进行加载，那么又自上而下加载用子类加载器进行加载，说白了就是先给父亲加载，父亲不行了再由儿子加载，这个地方有一个概念需要明确，一个类加载器的父类不是说它继承了父加载器，而是在ClassLoader类中有一个parent属性来维护当前类加载器对应的父加载器
说明：所有的类加载器都需要继承classLoader这个类

双亲委派的作用
1.沙箱安全机制：为了防止核心库里面的类文件被篡改，如果打破了双亲委派机制的情况下需要核心库的类文件依旧需要采用双亲委派机制，不然会报错
2.避免类的重复加载，提高我们的效率

双亲委派机制的核心代码：
jvm的底层是由c++实现，当程序启动的时候，操作系统会调用jvm.dll文件创建jvm，创建一个启动类加载器的实例，然后会去调用java类Launcher 的静态方法getLauncher()，这个时候就会创建出extClassLoader与appclassLoader

委派的过程源码（ClassLoader类中的loadClass（）方法）

全盘委托机制：一般一个类加载器一个类的时候，如果这个类有其他类的引用，那么其他类也用当前的类加载器来加载，这个机制对于我们后面进行自定义类加载器非常重要

打破双亲委派机制

我们试想一下同一个tomcat下能够运行多个java项目，项目A采用的架构是spring4，B项目采用的是spring5，那么以我们上面对类加载机制的了解，相同全限定名的类应该只会被加载一次，如果在当前tomcat就有大问题了，相同路径下的类要是spring4里面有一个getName方法，但是spring5可能因为其他原因取消了该方法，那么要是类加载器先去加载到了spring5里面的类，那么A项目在使用getName的时候就没有当前方法，这不是就出大问题了么？怎么办呢？

为什么需要打破双亲委派机制：
为了程序员能够更好的在实际应用中控制类的一个记载过程，解决以上提出的问题，比如如何实现类的隔离加载，如何实现java的热部署？如何实现热加载？那么这些实现都需要打破传统的双亲委派机制

如何打破双亲委派机制：自定义类加载器

普通的两个测试类，正常情况下他们会被AppclassLoader加载

测试我们自定义的类加载器

来看看结果：

自定义加载器制作成功，以上就在关于类加载过程与加载器的相关知识，后期针对自定义类加载器，还会出类隔离加载的实现，热部署等，敬请期待！