虚拟机类加载机制

最新推荐文章于 2023-01-06 08:51:55 发布

先给自己打个气

最新推荐文章于 2023-01-06 08:51:55 发布

阅读量127

点赞数

分类专栏： JVM深入讲解文章标签： jvm java

本文链接：https://blog.csdn.net/qq_40641206/article/details/111632316

版权

JVM深入讲解专栏收录该内容

3 篇文章 0 订阅

订阅专栏

虚拟机类加载机制

虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。

1、类加载的生命周期

加载->验证->准备->解析->初始化->使用->卸载七个阶段，验证、准备、解析三个部分叫做连接。

加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程回按照这种顺序去开始，而解析阶段不一定：它在某些情况下可以在初始化阶段之后在开始，这是为了支持Java的运行时绑定（动态绑定）

在初始化流程时，虚拟机规定了5种情况立即对类进行”初始化“：

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

2、类加载过程

加载

1、通过一个类的全限定名来获取定义此类的二进制字节流

例如：zip压缩包获取，网络获取，动态代理获取、jsp文件、数据库读取等

2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

3、在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

加载阶段与连接阶段是交叉进行的，加载阶段尚未完成、连接阶段可能已经开始。

验证

验证是连接的第一步，这一阶段目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。这个阶段如果不坚持输入的字节流，对其完全信任，很可能因为载入了有害的字节流导致系统崩溃。

例如：数据边界外的数据；将一个对象转型成它并未实现的类型；跳转到不存在的代码。

验证可以分为四个阶段的检验：

1、文件格式验证

验证字节流是否符合Class文件格式规范，能否被当前版本虚拟机处理

是否以魔数0xCAFEBABE开头
主次版本号是否在当前虚拟机处理范围之内
常量池的常量中是否有不被支持的常量类型
指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量
CONSTANT_Utf8_info型的常量是否有不符合UTF8编码的数据。
Class文件中各个部分及文件本身是否有被删除的或附加的其他信息
。。等

通过了一系列验证之后，字节流才会进入内存的方法区中进行存储，后面的三个都是基于方法区的存储结构进行的，不会咋在直接操作字节流。

2、元数据验证

对字节码描述的信息进行语义分析，保证其描述的信息符合Java语言规范

这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）
这个类是否继承了不允许被继承的类（final修饰的）
这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法
类中的字段、方法是否与父类产生矛盾（例如覆盖了父类的final字段，重载是不是不符合规则）

3、字节码验证

主要是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。第二阶段对元数据中的数据类型做完校验后，这个阶段将对类的方法体进行校验分析，保证被校验的类的方法在运行时不会做出危害虚拟机安全的事件。

例如：

int类型的数据，使用时按long类型加载入本地变量表
保证跳转指令不会跳转到方法体以外的字节码指令
保证方法体类型转换时有效的，（父类对象赋值给子类数据类型）
。。等

类方法体的字节码没有通过字节码验证，肯定有问题，但通过了字节码验证，也不一定时安全的。

4、符号引用验证

此校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段（解析阶段中发生），校验的内容为：

符号引用中通过字符串描述的全限定名是否能找到对应的类。
在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段。
符号引用中的类、字段、方法的访问性（private、protected、public、default）是否可被当前类访问.

验证这一阶段不是必要的，如果确定这个代码没有问题，可以通过-Xverify:none参数来关闭大部分类验证措施，缩短虚拟机类加载的时间

准备

准备阶段时正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。它仅分配类变量（static修饰的），不包括实例变量。

public static int val = 123;//在准备阶段过后初始值为0，把123赋值的putstatic指令时程序编译后。
public static final int val = 123;//因为存在ConstantValue属性，在准备阶段变量val就会被初始化为ConstantValue的值

解析

将符号引用替换为直接引用的过程

符号引用：以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义的定位到目标即可。
直接引用：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。

初始化

类初始化时类加载过程的最后一步，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。再此阶段，开始执行类中定义的Java程序代码。

在准备阶段，变量已经被赋过一次系统要求的初始值，在初始化阶段，去初始化类变量和其他资源，也可以理解为执行类构造器()方法的过程。

3、类加载器

加对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java 虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话可以表达得更通俗一些:比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

1、双亲委派模型

从Java虚拟机角度来讲，只存在两种不同的类加载器：

启动类加载器（Bootstrap ClassLoader），由c++语言实现，虚拟机自身的一部分
其他所有的类加载器，由Java语言实现，独立于虚拟机外部,并且全部继承自抽象类java.lang.ClassLoader

从开发人员来看：

启动类加载器（Bootstrap ClassLoader），主要加载<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定路径的
扩展类加载器（Extension ClassLoader）: 它负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库
应用程序类加载器(Application ClassLoader):这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，壁板也叫系统类加载器。它负责加载用户类路径(ClassPath)上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序没有自定义自己的类加载器，他就是默认的类加载器。

在这里插入图片描述

上图这种层次关系称为类加载器的双亲委派模型。双亲委派模型要求处理顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。

双亲委派模型的工作过程：

如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

使用双亲委派的好处：

例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶层的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类，相反如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证

