「java的双亲委派」java双亲委派设计模式

本篇文章给大家谈谈java的双亲委派，以及java双亲委派设计模式对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、北大青鸟java培训：创建新对象的两种方式？
• 2、双亲委派机制的优势与劣势
• 3、java类加载为什么采用双亲委派模型
• 4、五、ClassLoader双亲委派加载模式
• 5、java双亲委托机制是什么意思？

北大青鸟java培训：创建新对象的两种方式？

随着互联网编程开发技术的发展，编程开发语言已经由面向程序发展成为了面向对象的编程。

今天，我们就从两个方面来了解一下，java编程语言中如何创建新对象的。

java在new一个对象的时候，会先查看对象所属的类有没有被加载到内存，如果没有的话，就会先通过类的全限定名来加载。

加载并初始化类完成后，再进行对象的创建工作。

我们先假设是一次使用该类，这样的话new一个对象就可以分为两个过程：加载并初始化类和创建对象。

一、类加载过程(一次使用该类)java是使用双亲委派模型来进行类的加载的，所以在描述类加载过程前，我们先看一下它的工作过程：双亲委托模型的工作过程是：如果一个类加载器(ClassLoader)收到了类加载的请求，它先不会自己去尝试加载这个类，而是把这个请求委托给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求终都应该传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求(它的搜索范围中没有找到所需要加载的类)时，子加载器才会尝试自己去加载。

使用双亲委托机制的好处是：能够有效确保一个类的全局性，当程序中出现多个限定名相同的类时，类加载器在执行加载时，始终只会加载其中的某一个类。

1、加载由类加载器负责根据一个类的全限定名来读取此类的二进制字节流到JVM内部，并存储在运行时内存区的方法区，然后将其转换为一个与目标类型对应的java.lang.Class对象实例2、验证格式验证：验证是否符合class文件规范语义验证：检查一个被标记为final的类型是否包含子类;检查一个类中的final方法是否被子类进行重写;确保父类和子类之间没有不兼容的一些方法声明(比如方法签名相同，但方法的返回值不同)操作验证：在操作数栈中的数据必须进行正确的操作，对常量池中的各种符号引用执行验证(通常在解析阶段执行，检查是否可以通过符号引用中描述的全限定名定位到指定类型上，以及类成员信息的访问修饰符是否允许访问等)3、准备为类中的所有静态变量分配内存空间，并为其设置一个初始值(由于还没有产生对象，实例变量不在此操作范围内)被final修饰的static变量(常量)，会直接赋值;4、解析将常量池中的符号引用转为直接引用(得到类或者字段、方法在内存中的指针或者偏移量，以便直接调用该方法)，这个可以在初始化之后再执行。

解析需要静态绑定的内容。

//所有不会被重写的方法和域都会被静态绑定以上2、3、4三个阶段又合称为链接阶段，链接阶段要做的是将加载到JVM中的二进制字节流的类数据信息合并到JVM的运行时状态中。

5、初始化(先父后子)4.1为静态变量赋值4.2执行static代码块注意：static代码块只有jvm能够调用如果是多线程需要同时初始化一个类，仅仅只能允许其中一个线程对其执行初始化操作，其余线程必须等待，只有在活动线程执行完对类的初始化操作之后，才会通知正在等待的其他线程。

因为子类存在对父类的依赖，所以类的加载顺序是先加载父类后加载子类，初始化也一样。

不过，父类初始化时，子类静态变量的值也有有的，是默认值。

终，方法区会存储当前类类信息，包括类的静态变量、类初始化代码(定义静态变量时的赋值语句和静态初始化代码块)、实例变量定义、实例初始化代码(定义实例变量时的赋值语句实例代码块和构造方法)和实例方法，还有父类的类信息引用。

二、创建对象1、在堆区分配对象需要的内存分配的内存包括本类和父类的所有实例变量，但不包括任何静态变量2、对所有实例变量赋默认值将方法区内对实例变量的定义拷贝一份到堆区，然后赋默认值3、执行实例初始化代码初始化顺序是先初始化父类再初始化子类，初始化时先执行实例代码块然后是构造方法4、如果有类似于Childc=newChild()形式的c引用的话，在栈区定义Child类型引用变量c，然后将堆区对象的地址赋值给它需要注意的是，福建IT培训发现每个子类对象持有父类对象的引用，可在内部通过super关键字来调用父类对象，但在外部不可访问

双亲委派机制的优势与劣势

类加载器用来把类加载到Java虚拟机中。从JDK1.2版本开始，类的加载过程采用双亲委派机制，这种机制能更好地保证Java平台的安全。

如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就成功返回。只有父类加载器无法完成此加载任务时，才自己去加载。

