万万没想到，谷歌竟然也问双亲委派？

小饭饭饭饭饭饭
378 阅读12分钟

前几天H同学和我聊了下去谷歌的面试经验，令我诧异的是，没想到谷歌也问双亲委派模型？？？

熟悉双亲委派模型吗？

熟悉，这题我会。

机会来了，我八股文大神可是专门修炼过这个的。

我们为啥不能在Java工程中定义同名的String的Java文件？

(⊙o⊙)…

这.....

多线程加载类的时候为什么没有线程问题？

卧槽 ....

首先，在讲解这道题之前，先来划重点

类加载时机与过程

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)7个阶段。其中准备、验证、解析3个部分统称为连接（Linking）

加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）

加载

在加载阶段（可以参考java.lang.ClassLoader的loadClass()方法），虚拟机需要完成以下3件事情：

  1. 通过一个类的全限定名来获取定义此类的二进制字节流（并没有指明要从一个Class文件中获取，可以从其他渠道，譬如：网络、动态生成、数据库等）；
  2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；
  3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口；

加载阶段和连接阶段（Linking）的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。

验证

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。验证阶段大致会完成4个阶段的检验动作：

  1. 文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以魔术0xCAFEBABE开头（当class文件以二进制形式打开，会看到这个文件头，cafebabe）、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
  2. 元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外。
  3. 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
  4. 符号引用验证：确保解析动作能正确执行。

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在堆中。其次，这里所说的初始值通常情况下是数据类型的零值，

例如：public static int a = 1

这个时候变量a在准备阶段过后的初始值为0，而不是1，因为这个时候尚未开始执行任何java方法，而把a赋值为1的指令是程序被编译后，存放于类构造器()方法中，所以把a赋值为1的动作将在初始化阶段才执行。

而当：public static final int a = 2

这种情况又不同了，当类字段的属性是ConstantValue时，会在准备阶段初始化为指定的值，所以标志位final之后，a的值再准备阶段便被初始化为2，而不再是1 了。

划重点：这里其实也好理解，final标志的常量意味着是不变的，那么在准备阶段直接赋值了就可以了，没必要多此一举，先赋初始值，再在初始化的时候额外再做一次。

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。

初始化

在介绍初始化时，要先介绍两个方法：<clinit> 和 <init>:

  • 在编译生成class文件时，会自动产生两个方法，一个是类的初始化方法, 另一个是实例的初始化方法
  • <clinit>：在jvm第一次加载class文件时调用，包括静态变量初始化语句和静态块的执行
  • <init>: 在实例创建出来的时候调用，包括调用new操作符；调用 Class 或 Java.lang.reflect.Constructor 对象的newInstance()方法；调用任何现有对象的clone()方法；通过 java.io.ObjectInputStream 类的getObject() 方法反序列化。

类初始化阶段是类加载过程的最后一步，到了初始化阶段，才真正开始执行类中定义的java程序代码。在准备阶段、变量已经被赋值过一次系统要求的初始值，而在初始化阶段，则根据开发人员通过程序去初始化类变量和其他资源，或者说：初始化阶段是执行类构造器<clinit>()方法的过程.

<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块 static{} 中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。

虚拟机规范严格规定了有且只有5中情况（jdk1.7）必须对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

  • 遇到 new, getstatic, putstatic, invokestatic 这些字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译器把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
  • 使用 java.lang.reflect 包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
  • 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
  • 当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
  • 当使用jdk1.7动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果REF_getstatic, REF_putstatic, REF_invokeStatic 的方法句柄，并且这个方法句柄所对应的类没有进行初始化，则需要先出触发其初始化。

有了这个加载规则的印象，双亲委派模型就很好理解了，别着急，继续向下看, 你会发现你的理解层面提高了

总结一大波：其实也这个过程不用记，靠理解最好了，你想想看哦，你要把一个类加载到虚拟机，是不是要有一个加载的过程，这个过程就是将你的class对应的二进制字节流加载到虚拟机中，加载完虚拟机是不是要校验下，规则的你给的东西有没有毒？验证完了，是不是要帮我们把一些类变量设置下初始值？设置完了还有一些对象标志啊什么的，是不是也要帮忙解析成直接引用，最后是不是还要走下我们类的初始化方法。

双亲委派模型

image-20210804222532389

