父母委托机构的优势和劣势父母委托机构的优势避免了类的重复加载，确保一个类的全局唯一性Java类与其类加载器一起具有有优先级的层级关系，这样的
层次关系可以避免类的重复加载，如果父亲已经加载了该类，则不需要子级
类加载器将再次加载
父母委托机制可确保程序安全，防止核心API随意篡改代码，该机制嵌入到Java.lang.class loader.load class (string，boolean )接口中
接口的逻辑如下。
首先检查当前加载器的缓存中是否存在目标类，如果有，则直接返回
确定当前加载器的父加载器是否为空，如果不为空，则调用
parent.loadclass(name，false )接口与加载相反，如果当前加载器的父加载器为空，则调用
findbootstrapclassornull(name )接口、引导类加载器加载如果在上述三个路径之一中加载失败，则调用findclass接口
公路。 该接口最终显示了java.lang.ClassLoader接口的defineClass系列的
native接口加载目标Java类
父母委托的模型隐藏在步骤2和步骤3中。 例如，假设当前加载了一个名为java.lang.Object的类，它显然属于JDK的核心
因为心是不能再核心的类，所以只有引导类加载器才能加载。 以JVM为基准
如果要加载java.lang.Object，请按照JVM 默认会使用系统类加载器去加载，上的5进行操作
步骤2进行步骤加载的逻辑，因为在步骤1一定从系统类的缓存中找不到该类
舞步。 由于来自系统类加载器的父类加载器是扩展类加载器，因此扩展类加载器将继续
从第一步开始重复。 在扩展类加载器的缓存中也找不到类，因此进入
第二步。 因为扩展类的父加载器为空，所以系统调用find class (字符串)并最终通过
引导加载器加载
是否加载了父母委托机制弊端检验类的委托过程为单向的， 这个方式虽然从结构上说比较清晰，
明确各个类加载器的作用，但同时也是一个问题，即顶级的
ClassLoader无法访问底层ClassLoader加载的类
启动类加载器类通常是包含重要系统接口的系统核心模量。
在APP应用程序类加载器中，它是一个APP应用程序类。 在该模型中，APP应用系统当然不会访问系统系统
有问题，但是当系统类访问APP应用程序类时会出现问题。 例如，它为系统类提供了连接
端口。 此接口必须在APP应用程序类中实现。 它还绑定了用于创建此接口的工厂方法
的实例。 接口和工厂方法都在启动类加载器中。 于是，那个工厂方面出现了
方法无法创建由APP应用程序类加载器加载的APP应用程序实例