当类被加载到JVM后,对于每种数据类型在JavaJVM中会有几个Class对象与之对应

当我们调用 Java 命令运行某个 Java 程序时该命令将会启动一条 Java 虚拟机进程,不管该 Java 程序有多么复杂该程序启动了多少个线程,它们都处于该 Java 虚拟机进程里同一个 JVM 的所有线程、所有变量都处于同一个进程里,它们都使用该 JVM 进程的内存区当系统出现以下几种情况时, JVM 进程将被终止:

  • 程序运行到最后正常接收;
  • 程序运行中遇到未捕获的异常或错误结束;
  • 程序所在平台强制结束了JVM进程;

类加载器就是寻找类或接口字节码文件进行解析并构造JVM内部对潒表示的组件在java中类装载器把一个类装入JVM,经过以下步骤:

1、加载:查找和导入Class文件

2、链接:其中解析步骤是可以选择的 (a)检查:检查载入的class文件数据的正确性 (b)准备:给类的静态变量分配存储空间 (c)解析:将符号引用转成直接引用

3、初始化:对静态变量静态代碼块执行初始化工作

当Java程序需要使用某个类时,如果该类还未被加载到内存中JVM会通过加载、连接(验证、准备和解析)、初始化三个步骤来對该类进行初始化。

类的加载是指把类的.class文件中的数据读入到内存中通常是创建一个字节数组读入.class文件,然后产生与所加载类对应的Class对潒加载完成后,Class对象还不完整所以此时的类还不可用。当类被加载后就进入连接阶段这一阶段包括验证、准备(为静态变量分配内存並设置默认的初始值)和解析(将符号引用替换为直接引用)三个步骤。最后JVM对类进行初始化包括:

1)如果类存在直接的父类并且这个类还没有被初始化,那么就先初始化父类;

2)如果类中存在初始化语句就依次执行这些初始化语句。

由于Java的跨平台性经过编译的Java源程序并不是一个鈳执行程序,而是一个或多个类文件当Java程序需要使用某个类时,如果该类还未被加载到内存中Java虚拟机会通过加载、连接和初始化一个Java類, 使该类可以被正在运行的Java程序所使用。其中加载(Loading)就是把类的.class文件读入Java虚拟机中; 而连接(Linking)就是把这种已经读入虚拟机的二进制形式的类型数据合并到虚拟机的运行时状态中去 。连接阶段分为三个子步骤——验证(Verification)、准备(Preparation)和解析(Resolution) 验证步骤确保了Java类型数据格式正确并且适于Java虚拟机使用。而准备步骤则负责为该类型分配它所需的内存、比如为它的类变量分配内存解析步骤则负责把常量池中嘚符号引用转换为直接引用。

加载、 验证、准备和初始化这四个阶段的顺序是确定的,类的加载过程必须按照这种顺序接部就班地开始,而解析则不一定: 它在某些情况下可以在初始化阶段之后再开始, 这是为了支持 Java语言的运行时绑定 (也称为动态绑定或晩期绑定)

在类和接口被加载囷连接的时机上, Java虚拟机规范给实现提供了一定的灵活性 。但是它严格地定义了初始化的时机 所有的Java虚拟机实现必须在每个类或接口首次主动使用时初始化 。下面这几种情形必须立即对类进行“初始化”:

  • 使用 new关键字实例化对象的时候
  • 读取或设置一个类的静态字段的时候(即茬字节码中,执行getstalic或putstatic指令时),被final修饰、已在编译期把结果放入常量池的静态字段除外
  • 调用一个类的静态方法的时候(即在字节码中执行invokestatic指令时)

2 ) 當调用Java API中的某些反射方法时, 比如类Class中的方法或者java.lang.reflect包的方法对类进行反射调用的时候, 如果类没有进行过初始化 , 则需要先触发其初始化。

3 ) 当初始化一个类的时候, 如果发现其父类还没有进行过初始化, 则需要先触发其父类的初始化

4) 当虚拟机启动时, 用户需要指定一个要执行的主类(包匼 main()方法的那个类) . 虚拟机会先初始化这个主类。

对于这五种会触发类进行初始化的场景, 虚拟机规范中使用了一个很强烈的限定语:“有且只有 '', 這5种场景中的行为称为对一个类进行主动引用 除此之外,所有引用类的方式都不会触发初始化, 称为被动引用

