JVM04内存结构概述

JVM架构
在这里插入图片描述
类加载器的子系统:

  • 类加载器子系统负责从文件系统或者网络中加载class文件,class文件在文件头有特定的文件标识
  • ClassLoader只负责class文件加载,至于它是否可运行,则由Execution Engine决定
  • 加载的类信息存放于一块成为方法区的内存空间。除了类信息外,方法区中还会存放运行时常量池的信息,可能还包括字符串字面量和数字常量(这部分常量信息是Class文件中常量池部分的内存映射)

类加载器ClassLoader角色:
1.class file存在于本地硬盘上,可以理解为设计师画在纸上的模板,而最终这个模板在执行的时候是要加载到JVM当中来,根据这个文件实例化出n个一模一样的实例。
2.class file加载到JVM中,被成为DNA元数据模板,放在方法区
3.在.class文件—>JVM—>最终成为元数据模板,在此过程就要一个运输工具(类装载器Class Loader),扮演一个快递员角色。

类加载过程:
在这里插入图片描述

1.加载(loading)

加载时jvm做了这三件事:

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

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

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

补充:加载.class文件的方式
从本地系统中直接加载

  • 通过网络获取,典型场景:Web Applet
  • 从zip压缩包中读取,成为日后jar、war格式的基础
  • 运行时计算生成的,使用最多的是:动态代理技术
  • 有其他文件生成,典型场景:JSP的生成
  • 从转有的数据库中提取.class文件,比较少见
  • 从加密文件中获取,典型的防class文件被反编译的保护措施

2.链接:
验证(Verify)

  • 目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求,保证被加载类的正确性,不会危害虚拟机自身安全。
  • 主要包括四种验证,文件格式验证,元数据验证,字节码验证,符号引用验证

准备(Paper)

  • 为变量分配内存并且设置该变量的默认初始值,即零值。
  • 这里不包含用final修饰的static,因为final在编译的时候会分配了,准备阶段会显式初始化;
  • 这里不会为实例变量分配初始化,类变量会分配在方法区中,而实例变量是会随着对象一起分配到Java堆中。

解析(Resolve):

  • 将常量池内的符号引用转换为直接引用过程。
  • 事实上,解析操作往往会伴随着JVM在执行完初始化之后再执行。
  • 符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《Java虚拟机规范》的Class文件格式中。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标句柄。
  • 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等。

三、初始化(initialization):

  • 初始化阶段就是执行类构造器方法<clinit()的过程,clinit方法相当于class的初始化。
  • 此方法不需要定义,是Javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并来的。
  • 构造器方法中指令按语句来源文件中出现的顺序执行
  • <clinit()不同于类的构造器。(关联:构造器是虚拟机视角下的())
  • 若该类具有父类,JVM会保证子类的<clinit()执行前,父类的<clinit()已经执行完成
    虚拟机必须保证一个类的方法在多线程下被同步加锁。
    (clint那里还有一个>,但是因为加了之后不显示,所以先去掉)

具体谈一下clint和init:
<clinit,类构造器方法,在jvm第一次加载class文件时调用,因为是类级别的,所以只加载一次,是编译器自动收集类中所有类变量(static修饰的变量)和静态语句块(static{}),中的语句合并产生的,编译器收集的顺序,是由程序员在写在源文件中的代码的顺序决定的。
<init,实例构造器方法,在实例创建出来的时候调用,包括调用new操作符;调用Class或java.lang.reflect.Constructor对象的newInstance()方法;调用任何现有对象的clone()方法;通过java.io.ObjectInputStream类的getObject()方法反序列化。

