JVM 类加载子系统

此一别终不见

已于 2022-03-28 21:33:56 修改

阅读量1k

点赞数 1

分类专栏： JVM 文章标签： java

于 2022-03-20 17:59:35 首次发布

本文链接：https://blog.csdn.net/qianqia_n/article/details/123611540

版权

JVM 专栏收录该内容

24 篇文章 1 订阅

订阅专栏

jvm执行简图：

类加载子系统

作用：负责从文件系统或在网络中加载class文件，class文件开头有特定的标识
class loader只负责加载class文件，至于文件是否可以执行由Execution Engine(执行引擎:解释器、JIT、GC)决定。加载的类信息保存在方法区中，除了类信息外，方法区还会存放运行时常量池信息
阶段：加载(引导类加载器、扩展类加载器、系统类加载器、自定义加载器)->链接(验证、准备、解析)->初始化

每个阶段的详细操作

加载：
1、通过类的全限定名获取定义此类的二进制字节流
2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
3、在内存中生成一个class对象(保存在堆中)，作为方法区这个类的各种数据的访问入口
链接：
1、验证：
确保加载的class文件的字节流中包含的信息符合当前虚拟机的要求，保证加载类
                        的正确性，主要包括四种验证：文件格式验证、元数据验证、字节码验证、符合引
                        用验证。比如class文件头部的CA FE BA BE
2、准备：
为类变量分配内存空间并且设置该类型变量的默认初始值(如int 赋值为0)，真正的赋具体值动作在初始化的clinit()方法中。
这里不包含使用final修饰的static，因为final在编译的时候就会分配，准备阶段会显
                        示的初始化(赋值具体的值)。不会为实例变量分配初始化。实例变量是随着对象实例化一起分配到java堆中
                        从概念上讲，这些变量所使用的内存都应当在方法区中进行分配，但必须注意到方法区本身是一个逻辑上的区域，在JDK 7及之前，HotSpot使用永久代来实现方法区时，实现是完全符合这种逻辑概念的；而在JDK 8及之后，类变量则会随着Class对象一起存放在Java堆中，这时候“类变量在方法区”就完全是一种对逻辑概念的表述了

3、解析
                        将常量池内的符号引用转换为直接引用的过程事实上。
                        解析操作往往会伴随着JVM在执行完初始化之后再执行。
                        符号引用就是一组符号来描述所引用的目标符号引用的宇面量形式明确定义在
                        《java虛拟机规范》的Class文件格式中。直接引用就是直接指向目标的指针、相
                        对偏移量或一个间接定位到目标的句柄。
                        解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等
                        所有方法调用的目标方法在Class文件里面都是一个常量池中的符号引用，在类加载的解析阶段，会将其中的一部分符号引用转化为直接引用，这种解析能够成立的前提是：方法在程序真正运行之前就有一个可确定的调用版本，并且这个方法的调用版本在运行期是不可改变的。换句话说，调用目标在程序代码写好、编译器进行编译那一刻就已经确定下来。这类方法的调用被称为解析（Resolution）。
                        在Java语言中符合“编译期可知，运行期不可变”这个要求的方法，主要有静态方法和私有方法两大类，前者与类型直接关联，后者在外部不可被访问，这两种方法各自的特点决定了它们都不可能通过继承或别的方式重写出其他版本，因此它们都适合在类加载阶段进行解析。
                        只要能被invokestatic和invokespecial指令调用的方法，都可以在解析阶段中确定唯一的调用版本，Java语言里符合这个条件的方法共有静态方法、私有方法、实例构造器、父类方法4种，再加上被final修饰的方法（尽管它使用invokevirtual指令调用），这5种方法调用会在类加载的时候就可以把符号引用解析为该方法的直接引用。这些方法统称为“非虚方法”（Non-Virtual Method），与之相反，其他方法就被称为“虚方法”（Virtual Method）。
初始化：
                初始化阶段就是执行类构造器方法<clinit>()的过程。
                此方法不需定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块
                中的语句合并而来。如果类中没有相应操作就不会生成clinit()方法。
                构造器方法中指令按语句在源文件中出现的顺序执行

                <clinit>()不同于类的构造器（关联：构造器是虚拟机视角下的<init>）
                若该类具有父类，JVM会保证子类的<Clinit>()执行前，父类的<Clinit>()己经执行完毕。
                虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁。

类加载器的类别以及使用

类加载器分成：引导类加载器和自定义类加载器，从概念上来讲用户自己编写的类加载器属于自定义类加载器。但是jvm规范中将所有派生(其实就是继承)于抽象类ClassLoader的类划分为自定义类加载器
常见的类加载器就3种

注意：引导类加载器(启动类加载器)、扩展类加载器、系统类加载器并不是继承关系，而是包含关系。其中Bootstrap是使用c/c++编写的。

// 系统类加载器
ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
// 扩展类加载器
ClassLoader extClassLoader = systemClassLoader.getParent();
// 引导类加载器
ClassLoader bootstrapClassLoader = extClassLoader.getParent();

