JVM之类加载器

今天我们讲述的是JVM之类加载器：
也就是下图的这一坨！

首先先介绍三种类加载器：
启动（Bootstrap）类加载器
启动类加载器主要加载的是JVM自身需要的类，这个类加载使用C++语言实现的，是虚拟机自身的一部分，它负责将 <JAVA_HOME>/lib路径下的核心类库或-Xbootclasspath参数指定的路径下的jar包加载到内存中，注意必由于虚拟机是按照文件名识别加载jar包的，如rt.jar（想String，等本身就有的类就在这里面），如果文件名不被虚拟机识别，即使把jar包丢到lib目录下也是没有作用的(出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类)。

扩展（Extension）类加载器
扩展类加载器是指Sun公司(已被Oracle收购)实现的sun.misc.Launcher$ExtClassLoader类，由Java语言实现的，是Launcher的静态内部类，它负责加载<JAVA_HOME>/lib/ext目录下或者由系统变量-Djava.ext.dir指定位路径中的类库，开发者可以直接使用标准扩展类加载器。

##系统（System）类加载器
也称应用程序加载器是指 Sun公司实现的sun.misc.Launcher$AppClassLoader。它负责加载系统类路径java -classpath或-D java.class.path 指定路径下的类库，也就是我们经常用到的classpath路径，开发者可以直接使用系统类加载器，一般情况下该类加载是程序中默认的类加载器，通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器。
可以通过下面这段代码理解一下什么时候用的什么加载器：

双亲委派机制：
简单来说就是儿子被打了，找父亲来。

我们定义一个String类，里面写一个main方法，来运行，结果会报错，找不到main方法。
这是为什么呢？？？
因为String本身就是通过启动（Bootstrap）类加载器加载。
那为什么我自己定义的类就不行呢？？
这就用到了双亲委派机制了，

从上往下，现在Bootstrap中找，没找到，接着去扩展找，没找到，就这样，依次往下。
所以我们String既然在Bootstrap中存在，那么我就不需要往下找了，这就是双亲委派机制，自己写的代码不能污染java的源代码，于是实现了沙箱安全。