规定了类加载器的顺序是：引导类加载器先加载，若加载不到，由扩展类加载器加载，若还加载不到，才会由系统类加载器或自定义的类加载器进行加载。

双亲委派机制在java.lang.ClassLoader.loadClass(String,boolean)接口中体现。该接口的逻辑如下：

（1）先在当前加载器的缓存中查找有无目标类，如果有，直接返回。

（2）判断当前加载器的父加载器是否为空，如果不为空，则调用parent.loadClass(name，false)接口进行加载

（3）反之，如果当前加载器的父类加载器为空，则调用findBootstrapClassOrNull(name)接口，让引导类加载器进行加载。

（4）如果通过以上3条路径都没能成功加载，则调用findClass(name)接口进行加载。该接口最终会调用java.lang.ClassLoader接口的defineClass系列的native接口加载目标Java类。

双亲委派的模型就隐藏在这第2步和第3步中。

假设当前加载的是java.lang.Object这个类，很显然，该类属于JDK中核心得不能再核心的一个类，因此一定只能由引导类加载器进行加载。当JVM准备加载java.lang.Object时，JVM默认会使用系统类加载器去加载，按照上面4步加载的逻辑，在第1步从系统的缓存中肯定查找不到该类，于是进入第2步。由于从系统加载器的父加载器是扩展类加载器，于是扩展类加载器继续从第1步开始重复。由于扩展类加载器的缓存中也一定查找不到该类，因此进入第2步。扩展类的父加载器是null，因此系统调用findClass(String)，最终通过引导类加载器进行加载。

如果在自定义的类加载器中重写java.lang.ClassLoader.loadClass(String)或java.lang.ClassLoader.loadClass(String,boolean)方法，抹去其中的双亲委派机制，仅保留上面这4步中的第1步与第4步，那么是不是就能够加载核心类库了呢？

这也不行！因为JDK还为核心类库提供了一层保护机制。不管是自定义的类加载器，还是系统类加载器抑或扩展类加载器，最终必须调用java.lang.ClassLoader.defineClass(String,byte[],int,int,ProtectionDomain)方法，而该方法会执行 preDefineClass()接口 ，该接口中提供了对JDK核心类库的保护。

检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。

通常情况下，启动类加载器中的类为系统核心类，包括一些重要的系统接口，而在应用类加载器中，为应用类。按照这种模式， 应用类访问系统类自然是没有问题，但是系统类访问应用类就会出问题。 比如在系统类中提供了一个接口，该接口需要在应用中得以实现，该接口还绑定一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中。这时，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。

由于Java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派机制，只是建议而已。

比如在Tomcat中，类加载器所采用的加载机制就和传统双亲委派模型有一定区别，当缺省的类加载器接收到一个类的加载任务时，首先会由它自行加载，当它加载失败时，首先会由它自行加载，当它加载失败时，才会将类的加载任务委派给它的超类加载器去执行，这同时也是Servlet规范推荐的一种做法。

java类加载为什么采用双亲委派模型

采用双亲委派模型使得java类随着它的类加载器一起具备了一种带有优先级的层次关系。

例如类java.lang.Object，它存放在rt.jar中，无论哪个类加载器要加载这个类，最终都会委派给启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果用户自己写了一个名为java.lang.Object的类，并放在程序的Classpath中，那系统中将会出现多个不同的Object类，java类型体系中最基础的行为也无法保证，应用程序也会变得一片混乱。

五、ClassLoader双亲委派加载模式

获取启动类加载器加载的目录 System.getProperty("sun.boot.class.path");

获取扩展类加载器加载的目录 System.getProperty("java.ext.dirs");

获取应用类加载器加载的目录 System.getProperty("java.class.path");

将test.Test2.class移到启动类加载器加载的目录，然后其加载类

启动类加载器加载目录如下

通过上述案列可以分析出，test.Test2是由启动类加载器加载的，验证了双亲委派优先父加载器加载

通过上述案列得出AESKeyGenerator是由扩展类加载器加载的，手动修改扩展类加载器加载的目录,修改完成后在修改后的目录是找不到AESKeyGenerator，所以会报错

java -Djava.ext.dirs=./ test.Test19

将本地目录作为扩展类加载器加载的目录

同一个命名空间内的类时相互可见的

子加载器的命名空间包含所有的父加载器的命名空间。因此由子加载器加载的类可以看见父加载器加载的类。例如系统类加载器加载的类能看见跟类加载器加载的类。

由父加载器加载的类不能看见子加载器加载的类。

如果两个加载器之间没有直接或者间接的父子关系，那么它们各自加载的类相互不可见