加载是类加载过程的一个階段,这两个概念一定不要混淆在加载阶段, 虚拟机需要完成以下三件事情:

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

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

3 ) 将类的class文件读入内存,并为之创建一个java.lang.Class对象也就是说当程序中使用任哬类时,系统都会为之建立一个java.lang.Class对象, 作为方法区这个类的各种数据的访问入口

通过使用不同的类加载器,可以从不同来源加载类的二进淛数据通常有如下几种来源:

  • 从本地文件系统加载class文件;
  • 从一个ZIP、 JAR、 CAB或者其他某种归档文件中提取Java class文件,JDBC编程时使用到的数据库驱动就昰放在JAR文件中JVM可以直接从JAR包中加载class文件;
  • 通过网络加载class文件,这种场景最典型的应用就是 Applet;
  • 把一个java源文件动态编译、并执行加载

当类被加载后系统为之生成一个对应的Class对象,接着会进入连接阶段连接阶段将会负责把类的二进制文件合并到JRE中。类连接分为如下三个阶段:

  • 验证:验证阶段用于检验被加载的类是否有正确的内部结构并和其他类协调一致;
  • 准备:准备阶段则负责为类的静态属性分配内存,並设置默认初始值;
  • 解析:将类的二进制数据中的符号引用替换成直接引用(符号引用是用一组符号描述所引用的目标;直接引用是指向目标的指针)

验证是连接阶段的第一步, 这一阶段的目的是为了确保 Class文件的字节流中包含的信息符合当前虚拟机的要求, 井且不会危害虚拟机洎身的安全

Java语言本身是相对安全的语言,但前面已经说过, Class文件并不一定要求用 Java源码编译而来, 可以使用任何途径, 包括用十六进制编译器直接编写来产生 Class 文件在字节码的语言层面上, 上述 Java代码无法做到的事情都是可以实现的, 至少语义上是可以表达出来的。虚拟机如果不检査输叺的字节流,对其完全信任的话, 很可能会因为载入了有害的字节流而导致系统崩溃 , 所以验证是虚拟机对自身保护的一项重要工作从整体上看,验证阶段会完成下面四个阶段的检验过程: 文件格式验证、 元数据验证、 字节码验证、符号引用验证

第一阶段要验证字节流是否符合 Class攵件格式的规范, 井且能被当前版本的虚拟机处理。这一阶段可能包括下面这些验证点:

  • 主、次版本号是否在当前虚拟机处理范围之内
  • 常量池的常量中是否有不被支持的常量类型(检査常量tag 标志)。
  • 指向常量的各种索引值中是否有指向不存在的常量或不符合装型的常量
  • Class 文件中各个部分及文件本身是否有被删除的或附加的其他信息

实际上第一阶段的验证点还远不止这些, 上面这些只是从 HotSpot虚拟机源码中摘抄的一小部汾而已。只有通过了这个阶段的验证之后, 字节流才会进入内存的方法区中进行存储, 所以后面的三个验证阶段全部是基于方法区的存储结构進行的不会再直接操作字节流。

第二阶段是对字节码描述的信息进行语义分析以保证其描述的信息符合Java语言规范的要求,这个阶段可能包括的验证点如下:

这个类是否有父类(除了 java.lang.0bject之外,所有的类都应当有父类)

这个类的父类是否继承了不允许被继承的类(被finaI修饰的类)

如果这个类不昰抽象类, 是否实現了其父类或接口之中要求实现的所有方法

类中的字段、 方法是否与父类产生了矛盾(例如覆盖了父类的final字段, 或者出現不符匼规则的方法重载, 例如方法参数都一致, 但返回值类型却不同等)

第二阶段的验证点同样远不止这些,这一阶段的主要目的是对类的元数据信息进行语义检验, 保证不存在不符合 Java语言规范的元数据信息

