双亲委派模型
双亲委派模型的工作流程：
当类加载器接收到类加载的请求时，它不会自己去尝试加载这个类，而是把这个请求委派给父加载器去完成，每一个层次的类加载器都是如此，因此所有的请求最终都应该传送到启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求(它的搜索范围内没有找到所需的类)时，子加载器才会尝试自己去加载。
优点：java类随着它的类加载器一起具备了一种带有优先级的层次关系。
举例：比如我们要加载java.lang.Object，它存放在rt.jar中，无论哪个类加载器要加载换个类，都会委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类(上面提到了如何比较俩个类是否’相等’)。相反，如果没有双亲委派模型，那么各个类加载器都去自行加载的话，那么在程序中就会出现多个Object类，导致应用程序一片混乱。
双亲委派模型的实现
protected synchronized Class
loadClass(String name, Boolean resolve) throws ClassNotFoundException{ //首先检查请求的类是否已经被加载过 Class c = findLoadedClass(name); if(c == null){ try{ if(parent != null){ //委派父类加载器加载 c = parent.loadClass(name, false); } else{ //委派启动类加载器加载 c = findBootstrapClassOrNull(name); } }catch(ClassNotFoundException e){ //父类加载器无法完成类加载请求 } if(c == null){ //本身类加载器进行类加载 c = findClass(name); } } if(resolve){ resolveClass(c); } return c;}
双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。不过这里类加载器之间的父子关系一般不是以继承(Inheritance)的关系来实现的，而是通常使用组合(Composition)关系来复用父加载器的代码。
双亲委派模型的破坏
JDK12才有双亲委派模型，面对已经存在的用户自定义类加载器的代码，为了兼容这些已有代码，无法再以技术手段避免loadClass()被子类覆盖的可能性，只能在JDK 1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码。
由这个模型自身的缺陷导致的，如果有基础类型又要调用回用户的代码。
由于用户对程序动态性的追求而导致的，这里所说的“动态性”指的是一些非常“热”门的名词：代码热替换(Hot Swap)、模块热部署(HotDeployment)等
OSGi实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块(OSGi中称为Bundle)都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构
Java模块化系统
在JDK 9中引入的Java模块化系统(Java Platform Module System，JPMS)是对Java技术的一次重要升级，为了能够实现模块化的关键目标——可配置的封装隔离机制，Java虚拟机对类加载架构也做出了相应的变动调整，才使模块化系统得以顺利地运作。