<clinit() 与 <init() 区别
<clinit()
Java 类加载的初始化过程中,编译器按语句在源文件中出现的顺序,依次自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并产生 <clinit() 方法。 如果类中没有静态语句和静态代码块,那可以不生成<clinit()` 方法。
clinit是类构造器方法,也就是在jvm进行类加载—–验证—-解析—–初始化,中的初始化阶段jvm会调用clinit方法。

并且 <clinit() 不需要显式调用父类(接口除外,接口不需要调用父接口的初始化方法,只有使用到父接口中的静态变量时才需要调用)的初始化方法 <clinit(),虚拟机会保证在子类的 <clinit() 方法执行之前,父类的 <clinit() 方法已经执行完毕。

<init()
对象构造时用以初始化对象的,构造器以及非静态初始化块中的代码。
init是对象构造器方法,也就是说在程序执行 new 一个对象调用该对象类的 constructor 方法时才会执行init方法

init is the (or one of the) constructor(s) for the instance, and non-static field initialization.
clinit are the static initialization blocks for the class, and static field initialization.
上面这两句是Stack Overflow上的解析,很清楚init是instance实例构造器,对非静态变量解析初始化,而clinit是class类构造器对静态变量,静态代码块进行初始化。
即一个为类加载过程(clinit): clinit方法中的执行顺序为:父类静态变量初始化,父类静态代码块,子类静态变量初始化,子类静态代码块; clinit()方法只执行一次。
一个是对象实例化过程, init()方法中的执行顺序为:父类变量初始化,父类代码块,父类构造器,子类变量初始化,子类代码块,子类构造器。

clinit()方法优先于init()方法执行,所以整个顺序就是:
父类静态变量初始化,父类静态代码块,子类静态变量初始化,子类静态代码块,父类非静态变量初始化,父类非静态代码块,父类构造器,子类非静态变量初始化,子类非静态代码块,子类构造器。
<clinit() 与 <init() 执行顺序
一个代码用例,用的别人文章里的

public class Test {
    private static Test instance;

    static {
        System.out.println("static开始");
        // 下面这句编译器报错,非法向前引用
        // System.out.println("x=" + x);
        instance = new Test();
        System.out.println("static结束");
    }

    public Test() {
        System.out.println("构造器开始");
        System.out.println("x=" + x + ";y=" + y);
        // 构造器可以访问声明于他们后面的静态变量
        // 因为静态变量在类加载的准备阶段就已经分配内存并初始化0值了
        // 此时 x=0,y=0
        x++;
        y++;
        System.out.println("x=" + x + ";y=" + y);
        System.out.println("构造器结束");
    }

    public static int x = 6;
    public static int y;

    public static Test getInstance() {
        return instance;
    }

    public static void main(String[] args) {
        Test obj = Test.getInstance();
        System.out.println("x=" + obj.x);
        System.out.println("y=" + obj.y);
    }
}

输出信息:

static开始
构造器开始
x=0;y=0
x=1;y=1
构造器结束
static结束
x=6
y=1

虚拟机首先执行的是类加载初始化过程中的 <clinit() 方法,也就是静态变量赋值以及静态代码块中的代码,如果 <clinit() 方法中触发了对象的初始化,也就是 <init() 方法,那么会进入执行 <init() 方法,执行 <init() 方法完成之后,再回来继续执行 <clinit() 方法。

这段用的例子的地址如下:
https://www.jianshu.com/p/7ff65c3040ec

四.类加载器的分类

  • JVM支持两种类型的类加载器,分别为引导类加载器(Bootstrap ClassLoader)和自定义类加载器(User-Defined
    ClassLoader).
  • 从概念上来讲,自定义类加载器一般指的是程序中由开发人员自定义的一类加载器,但是Java虚拟机规范却没有这么定义,而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器.
  • 无论类加载器的类型如何划分,在程序中我们最常见的类加载器始终只有3个
    在这里插入图片描述
    1. 启动类加载器:Bootstrap ClassLoader(引导类加载器)
    负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录,下同)下,或被-Xbootclasspath参数指定的路径中的,并且能被虚拟机识别的类库(如rt.jar,所有的java.开头的类均被Bootstrap ClassLoader加载)。启动类加载器是无法被Java程序直接引用的。
  • 这个类使用c/c++语言实现,嵌套在JVM内部
  • 用来加载Java核心库(JAVA_HOME/jre/lib/rt.jar\resourece.jar或sun.boot.class.path下的内容),用于提供JVM自身需要的类
  • 并不继承自Java.lang.ClassLoader,没有父类加载器
  • 加载扩展类和应用程序类加载器,并指定为他们的父类加载器
  • 出于安全考虑,Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类

2. 扩展类加载器:Extension ClassLoader
该加载器由sun.misc.Launcher$ExtClassLoader实现,它负责加载JDK\jre\lib\ext目录中,或者由java.ext.dirs系统变量指定的路径中的所有类库(如javax.开头的类),开发者可以直接使用扩展类加载器。

  • Java语言编写
  • 派生于ClassLoader类
  • 父类加载器为启动类加载器
  • 从Java.ext.dirs系统属性所指定的目录中加载类库,或从JDK的安装目录的jre/lib/ext子目录(扩展目录)下加载类库。如果用户创建的JAR放在此目录下,也会自动由扩展类加载器加载。

3. 应用程序类加载器:Application ClassLoader(系统类加载器)
该类加载器由sun.misc.Launcher$AppClassLoader来实现,它负责加载用户类路径(ClassPath)所指定的类,开发者可以直接使用该类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。

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

4. 自定义类加载器(反射)UrlClassLoader
UrlClassLoader u=new UrlClassLoader(new RUL[] {“c:/a.jar”}) //要加载的路径数组
Class c =u.loadClass(“cn.et.A”); //Class 是通用 类加载器
Object obj=c.newInstance(); //实例化
Method method =c.getMethod(“syso”); //通用方法Method 获取加载类a的syso方法
method.invoke(obj) //反射,执行方法
为什么要自定义类加载器:

  • 隔离加载类
  • 修改类加载的方式
  • 扩展加载源
  • 防止源码泄露
    用户自定义类加载器实现步骤:
    1.开发人员可用通过继承抽象类Java.lang.ClassLoader类的方式,实现自己的类加载器,以满足一些特殊的需求
    2.在JDK1.2之前,在自定义类加载器时,总会去继承ClassLoader类并重写loadClass()方法,从而实现自定义的类加载类,但是JDK1.2之后,已不再建议用户去覆盖loadClass()方法,而是建议把自定义的类加载逻辑写在findClass()方法中
    3.在编写自定义类加载器时,如果没有太过于负责的需求,可用之间继承URLClassLoader类,这样就可以避免自己去写findClass()方法以及其获取字节码流的方式,使自定义类加载器编写更加简洁。

关于ClassLoader
是一个抽象类,其后所有的类加载器都继承自ClassLoader(不包括启动类加载器)。
获取ClassLoader的途径
方式一:获取当前类的ClassLoader
class.getClassLoader()
方式二:获取当前线程上下文的ClassLoader
Thread.currentThread().getContextClassLoader()
方式三:获取系统的ClassLoader
ClassLoader.getSystemClassLoader()
方式四:获取调用者的ClassLoader
DriverManger.getCallerClassLoader()

发布了20 篇原创文章 · 获赞 3 · 访问量 1710

猜你喜欢

转载自blog.csdn.net/weixin_43493354/article/details/104761644