《Understanding the JVM》读书笔记之五——类加载器

一、JVM中类唯一性的确认
  对于任意一个类,都需要由加载它的类加载器和这个类本身来确定其在JVM中的唯一性。
即:只有在两个类是由同一个类加载器加载时,才能比较两个类是否相等。

  类相等包括:类的Class对象的equals()方法,isAssignableFrom()方法,isInstance()方法的返回结果,instanceof判定结果等。


二、两种不同的类加载器:
  1. 启动类加载器——C++实现,是JVM自身的一部分。
  2. 所有其他类加载器——Java实现,独立于JVM存在,全都是抽象类java.lang.ClassLoader的子类。
虚拟机提供的3中类加载器:
    1. 启动类加载器(Bootstrap ClassLoader):
      • 负责加载\lib目录中的类或被参数-Xbootclasspath参数指定的路径中的类(这些类一定要能被JVM识别)。
      • 在定义自己的类加载器时,如果需要把加载请求委托给启动类加载器,直接用null代替即可。
    2. 扩展类加载器(Extension ClassLoader):
      • 负责加载\lib\ext目录中的类或被java.ext.dirs系统变量所指定的路径中的所有类库。
    3. 应用程序类加载器(Application ClassLoader):
      • 负责加载用户路径(ClassPath)上所指定的类库,如果程序中没有自定义过自己的类加载器,默认为应用程序类加载器
      • 这个类加载器是ClassLoader类中的getSystemClassLoader()方法的返回值,也称为“系统类加载器”。


三、双亲委派模型:

  《Understanding the JVM》读书笔记之五——类加载器_第1张图片
  这里的类加载器之间的父子关系不通过继承实现,而是使用组合关系来复用父加载器的代码。
双亲委派模型的工作机制:
  • 一个类加载器收到了类的加载请求,会先把这个请求委托给父类加载器去完成,每一层的类加载器如此。
  • 所有的加载请求都会传送到顶层的启动类加载器,只有当父加载器无法完成这一请求时,子类加载器才会尝试自己去加载。
  **这种机制保证了Object类在程序的各种类加载器中都是同一个类,如果没有双亲委派,用户自己编写一个java.lang.Object类,并放到ClassPath路径中,那么系统中会出现多个不同的Object类,Java体系则被破坏。


四、破坏双亲委派模型的方式:
  1. 重写loadClass()方法
  2. 通过Thread类的setContextClassLoader()方法设置线程上下文类加载器
  3. OSGI技术
    • 双亲委派的具体逻辑都子啊loadClass()方法中实现,修改了loadClass()方法也就修改了双亲委派模型。
    • Thread Context Class Loader线程上下文类加载器,如果线程创建时未设置此加载器,则会在父线程中继承一个,默认时应用程序类加载器。可以实现JavaAPI对用户代码的调用操作。
    • OSGI用于实现代码的热替换、模块热部署等操作,当收到类加载请求时,OSGI按如下顺序进行搜索(只有前两种情况符合双亲委派):
      a. 将java.*开头的类委托给父类加载器加载;
      b. 将委派列表名单中的类委派给父类加载器加载;
      c. 将Import列表中的类委派给Export这个类的Bundle的类加载器加载;
      d. 查看当前Bundle的ClassPath,使用自己的类加载器加载;
      e. 查找类是否在自己的FragmengBundle中,如果在,委托给FragmentBundle的类加载器加载;
      f. 查找DynamicImport列表的Bundle,委派给对应的Bundle的类加载器加载
      g. 都不存在,则失败。

转载于:https://www.cnblogs.com/logic-hatten/p/11327099.html

你可能感兴趣的:(《Understanding the JVM》读书笔记之五——类加载器)