/**
* 双亲委派模型的实现
*/
protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // First,检查请求的类是否已经被加载过
            Class<?> c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // 如果父类加载器抛出ClassNotFoundException
                    //说明父类加载器无法完成加载请求
                }

                if (c == null) {
                    // 在父类加载器无法加载的时候，调用本身的findClass来进行类加载
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    //这是定义类加载器；记录统计数据
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }

破环双亲委派：

1、双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前——即JDK 1.2发布之前。由于双亲委派模型在JDK 1.2之后才被引人，而类加载器和抽象类java.lang.ClassLoader则在JDK 1.0时代就已经存在，面对已经存在的用户自定义类加载器的实现代码，Java设计者引人双亲委派模型时不得不做出一些妥协。为了向前兼容，JDK 1.2之后的java.lang.ClassLoader添加了一个新的protected方法 findClass()，JDK 1.2之后已不提倡用户再去覆盖loadClass()方法，而应当把自己的类加载逻辑写到findClass()方法中，在loadClass()方法的逻辑里如果父类加载失败，则会调用自己的findClass()方法来完成加载，这样就可以保证新写出来的类加载器是符合双亲委派规则的。

2、第二次破环时因为自身的缺陷，试想一个问题，双亲委派很好的解决的各个类加载器基础类统一的问题，是因为它们总是作为用户代码调用的API，但如果基础类想调回用户的代码，那该怎么办？

Java设计团队引入了一个叫线程上下文类加载器(Thread Context ClassLoader)。这个类加载器可以加载我所需要的子类加载器加载的类，也就是父类加载器请求子类加载器去完成类加载，逆向的使用类加载器。

3、第三次是因为追求程序动态性的追求导致的。例如热部署，代码热替换。

OSGi实现模块话的关键是它自定义类加载器机制的实现，每一个程序模块(OSGi中称为Bundle)都有一个自己的类加载器，当需要更换一个模块时，连同模块带着类加载器一起换掉实现代码的热替换。

在OSGi下，类加载器不再是树状结构，而是复杂的网状架构。当收到类加载请求时，OSGi将按照下面的顺序进行类搜索:
1）将以java.*开头的类委派给父类加载器加载。
2）否则，将委派列表名单内的类委派给父类加载器加载。
3）否则，将Import列表中的类委派给Export这个类的 Bundle 的类加载器加载。4）否则，查找当前Bundle的 ClassPath，使用自己的类加载器加载。

5）否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。
6）否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。

7)否则，类查找失败。

上面的查找顺序中只有开头两点仍然符合双亲委派规则，其余的类查找都是在平级的类加载器中进行的。

2、tomcat的类加载器架构

一个功能健全的Web服务器,要解决几个问题：

部署在同一个服务器上的两个Web应用程序所使用的Java类库可以实现相互隔离。
- 两个不同的应用程序可能会依赖同一个第三方类库的不同版本，不能要求一个类库在一个服务器一份，服务器应当保证两个应用程序的类库可以互相独立使用
部署在统一服务器上的两个Web应用程序所使用的Java类库可以互相共享。
- 用户把10个使用spring组织的应用程序部署在同一台服务器上，如果把10份Spring分别存放在各个应用程序的隔离目录中，将会时很大的资源浪费，如果类库不能共享，虚拟机的方法区很容易出现过度膨胀的风险。
服务器需要尽可能地保证自身的安全不受部署的web应用程序的影响。
- 服务器本身也有类库依赖问题，基于安全考虑，服务器所使用的类库应该与应用程序的类库互相独立。
支持热部署

（“/common/*”，“/server/*”，“shared/*”，“WEB-INF/*”）

放置在/common目录中:类库可被Tomcat和所有的Web应用程序共同使用。
放置在/server目录中:类库可被Tomcat使用，对所有的Web应用程序都不可见。
放置在/shared目录中:类库可被所有的Web应用程序共同使用，但对Tomcat自己不可见。
放置在/WebApp/WEB-INF目录中:类库仅仅可以被此Web应用程序使用，对Tomcat和其他Web应用程序都不可见。

在这里插入图片描述

最上面的3个类加载器时JDK默认提供的类加载器，下面的都是Tomcat自己定义的类加载器。

Common ClassLoader能加载的类都可以被Catalina ClassLoader,和Shared ClassLoader使用，

而CatalinaClassLoader和 SharedClassLoader自己能加载的类则与对方相互隔离。

WebAppClassLoader可以使用SharedClassLoader加载到的类，但各个webAppClassLoader实例之间相互隔离。

而 JasperLoader 的加载范围仅仅是这个JSP文件所编译出来的那一个Class，它出现的目的就是为了被丢弃:当服务器检测到JSP文件被修改时，会替换掉目前的JasperLoader的实例，并通过再建立一个新的Jsp类加载器来实现JSP文件的HotSwap功能。

先给自己打个气

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
虚拟机类加载机制

虚拟机类加载机制虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。1、类加载的生命周期加载->验证->准备->解析->初始化->使用->卸载七个阶段，验证、准备、解析三个部分叫做连接。加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程回按照这种顺序去开始，而解析阶段不一定：它在某些情况下可以在初始化阶段之后在开始，这是为了支持Java的运
复制链接

扫一扫