上述案列是因为classLoader1与classLoader2的父加载器都为AppClassLoader，所以classLoader1加载完Person后在内存的缓存中是有Person.class的，classLoader2委托AppClassLoader加载的时候直接就从内存中获取Person.class，所以他们是一致的，method方法也是可以执行的

当删除当前classpath下的Person.class文件，将Person.class文件移到D盘下

此时当前的classPath下没有Person.class文件，会分别由classLoader1加载器与classLoader2加载器加载，会存在classLoader1加载器的命名空间以及classLoader2加载器的命名空间，根据  如果两个加载器之间没有直接或者间接的父子关系，那么它们各自加载的类相互不可见 的规则那么classLoader1与classLoader2加载的类时相互不可见的也是不相同的，这里会有很有趣的问题  java.lang.ClassCastException: test.Person cannot be cast to test.Person

修改扩展类加载路劲为当前路径

执行 java -Djava.ext.dirs=./ test.Test22

可以发现还是使用AppClassLoader加载的Test22以及Test1

扩展类加载器不能直接加载.class文件，需要将.class文件打成jar包

jar cvf test.jar test/Test1.class

再次执行 ，可以发现Test1是通过扩展类加载器加载的，因为此处只将Test1打成jar包了

1. 可以确保java核心库的类型安全: 例如所有的JAVA应用都至少会引用java.lang.Object类，也就是说在jvm的运行期间,java.lang.Object类会被加载到java虚拟机中,如果这个过程是由自己定义的java类加载器完成的,那么很有可能在jvm中存在多个版本的java.lang.Object类，也就是说在jvm的运行期间而这些类之间是相互不兼容的(命名空间不同导致的)。

借助双亲委派机制,java核心类库的加载必须由启动类加载器加载,从而确保java中使用的核心类库的版本统一，他们之间是相互兼容的

2. 可以保证java核心类库加载的类不会被自定义类所替代。

3. 不同类的加载器可以为相同名称的类(binary name)创建额外的命名空间。相同名称的类可以并存与不同命名空间的内存中，不同类加载器加载的类之间是相互不兼容的就相当于在java虚拟机内部创建了一个又一个相互独立并且隔离的的java空间,这类技术在很多框架都得到了使用。

在运行期间，一个Java类是由该类的完全限定名(binary name,二进制名)和用于加载该类的定义类加载器(defining loader)所共同决定的。如果同样名字(即相同的限定名)的类是由两个不同的加载类所加载，那么这些类就是不同的，即便.class文件的字节码完全一样，并且从相同的位置加载也是如此。

在Oracle的Hotspot实现中，系统属性 sun.boot.class.path如果被修改错了，则运行会出错，提示如下错误信息:

Error occureed during initialization of VM

java/lang/NoClassDefFoundError: java/lang/Object

内建于JVM中的启动类加载器会加载java.lang.ClassLoader以及其他的java平台类,当JVM启动时，一块特殊的机器码会运行，它会加载扩展类加载器以及系统类加载器，这块特殊的机器码叫做启动类加载器(BootStrap)。启动类加载器并不是java类，而其他的加载器都是java类，启动类加载器是特定于平台的机器指令，它负责开启整个加载过程

所有类加载器(除了启动类加载器)都被实现为Java类。不过总归要有一个组件来加载第一个java类加载器，从而让整个加载过程能够顺利进行，加载第一个纯JAVA类加载器就是启动类加载器的职责。

启动类加载器还会负责加载JRE正常运行时所需的基本组件，这包括java.util与java.lang包中的类等等

java -Djava.system.class.loader=test.Test16 test.Test23

java双亲委托机制是什么意思？

这个机制是 java class loader 范畴的内容。‘

java 虚拟机要将被用到的java类文件通过classLoader 加载到JVM内存中。

首先classloader 分三个级别，最上级 ： bootstrap classLoader 中间级：extension classLoader 最低级 app classLoader.

当需要加载某个类的时候，会看看这个类是否已经被加载了，如果没有，会请求app 级来加载，app 请求 extension 级 extension 请求 bootstrap级， 由最高级来负责加载（这个就是双亲委派，委托 上两级的loader来做加载），如果高级的无法加载 则会将人物返回给 下一级 以此类推 最后如果双亲都不行 就由自己来加载。 为什么要用这个机制？ 比如 java.lang.String 这个类，这个是jdk提供的类， 如果我们自定义个 包名：java.lang 然后在里面创建一个String 类， 当我在用String类的时候，根据前面所说，是由bootstrap级的loader 来进行加载的，这个时候它发现其实已经加载过了jdk的String了，那么就不会去加载自定义的String了，防止了重复加载 也加大了安全性。

纯手打，有问题指正。

java的双亲委派的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java双亲委派设计模式、java的双亲委派的信息别忘了在本站进行查找喔。