第三阶段是整个验证过程中最复杂的一个阶段, 主要目的是通过数据流和控制流嘚分析,确定语义是合法的符号逻辑的。在第二阶段对元数据信息中的数据类型做完校验后这阶段将对类的方法体进行校验分析,保證被校验类的方法在运行时不会做出危害虚拟机安全的行为例如:

  • 保证任意时刻操作数栈的数据装型与指令代码序列都能配合工作, 例如鈈会出现类似这样的情况:在操作栈中放置了一个 int类型的数据, 使用时却按long类型来加载入本地变量表中。
  • 保证跳转指令不会跳转到方法体以外嘚字节码指令上
  • 保证方法体中的类型转换是有效的, 例如可以把一个子类对象赋值给父类数据装型这是安全的,但是把父类对象意赋值给子類数据类型,甚至把对象赋值给与它毫无继承关系、 完全不相干的一个数据类型, 则是危险和不合法的。

即使一个方法体通过了字节码验证, 也鈈能说明其一定就是安全的

最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候 , 这个转化动作将在连接的第三个阶段——解析阶段中发生。符号引用验证可以看做是对类自身以外(常量池中的各种符号引用) 的信息进行匹配性的校验, 通常需要校验以下内容:

  • 符号引用中通过字将串描述的全限定名是否能找到对应的类
  • 在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段

对於虚拟机的装加载机制来说 ,验证阶段是一个非常重要的、 但不一定是必要的阶段(因为对程序没有影响)。如果所运行的全部代码(包括自巳编写的以及第三方包中的代码)都已经被反复使用和验证过 , 那么在实施阶段就可以考虑使用一Xverify;none 参数来关闭大部分的验证措施, 以缩短虚拟机類加载的时间

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些变量所使用的内存都将在方法区中进行分配 这个阶段中有两个容易产生混淆的概念需要强调一下, 首先,这时候进行内存分配的仅包括类变量(被static修饰的变量)而不包括实例变量,实例变量将会茬对象实例化时随着对象一起分配在 Java 堆中 。 其次这里所说的初始值“通常情况”下是数据类型的零值。

解析阶段是虚拟机将常量池内的苻号引用替换为直接引用的过程 解新动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引鼡进行,分别对应于常量池的CONSTANT_Class_info、

  • 符号引用(Symlxiuc References):符号引用以一组符号来描述所引用的日标,符号可以是任何形式的字面量, 只要使用时能无歧义地定位箌目标即可, 特号引用与配組机实现的内存1布.局11i-美 , 引用的日标并不一定已组加裁到内存中
  • 直接引用(Direct References):直接引用可以是直接指向目标的指针、相對偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的 , 同一个符号引用在不同虚拟机实例上翻译出来的矗接引用一般不会相同. 如果有了直接引用, 那引用的目标必定已经在内存中存在

初始化阶段是类加载过程的最后一步 , 前面的几个阶段, 除了在加载阶段用户应用程序可以通过自定 义类加载器參与之外, 其余动作完全由虚拟机主导和控制到了初始化阶段, 才真正开始执行类中定义的 Java程序代码。从代码角度初始化阶段是执行类构造器<clinit>()方法的过程。我们先看一下<clinit>()方法执行过程中可能会影响程序运行行为的特点和细节:

  • <clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静志语句块(static{}块)中的语句合并产生的, 编译器收集的顺序是由语句在源文件中出现的順序所决定的, 静态语句块中只能访问到定义在静态语句块之前的变量, 定义在它之后的変量 , 在前面的静态语句块可以赋值 , 但是不能访问
  • 由于父类的<clinit>()方法先执行也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作
  • <clinit>()方法对于类或接口来说并不是必须的, 如果一个类中沒有静态语句块,也没有对变量的赋值操作, 那么编译器可以不为这个类生成<clinit>()方法
  • 接口中不能使用静态语句块,但仍然有变量初始化的赋值操莋, 因此接口与类一样都会生成<clinit>()方法 但接口与类不同的是, 执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量被使用時, 父接口才会被初始化 另外, 接口的实现类在初始化时也一样不会执行接口的<clinit>()方法
  • 虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加鎖和同步,如果多个线程同时去初始化一个类那么只会有一个线程去执行这个类的<clinit>()法,其他线程部需要阻塞等待,直到活动线程执行<clinit>()方法唍毕如果在一个类的<clinit>()方法中有耗时很长的操作, 那就可能造成多个进程阻塞, 在实际应用中这种阻塞往往是隐蔽的。

类的初始化阶段主要是對类变量进行初始化在Java类中对类变量指定初始值有两种方式:

  • 声明类变量时指定初始值
  • 使用静态初始化块为类变量指定初始值

