JVM之类加载器
一.类加载器总结
ClassLoader即常说的类加载器，其功能是用于从Class文件加载所需的类，主要场景用于热部署、代码热替换等场景。 系统提供3种的类加载器：Bootstrap ClassLoader、Extension ClassLoader、Application ClassLoader
虚拟机设计团队把加载动作放到 JVM 外部实现，以便让应用程序决定如何获取所需的类，JVM 提
供了 3 种类加载器：
1.1 启动类加载器(Bootstrap ClassLoader)
最顶层的加载类，由C ++实现.
负责加载 JAVA_HOME\lib 目录中的，或通过-Xbootclasspath 参数指定路径中的，且被虚拟机认可（按文件名识别，如 rt.jar）的类。
1.2 扩展类加载器(Extension ClassLoader)
负责加载 JAVA_HOME\lib\ext 目录中的，或通过 java.ext.dirs 系统变量指定路径中的类库。
1.3 应用程序类加载器(Application ClassLoader)
负责加载用户路径（classpath）上的类库。
二. 双亲委派
**当一个类收到了类加载请求，他首先不会尝试自己去加载这个类，而是把这个请求委派给父
类去完成，**每一个层次类加载器都是如此，因此所有的加载请求都应该传送到启动类加载其中，
只有当父类加载器反馈自己无法完成这个请求的时候（在它的加载路径下没有找到所需加载的
Class），子类加载器才会尝试自己去加载。
2.1 双亲委派模型的好处
采用双亲委派的一个好处是比如加载位于 rt.jar 包中的类 java.lang.Object，不管是哪个加载
器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载
器最终得到的都是同样一个 Object 对象。
2.2 怎样不使用双亲
我们可以自己定义一个类加载器，然后重载 loadClass() 即可。
2.3 自定义类加载器
除了 顶层BootstrapClassLoader ,其他类加载器均由 Java 实现且全部继承java.lang.ClassLoader。如果我们要自定义自己的类加载器，需要继承 ClassLoader。
三.应用场景
-
Tomcat，类加载器架构，自己定义了多个类加载器，
保证了同一个服务器的两个Web应用程序的Java类库隔离；
保证了同一个服务器的两个Web应用程序的Java类库又可以相互共享；比如多个Spring组织的应用程序不能共享，会造成资源浪费；
保证了服务器尽可能保证自身的安全不受不受部署Web应用程序影响；
支持JSP应用的服务器，大多需要支持热替换(HotSwap)功能。 -
OSGi(Open Service GateWay Initiative)，是基于Java语言的动态模块化规范。已成为Java世界的“事实上”的模块化标准，最为熟悉的案例的Eclipse IDE。