第一章 JVM类加载_java

文章目录

- - 1、JVM的位置
  - 2、JVM的架构模型
  - 3、内存结构
  - 4、类加载子系统
  - - 4.1、类加载过程
    - 4.1、类的加载
    - 4.2、类的链接
    - 4.2、类的初始化
  - 5、类的加载器
  - - 5.1、类加载器的分类
    - 5.2、Bootstrap ClassLoader（启动类加载器、引导类加载器)
    - 5.3、ExtClassLoader(扩展类加载器)
    - 5.4、AppClassLoader(应用类加载器即系统类加载器)
    - 5.5、用户自定义类加载器
    - 5.6、代码示例
  - 6、双亲委派机制
  - - 6.1、双亲委派机制原理
    - 6.2、双亲委派机制优势
    - 6.3、判断两个class对象是否相同

1、JVM的位置

2、JVM的架构模型

Java编译器输入的指令流基本上是一种基于栈的指令集架构，另外一种指令集架构则是基于寄存器的指令集架构。这两种架构之间的区别：

基于栈式架构的特点

设计和实现更简单，适用于资源受限的系统
避开了寄存器的分配难题：使用零地址指令方式分配
指令流中的指令大部分是零地址指令，其执行过程依赖于 *** 作栈。指令集更小，编译器容易实现
不需要硬件支持，可移植性更好，更好实现跨平台

基于寄存器架构的特点

典型的应用是x86的二进制指令集：比如传统的PC以及Android的Davlik虚拟机。
指令集架构则完全依赖硬件，与硬件的耦合度高，可移植性差
性能优秀和执行更高效
花费更少的指令去完成一项 *** 作
在大部分情况下，基于寄存器架构的指令集往往都以一地址指令、二地址指令和三地址指令为主，而基于栈式架构的指令集却是以零地址指令为主

3、内存结构

4、类加载子系统 4.1、类加载过程

加载 -》链接（验证、准备、解析）-》初始化

4.1、类的加载

通过一个类的全限定名获取定义此类的二进制字节流
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

4.2、类的链接

验证：确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全。

主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证

准备：为类变量分配内存并且设置该类变量的默认初始值，即零值

这里不包含用final修饰的static，因为final在编译的时候就会分配好了默认值，准备阶段会显式初始化
这里不会为实例变量分配初始化，实例变量会随着对象一起分配到Java堆中

解析：将常量池内的符号引用转换为直接引用的过程

符号引用就是一组符号来描述所引用的目标。直接引用就是直接指向目标的指针
反编译字节码文件后，可以查看符号引用

4.2、类的初始化

初始化阶段就是执行类构造器方法()的过程
此方法不需定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。也就是说，当我们代码中包含static变量的时候，就会有( )方法；如果当前类不存在static变量，那么它的字节码文件是不会存在( )

()方法中的指令按语句在源文件中出现的顺序执行
()不同于类的构造器。（构造器是字节码文件里的()方法）
若该类具有父类，JVM会保证子类的()执行前，父类的()已经执行完毕
虚拟机必须保证一个类的()方法在多线程下被同步加锁

说明：当前类存在静态变量，类的字节码文件就存在()方法，否则就不存在

5、类的加载器 5.1、类加载器的分类

JVM支持两种类型的类加载器。分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）
从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器
无论类加载器的类型如何划分，在程序中我们最常见的类加载器始终只有3个，如下所示

5.2、Bootstrap ClassLoader（启动类加载器、引导类加载器)

这个类加载使用C/C++语言实现的，嵌套在JVM内部
它用来加载Java的核心库（JAVA_HOME / jre / lib / rt.jar、resources.jar 或 sun.boot.class.path 路径下的内容），用于提供JVM自身需要的类
并不继承自java.lang.ClassLoader，没有父加载器
加载扩展类和应用程序类加载器，并作为他们的父类加载器
出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类

5.3、ExtClassLoader(扩展类加载器)

继承关系图
特点：

Java语言编写，由sun.misc.Launcher$ExtClassLoader实现
派生于ClassLoader类，父类加载器为启动类加载器
从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的 jre / lib / ext子目录（扩展目录）下加载类库。如果用户创建的 JAR 放在此目录下，也会自动由扩展类加载器加载

5.4、AppClassLoader(应用类加载器即系统类加载器)

继承关系图

2、特点：

Java语言编写，由sun.misc.LaunchersAppClassLoader实现
派生于ClassLoader类，父类加载器为扩展类加载器
它负责加载环境变量 classpath 或系统属性java.class.path指定路径下的类库
该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载的
通过ClassLoader.getSystemclassLoader( )方法可以获取到该类加载器

5.5、用户自定义类加载器

自定义类加载器实现：

开发人员可以通过继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器，以满足一些特殊的需求
在JDK1.2之前，在自定义类加载器时，总会去继承ClassLoader类并重写loadClass( )方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖loadClass( )方法，而是建议把自定义的类加载逻辑写在findclass( )方法中
在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URIClassLoader类，这样就可以避免自己去编写findclass( )方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

为什么还需要自定义类加载器？

隔离加载类
修改类加载的方式
扩展加载源
防止源码泄露

5.6、代码示例

public class TestCLassLoader {
    public static void main(String[] args) {
        //获取系统类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader);

        //获取扩展类加载器
        ClassLoader extClassLoader = systemClassLoader.getParent();
        System.out.println(extClassLoader);

        //获取引导类加载器（获取不到，因为引导类加载器是C语言实现的）
        ClassLoader bootStrapClassLoader = extClassLoader.getParent();
        System.out.println(bootStrapClassLoader);

        //获取加载当前类TestCLassLoader的类加载器(testClassLoader的地址和systemClassLoader的地址一致，用户自定义类由系统类加载器加载)
        ClassLoader testClassLoader = TestCLassLoader.class.getClassLoader();
        System.out.println(testClassLoader);

        //java.lang.System类使用引导类加载器进行加载的,获取到的内存地址为null
        ClassLoader sysClassLoader = System.class.getClassLoader();
        System.out.println(sysClassLoader);
    }
}