JVM的体系结构图
先来看一下JVM的体系结构，如下图：
JVM的位置
JVM的位置，如下图：
JVM是运行在操作系统之上的，与硬件没有直接的交互，但是可以调用底层的硬件，用JIN（Java本地接口调用底层硬件）
JVM结构图中的class files文件
class files文件，是保存在我们电脑本地的字节码文件，.java文件经过编译之后，就会生成一个.class文件，这个文件就是class files所对应的字节码文件，如下图：
JVM结构图中的类加载器ClassLoader的解释
类加载器ClassLoader的作用
类加载器只有一个作用，就是负责把我们本地的.class字节码文件，加载到JVM中，以类模板的形式存在于JVM中。
类加载器加载的.class文件也是有要求的，并不是只要是后缀名为.class的文件，都可以被类加载器加载，这个.class文件的必须是.java文件经过编译后得到的字节码文件，也就是指这个.class文件的开头必须要是cafe babe字符单词，它的内容是经过加密后的二进制文件，但是此二进制使用十六进制表示出来的，如下图：
类加载器ClassLoader只负责加载.class文件，但至于他是否可以运行，由JVM中的执行引擎Excution Engine决定的。
解释：
Car.class是由.java文件编译得来的.class文件，存在本地磁盘。
ClassLoader：类加载器，负责加载并初始化 类文件，得到真正的Class类，即模板。
Car Class：由Car.class字节码文件，通过ClassLoader加载并且初始化得到，这个Car就是当前类的模板，这个Car Class模板就存在方法区。
car1，car2，car3：是由Car模板经过实例化而得，一个模板可以获得多个实例化对象。
拿car1举例，car1.getClass()可以得到模板Car类，Car.getClassLoader()可得到其装载器。
类加载器的种类
一共有四类。
虚拟机自带的加载器：
启动类加载器，也叫根加载器（BootStrap）。由C++编写，程序中自带的类，存储在 $JAVAHOME/jre/lib/rt.jar中，如object类等
扩展类加载器（Extension），Java编写，在我们看到的类路径中，凡是以Javax开头的，都是拓展包，存储在 $JAVAHOME/jre/lib/ext/*.jar 中，为什么会有扩展包？是因为原本的java包中在功能上，不能满足我们了，所以我们就在原本的java包的基础上扩展出了一些新的功能，而形成的新的包就叫做扩展包。
应用程序类加载器（AppClassLoader）,即平时程序中自定义的类 new出来的
用户自定义的加载器：
Java.lang.ClassLoader的子类，用户可以定制类的加载方式，即如果你的程序有特殊的需求，你也可以自定义你的类加载器的加载方式 ，进入ClassLoader的源码，其为抽象类，因此在你定制化开发的时候，需要你定义自己的加载器类来继承ClassLoader抽象类即可，即 MyClassLoader extends ClassLoader
java类的加载机制
首先你需要知道，当java程序需要加载一个类的时候，会去找类加载器，然后找类加载器里面看是否有对应的类模板。
Java的类加载机制，永远是以 根加载器->拓展类加载器->应用程序类加载器 这样的一个顺序进行加载的。什么意思呢？就是如果能在BootStrapClassLoader类加载器的路径下找到对应的类模板，那么就不会再去扩展类加载器ExtensionClassLoader中找对应的类模板，如果能在扩展类加载器ExtensionClassLoader中找到对应的类模板，那么就不会去应用程序类加载器AppClassLoader中找对应的类模板。类加载器的父子级关系，如下图：
从上图可以看出根加载器BootStrapClassLoader是扩展类加载器ExtensionClassLoader的父级，扩展类加载器ExtensionClassLoader是应用程序加载器AppClassLoader的父级，如下图：
被某个类加载器加载的类，都会存放到这个类加载器的路径中，当程序需要加载某个类的时候，会先去根加载器BootstrapClassLoader的路径下，寻找是否有这个类的模板，如果没有则会去这个类加载器的下一级，若有，则不会再去下一级寻找了。
利用obj.getClass().getClassLoader()方法，可以找到对应的类模板是存放在哪个类加载器的路径下的，换一个说法，可以让你知道在加载这个类模板所对应的类的字节码文件的时候，是用的哪一个类加载器把这个类的字节码文件加载成类模板的，如下图：
那么问题来了？为什么说Object类是java自带的类呢？java自带的类到底可以在哪里找到呢？java自带的类可以 J A V A H O M E / j r e / l i b / r t . j a r 下 找 到 。 首 先 来 看 一 下 JAVAHOME/jre/lib/rt.jar下找到。首先来看一下 JAVAHOME/jre/lib/rt.jar下找到。首先来看一下JAVAHOME，也即是java的安装目录，如下图：
然后咱来看一下$JAVAHOME/jre/lib/rt.jar中的包（rt其实也即是RunTime的缩写），如下图：
打开rt.jar压缩包，它的目录结构，如下图：
Object类在java/lang包下，如下图：
JVM中的类加载器，根加载器BootStrap，在一开始，就会把rt.jar压缩包中的所有的 类的字节码文件都加载到JVM中，变成类的模板，所以这些java自带的类，对应的类的模板，都会被存放到根加载器BootStrap的路径下面。故当java程序中需要用到java中的自带类的时候，都会去根加载器BootStrap的路径下去寻找类的模板。
双亲委派机制
官方概念：当一个类收到类加载请求后，他不会首先去加载这个类，而是把这个请求委派给父类去完成。每一个层次的类加载器都是如此，因此所有的类加载器请求都是应该传到根加载器中的，只有当其父类加载器自己无法完成这个请求的时候（在他的加载路径下没有找到所需加载的class），子类加载器才会尝试自己去加载。
我的理解翻译：当java程序需要加载一个类的时候，比如要加载java.lang.String类，会首先去根加载器类BootstrapClassLoader的路径下去寻找，如果在根加载器路径下可以找到java.lang.String类，那么就不会再往下寻找java.lang.String类了，因为已经找到了；若在根加载器路径下没有找到java.lang.String类，则会去下一级扩展类加载器ExtensionClassLoader中寻找java.lang.String类，如果在扩展类加载器中找到了java.lang.String类，那么就不会再去下一级类加载器中寻找了；如果没有找到，则会去应用程序类加载器AppClassLoader中去寻找java.lang.String类，如果仍然没有找到会报classNotFoundException异常。
采用双亲委派机制的好处：保证了我们写的代码不会污染到java的源代码，因为只要java的源代码中存在我们即将要加载的类，那么java程序在加载类的时候就会去顶层的根加载器BootstrapClassLoader路径下去寻找类模板，然后把这个类加载。你就比如假设我们自己写一个java.lang包，然后在这个包里面写一个String类，那么如果java源代码中没有java.lang.String这个类，java程序在用到这个类加载的时候，会用到应用程序类加载器AppClassLoader路径下的java.lang.String类，但是，我们都知道java源代码中是有java.lang.String这个类的，也即是在根加载器BootstrapClassLoader路径下有java.lang.String这个类，所以java程序在用到这个类加载它的时候，会加载根加载器BootstrapClassLoader路径下的java.lang.String类，而不会去加载应用程序类加载器AppClassLoader下的java.lang.String类，这样就保证了，我们在java程序的其它地方所用到的java.lang.String类的方法是正确的，怎么个正确法呢？因为啊，假设你是加载的应用程序加载器AppClassLoader路径里的java.lang.String类也即是你自己写的String类，那么在java程序的其它地方如果使用到了源代码java.lang.String类里面的方法该怎么办？这样是不是会出错？这其实也就是，你写的代码污染了人家写的源代码。
双亲委派机制的程序理解，如下图：
沙箱安全机制
通过双亲委派机制，类的加载永远都是从根加载器开始的，如果跟加载器中没有对应的类模板，则会去下一级类加载器中寻找这个类模板，如果有的话则就不会去下一级寻找了。这样就保证你所写的代码不会污染Java自带的源代码，保证了沙箱的安全。
为什么说这样不会污染java自带的源代码呢？因为只要java的源代码中存在我们即将要加载的类，那么java程序在加载类的时候就会去顶层的根加载器BootstrapClassLoader路径下去寻找类模板，然后把这个类加载。你就比如假设我们自己写一个java.lang包，然后在这个包里面写一个String类，那么如果java源代码中没有java.lang.String这个类，java程序在用到这个类加载的时候，会用到应用程序类加载器AppClassLoader路径下的java.lang.String类，但是，我们都知道java源代码中是有java.lang.String这个类的，也即是在根加载器BootstrapClassLoader路径下有java.lang.String这个类，所以java程序在用到这个类加载它的时候，会加载根加载器BootstrapClassLoader路径下的java.lang.String类，而不会去加载应用程序类加载器AppClassLoader下的java.lang.String类，这样就保证了，我们在java程序的其它地方所用到的java.lang.String类的方法是正确的，怎么个正确法呢？因为啊，假设你是加载的应用程序加载器AppClassLoader路径里的java.lang.String类也即是你自己写的String类，那么在java程序的其它地方如果使用到了源代码java.lang.String类里面的方法该怎么办？这样是不是会出错？这其实也就是，你写的代码污染了人家写的源代码。
总结
到此这篇关于JVM中ClassLoader类加载器的文章就介绍到这了,更多相关JVM中ClassLoader类加载器内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！