类加载、类加载器

「已注销」

于 2021-01-05 20:36:37 发布

阅读量97

点赞数

分类专栏： jvm（java虚拟机）

本文链接：https://blog.csdn.net/qq_45385905/article/details/112249049

版权

jvm（java虚拟机）专栏收录该内容

4 篇文章 0 订阅

订阅专栏

类加载机制

JVM把class文件加载到内存，并对数据进行校验、解析和初始化，最终形成
JVM可以直接使用的Java类型的过程。

类的加载过程

去水映

加载：将类名下的字节码文件加载进虚拟机（VM），并存储在方法区，并转换成java.lang,class对象实例；
链接：将Java类的二进制代码合并到JVM的运行状态之中的过程
详细分为3步：
1.验证：确保加载的类信息符合JVM规范，没有安全方面的问题；
2.准备：为类中静态变量(static变量)都赋初始值，final直接赋值，这些内存都将在方法区中进行分配；
3.解析：将虚拟机常量池(也在方法区)中的符号引用转为直接引用；
初始化：a.为静态变量赋值;b.执行static代码块(类的加载顺序是先加载父类后加载子类,且static静态代码块和静态变量和类一样最先加载)；

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

java.class.ClassLoader类

作用：

– java.lang.ClassLoader类的基本职责就是根据一个指定的类的名称，
找到或者生成其对应的字节代码，然后从这些字节代码中定义出一个
Java 类，即 java.lang.Class类的一个实例。
– 除此之外，ClassLoader还负责加载 Java 应用所需的资源，如图像文
件和配置文件等。

类加载器的层次结构(树状结构)

引导类加载器（bootstrap class loader）/启动类加载器
– 它用来加载 Java 的核心库(JAVA_HOME/jre/lib/rt.jar,或sun.boot.class.path路径下的内容)，是用原生代码来实现的，并不继承自 java.lang.ClassLoader。
– 加载扩展类和应用程序类加载器。并指定他们的父类加载器。
扩展类加载器（extensions class loader）
– 用来加载 Java 的扩展库(JAVA_HOME/jre/ext/*.jar，或java.ext.dirs路径下的内容) 。Java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java类。
– 由sun.misc.Launcher$ExtClassLoader实现
应用程序类加载器（application class loader）/系统类加载器
– 它根据 Java 应用的类路径（classpath，java.class.path 路径下的内容）来加载 Java 类。一般来说，Java 应用的类都是由它来完成加载的。
– 由sun.misc.Launcher$AppClassLoader实现
自定义类加载器
– 开发人员可以通过继承 java.lang.ClassLoader类的方式实现自己的类加载器，以满足一些特殊的需求。

类加载器的代理模式----双亲委托机制

代理模式

– 交给其他加载器来加载指定的类

双亲委托机制

某个特定的类加载器在接到加载类的请求时，
——首先将加载任务委托给父类加载器，依次追溯(逐级向上)，直到最高的爷爷辈-引导类加载器
——如果父类加载器可以完成类加载任务，就成功返回；
——当父类加载器无法完成此加载任务时，才尝试逐级向下去加载。
双亲委托机制是为了保证 Java 核心库的类型安全。
这种机制保证了不会出现用户自己能定义java.lang.Object类的情况。
类加载器除了用于加载类，也是安全的最基本的屏障

特别说明：

双亲委托机制是代理模式的一种
并不是所有的类加载器都采用双亲委托机制。
例如：tomcat服务器类加载器也使用代理模式，所不同的是它是首先尝试去加载某个类，如果找不到再代理给父类加载器。这与一般类加载器的顺序是相反的

自定义类加载器

自定义类加载器的流程：

1、首先检查请求的类型是否已经被这个类装载器装载到命名空间中了，如果已经装载，直接返回；否则转入步骤2
2、委派类加载请求给父类加载器（更准确的说应该是双亲类加载器，真个虚拟机中各种类加载器最终会呈现树状结构），如果父类加载器能够完成，则返回父类加载器加载的Class实例；否则转入步骤3
3、调用本类加载器的findClass（…）方法，试图获取对应的字节码，如果获取的到，则调用defineClass（…）导入类型到方法区；如果获取不到对应的字节码或者其他原因失败，返回异常给loadClass（…）， loadClass（…）转抛异常，终止加载过程（注意：这里的异常种类不止一种）。

注意：
被两个类加载器加载的同一个类，JVM不认为是相同的类

线程上下文类加载器

先来看：双亲委托机制以及默认类加载器的问题

一般情况下, 保证同一个类中所关联的其他类都是由当前类的类加载器所加载的。
比如，ClassA本身在Ext下找到，那么他里面new出来的一些类也就只能用Ext去查找了（不会低一个级别），所以有些明明App可以找到的，却找不到了。
JDBC API，他有实现的driven部分（mysql/sql server），我们的JDBC API都是由Boot或者Ext来载入的，但是JDBC driver却是由Ext或者App来载入，那么就有可能找不到driver了。在Java领域中，其实只要分成这种Api+SPI（Service Provide Interface，特定厂商提供）的，都会遇到此问题。
常见的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。这些 SPI 的接口由 Java 核心库来提供，如 JAXP 的 SPI 接口定义包含在 javax.xml.parsers 包中。SPI 的接口是 Java 核心库的一部分，是由引导类加载器来加载的;SPI 实现的Java 类一般是由系统类加载器来加载的。引导类加载器是无法找到 SPI 的实现类的，因为它只加载 Java 的核心库。

再来看：通常需要动态加载资源的时候 , 至少有三个 ClassLoader 可以选择

1.系统类加载器或叫作应用类加载器 (system classloader or application classloader)
2.当前类加载器
3.当前线程类加载器

正文：当前线程类加载器(即线程上下文类加载器)

作用：
是为了抛弃双亲委派加载链模式

说明：

每个线程都有一个关联的上下文类加载器。
如果你使用new Thread()方式生成新的线程，新线程将继承其父线程的上下文类加载器。
如果程序对线程上下文类加载器没有任何改动的话，程序中所有的线程将都使用系统类加载器作为上下文类加载器

TOMCAT服务器的类加载机制

一切都是为了安全！
——TOMCAT不能使用系统默认的类加载器。
• 如果TOMCAT跑你的WEB项目使用系统的类加载器那是相当危险的，你可以直接是无忌惮是操作系统的各个目录了。
• 对于运行在 Java EE™容器中的 Web 应用来说，类加载器的实现方式与一般的 Java 应用有所不同。
• 每个 Web 应用都有一个对应的类加载器实例。该类加载器也使用代理模式(不同于前面说的双亲委托机制)，所不同的是它是首先尝试去加载某个类，如果找不到再代理给父类加载器。这与一般类加载器的顺序是相反的。但也是为了保证安全，这样核心库就不在查询范围之内。
为了安全TOMCAT需要实现自己的类加载器。
• 我可以限制你只能把类写在指定的地方，否则我不给你加载！