所谓双亲委派是指每次收到类加载请求时，先将请求委派给父类加载器完成（所有加载请求最终会委派到顶层的Bootstrap ClassLoader加载器中），如果父类加载器无法完成这个加载（该加载器的搜索范围中没有找到对应的类），子类尝试自己加载， 如果都没加载到，则会抛出 ClassNotFoundException 异常， 看到这里其实就解释了文章开头提出的第一个问题，父加载器已经加载了JDK 中的 String.class 文件，所以我们不能定义同名的 String java 文件。

这么做的好处是什么?

因为这样可以避免重复加载，当父亲已经加载了该类的时候，就没有必要 ClassLoader 再加载一次。考虑到安全因素，我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义的类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String 已经在启动时就被引导类加载器（Bootstrcp ClassLoader）加载，所以用户自定义的ClassLoader永远也无法加载一个自己写的String，除非你改变 JDK 中 ClassLoader 搜索类的默认算法。

我们发现除了启动类加载器（BootStrap ClassLoader），每个类都有其"父类"加载器，这种组合关系是通过组合模式来决定的，而不是继承关系。

三种类加载器分别职责是啥？

  1. Bootstrap ClassLoader:这个加载器不是一个Java类，而是由底层的c++实现，负责在虚拟机启动时加载Jdk核心类库（如：rt.jar、resources.jar、charsets.jar等）以及加载后两个类加载器。这个ClassLoader完全是JVM自己控制的，需要加载哪个类，怎么加载都是由JVM自己控制，别人也访问不到这个类
  2. Extension ClassLoader:是一个普通的Java类，继承自ClassLoader类，负责加载{JAVA_HOME}/jre/lib/ext/目录下的所有jar包。
  3. App ClassLoader：是Extension ClassLoader的子对象，负责加载应用程序classpath目录下的所有jar和class文件。

通常用这两种方式来动态加载一个 java 类，Class.forName() 与 ClassLoader.loadClass() ，但是两个方法之间也是有一些细微的差别，具体看上一篇文章：mp.weixin.qq.com/s/EKSfiMQjG…

双亲委派模型源码解析

来看看核心loadClass的方法

image-20210804075639756

可以看到方法有同步块（synchronized）, 这样就算多线程情况也不会出现重复加载的情况。

JAVA热部署实现

什么是热部署（hotswap）？

Java 类是通过 Java 虚拟机加载的，某个类的 class 文件在被 classloader 加载后，会生成对应的 Class 对象，之后就可以创建该类的实例，而热部署是在不重启 Java 虚拟机的这一前提下，自动侦测到 class 文件的变化，更新运行时 class 的行为。

而实际上，对于同一个全限定名的java类，只能被加载一次，而且无法被卸载。

那么竟然类无法被卸载，那么能不能把她妈给换了？也就是类加载器，答案是可以的，我们可以自定义类的加载器，并重写ClassLoader的findClass方法，然后热部署步骤就是：

  1. 销毁自定义ClassLoader(被该加载器加载的class也会自动卸载)；
  2. 更新class
  3. 使用新的ClassLoader去加载class

最终落地到实现，其实就是将ClassLoader给覆盖掉，怎么覆盖，重新new一个同样的ClassLoader就可以了。

总结一大波： 我们虽然不能对被加载的class动手动脚，但是却可以对ClassLoader动手脚，搞掉它，然后使用新的ClassLoader加载class就可以了。

那么什么时候回收掉老的类呢？毕竟替换了，就存在新旧问题了，也就存在内存泄露问题了。

通常情况下，在JSP，OSGI及其他一些支持热替换的库，都是需要进行类的卸载回收的，否则类在替换后，老的类就没用了但是还在内存中，就会造成内存泄漏。

类的卸载需要满足以下三个条件:

  • 该类所有的实例都已经被GC，也就是JVM中不存在该Class的任何实例。
  • 加载该类的ClassLoader已经被GC。
  • 该类的java.lang.Class 对象没有在任何地方被引用，如不能在任何地方通过反射访问该类的方法。

所以在自定义类加载器时，就要注意这一点，如果你是希望其使用完成后就被卸载，那么就需要特别留意类加载器及类的作用域了。

最后

想知道前面几道题的标准答案的可以给我文章点个赞哈，然后文章底下评论下，我后面回复下。

avatar
文章
阅读
粉丝