每种加载器加载的类：
启动类加载器：
使用c/c++实现，嵌套在jvm内部
用来加载java的核心库(JAVA_HOME/jre/lib/rt.jar、resoirces.jar或sun.boot.class.path路径下的内容)，用于提供jvm自身需要的类。不继承于ClassLoader，没有父类加载器
加载扩展类加载器和系统类加载器，并指定为他们的父加载器
只加载java、javax、sum等开头的类
扩展类加载器：
由sum.misc.Launcher$ExtCalssLoader实现
继承于Classloader类
从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的jre/lib/ext子目录(扩展目录)下加载类库，如果用户创建的JAR放在此目录下，也会由扩展类加载器加载。
系统类加载器：
由sum.misc.Launcher$AppClassLoader实现
父加载器是扩展类加载器(扩展类加载器和系统类加载器不是继承关系，二者都是Launcher内部类)
继承ClassLoader类
负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
是程序中默认的类加载器，一般来说java应用的类都是由它来加载
用户自定义类加载器：
为什么要自定义类加载器
隔离加载类：比如中间件和框架的jar包，防止类冲突
修改类加载的方式
扩展加载源
防止源码泄露(加密)
实现步骤
通过继承ClassLoader类，JDK1.2之后推荐把自己的类加载逻辑写在findClass()方法，如果没有复杂的要求也可以继承URLClassLoader类，这样就可以不用实现findClass()以及获取字节码流的方式
重写findClass()、把根据指定的路径以二进制流的方式读到内存以byte[]数组的形式(如果需要解密也是在这一步)，再结合defindClass()方法返回类对象

ClassLoader类的常用方法
ClassLoader是一个抽象类，所有的类加载器都继承于它(除了启动类加载器)

获取Classloader的途径

双亲委派机制

java虚拟机对于class采用的是按需加载的方式，即需要使用到该类的时候才会将它的class文件加载到内存生成class对象，在加载这个类的时候java虚拟机采用的就是双亲委派模式，即把请求交给父类加载器处理，是一种委派模式。

工作原理
1、如果一个类加载器收到了类加载请求，它不会自己去加载，而是去找它的父类加载器，委托父加载器去加载这个类
2、如果父类加载器还有父类，那么会再次向上委托，直到启动类加载器
3、如果需要加载的类在父类加载器的加载范围即父类加载器可以完成加载(再次复习每个类加载器的加载范围)，就成功返回。如果父类加载器无法完成加载，那么就交给子类加载器去加载，子类加载器看是否可以加载，如果不行就再次交给子类加载器。

双亲委派机制的优势
1、避免类的重复加载
2、保证程序安全，防止核心API被篡改(所有的类都是先由父类加载器看是否能加载)

线程上下文类加载器(ContextClassLoader)：
        ContextClassLoader其实只是一个概念
线程上下文类加载器的产生原因：
        java 提供了很多服务提供者接口（Service Provider Interface，SPI），允许第三方为这些接口提供实现。常见的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。
        这些 SPI 的接口由 Java 核心库来提供，而这些 SPI 的实现代码则是作为 Java 应用所依赖的 jar 包被包含进类路径（CLASSPATH）里。SPI接口中的代码经常需要加载具体的实现类。并且我们知道一个类由类加载器A加载,那么这个类依赖类也应该由相同的类加载器加载.那么问题来了，引导类加载器无法找到 SPI 的实现类的，因为它只加载 Java 的核心库。它也不能代理给系统类加载器，因为它是系统类加载器的祖先类加载器。也就是说，双亲委派模型无法解决这个问题。
线程上下文类加载器的作用：
        ContextClassLoader的作用都是为了破坏Java类加载委托机制，使程序可以逆向使用类加载器。
        比如：SPI的接口是Java核心库的一部分，是由引导类加载器(Bootstrap Classloader)来加载的；SPI的实现类是由系统类加载器(System类加载器)来加载的。
线程上下文类加载器的使用：
        线程上下文类加载器（context class loader）是从 JDK 1.2 开始引入的。
        类 java.lang.Thread中的方法 getContextClassLoader()和 setContextClassLoader(ClassLoader cl)用来获取和设置线程的上下文类加载器。
        如果没有通过 setContextClassLoader(ClassLoader cl)方法进行设置的话，Thread默认集成父线程的 Context ClassLoader（注意，是父线程不是父类）。如果你整个应用中都没有对此作任何处理，那么所有的线程都会以System ClassLoader作为线程的上下文类加载器。在线程中运行的代码可以通过此类加载器来加载类和资源。
在实际使用时一般都用下面的经典结构: （获取-使用-还原）

ClassLoader targetClassLoader = null;// 外部参数

ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
try {
    Thread.currentThread().setContextClassLoader(targetClassLoader);
    // TODO
} catch (Exception e) {
    e.printStackTrace();
} finally {
    Thread.currentThread().setContextClassLoader(contextClassLoader);
}

首先获取当前线程的线程上下文类加载器并保存到方法栈,然后将外部传递的类加载器设置为当前线程上下文类加载器
doSomething则可以利用新设置的类加载器做一些事情
最后在设置当前线程上下文类加载器为老的类加载器

沙箱安全：

类的主动使用和被动使用

在jvm在表示两个class对象是否为同一个类有两个必要条件
1、类的完整类名完全一样、包括包名
2、加载这个类的classloader(ClassLoader的实例对象)必须相同
即使两个class对象由同一个类文件加载而来，只要加载的类加载器不一样那这两个class对象也不相等
对类加载器的引用