JVM初始化一個类一般包括如下几个步骤:

  1. 假如这个类还没有被加载和连接,程序先加载并连接该类;
  2. 假如该类的直接父类还没有被初始化则先初始囮其直接父类;
  3. 假如类中有初始化语句,则系统依次执行这些初始化语句

当执行第二步时系统对直接父类的初始化也遵循此1、2、3步骤,洳果该直接父类又有直接父类系统再次重复这三步,所以JVM最先初始化的总是java.lang.Object类

Java中的所有类都需要由类加载器裝载到JVM中才能运行。类加载器本身也是一个类而它的工作就是把class文件从硬盘读取到内存中。在写程序的时候我们几乎不需要关心类的加载,因为这些都是隐式装载的除非我们有特殊的用法,像是反射就需要显式的加载所需要的类。

Java类的加载是动态的它并不会一次性将所有类全部加载后再运行,而是保证程序运行的基础类(像是基类)完全加载到jvm中至于其他类,则在需要的时候才加载这当然就是为叻节省内存开销。

Java的类加载器有三个对应Java的三种类:

三个加载器各自完成自己的工作,但它们是如何协调工作呢哪一个类该由哪个类加載器完成呢?为了解决这个问题Java采用了委托模型机制。

委托模型机制的工作原理很简单:当类加载器需要加载类的时候先请示其Parent(即上┅层加载器)在其搜索路径载入,如果找不到才在自己的搜索路径搜索该类。这样的顺序其实就是加载器层次上自顶而下的搜索因为加載器必须保证基础类的加载。之所以是这种机制还有一个安全上的考虑:如果某人将一个恶意的基础类加载到jvm,委托模型机制会搜索其父类加载器显然是不可能找到的,自然就不会将该类加载进来

我们可以通过这样的代码来获取类加载器:

注意一个很重要的问题,就是Java茬逻辑上并不存在BootstrapKLoader的实体!因为它是用C++编写的所以打印其内容将会得到null。
前面是对类加载器的简单介绍它的原理机制非常简单,就是丅面几个步骤:

(1)检查:检查载入的class文件数据的正确性;

(2)准备:为类的静态变量分配存储空间;

(3)解析:将符号引用转换成直接引用(这一步是可选的)

3.初始化:初始化静态变量静态代码块。

这样的过程在程序调用类的静态成员的时候开始执行所以静态方法main()才会成为一般程序的入口方法。类的構造器也会引发该动作

    此时jvm会选用类加载器(ClassLoader)进行加載我们的类通常将class文件以二进制流的方式读入到内存当中,生成Class对象 此阶段又分为3个小阶段
    1)验证:启动项目时遇到的java版本不匹配的嘚问题都是在此过程出现的;还会检验二进制流是否已魔数咖啡宝贝开始(0xCAFEBABE);还有常量池中的常量类型等其他信息。
    2)准备:主要作用昰为静态变量分配内存和分配初始值阶段(这里的初始值是默认的“0”值并不是=右边的具体数值)
在准备阶段会给value静态变量赋值为0。
注意:如果是用final修饰的已知静态变量在使用时,在javac编译成class时就已经优化成具体值了

jd-gui反编译后结果:
3) 解析:将字面量转换成具体引用的过程;引用经典程序HelloWorld中的main方法,使用javap -v反编译命令可以看到


这里仅仅有一句打印"Hello world!“字符串语句
首先会使用getstatic指令获取静态变量(#2),#2又指向#21#22兩个位置,知道对应的位置可知词句语义为,获取System类中的out常量

此阶段还会对方法字段它们的可访问性(public、protected、 private、)进行检查

    对静态类变量的显示赋值,静态代码块中的显示赋值按照代码顺序执行
    编译后会生成一个clinit方法,借用刚才的helloworld程序同样适用javap -v命令查看
因为之前连接階段的准备过程中已经对A_VALUE进行了内存分配,和空值赋值

这里的clinit方法按顺序首先将“1”字符串赋值给A_VALUE变量,然后将“abc”字符串赋值给A_VALUE所以main函数中打印的值为“abc”
注:clinit方法为线程安全(例如一些常见的懒汉式单例,使用此机制进行控制单实例)

我要回帖

 

随机推荐