类加载器

Java程序可以通过类加载器来达到通过一个类的全限定类名来获取该类的二进制字节流。

类与类加载器

对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器都拥有一个独立的类名称空间。即时这两个类

双亲委派模型

三层类加载器：

• 启动类加载器(Bootstrap Class Loader)：负责加载\lib目录下面或者-Xbootclasspath参数指定的路径下存放的类库。启动类加载器无法被Java程序直接引用。
• 扩展类加载器(Extension Class Loader)：扩展Java SE功能的类库可以放在ext目录下面，由该加载器加载。这种加载器被模块化系统取代，开发者可以直接使用扩展类加载器加载Class文件
• 应用程序类加载器(Application Class Loader)：用来加载用户类路径下面的所有类库，如果应用程序中没有自定义过自己的类加载器，这个就是程序中默认的类加载器。

除此之外，用户还可以自定义类加载器来实现特定功能

双亲委派模型要求除了顶层启动类加载器以外，所有类加载器都应有自己的父类加载器。

双亲委派模型的工作流程：如果一个类加载器受到了类加载请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载去完成。

这个模型保证了一些底层类如Object是被同一个类加载器——启动类加载器加载的，避免出现多个重名但是被虚拟机认为不同类的情况的出现。保证了Java虚拟机的稳定运行。

破坏双亲委派模型

当一些标准服务类(由启动类加载器加载)需要调用用户代码的时候，启动类加载器是无法得知这些应用程序中的接口代码的，这时只能通过线程上下文类加载器来由上层逆向调用下层的代码。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果线程还未设置，他将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认的是应用程序类加载器。

后来在OSGI的环境下面，类加载器不再使用双亲委派模型，而是更加复杂的网状结构