Java类的运行顺序与Java加载机制
Author:[email protected] Date:
Java类的运行顺序
看下基本java代码的执行顺序,代码如图所属
基本运行顺序执
代码执行顺序解析
先运行到第 9 行,这是程序的入口。
然后运行到第 10 行,这里要 new 一个Demo,就要调用 Demo 的构造方法。
就运行到第 5 行,注意:可能很多人觉得接下来就应该运行第 6 行了,错!初始化一个类,必须先初始化它的属性。
因此运行到第 2 行,然后是第 3 行。
属性初始化完过后,才回到构造方法,执行里面的代码,也就是第 6 行、第 7 行。
然后是第8行,表示 new 一个Demo实例完成。
然后回到 main 方法中执行第 11 行。
然后是第 12 行,main方法执行完毕。
作为程序员,应该清楚程序的基本运行过程,否则糊里糊涂的,不利于编写代码,也不利于技术上的发展。
public class Main { private String name; private int age; public static class Demo{ String name = "微学苑"; int age = 3; } public static void main(String[] args){ Demo obj = new Demo(); System.out.println(obj.name + "的年龄是" + obj.age); } }
再来一个 题目考下大家:
class TestCodeSeg{ static{ System.out.println("1"); } { System.out.println("2"); } public TestCodeSeg(){ System.err.println("3"); } public static void main(String[] args){ new TestCodeSeg(); } }
输出结果是?
类加载机制基本概念
我们首先从宏观上回顾一下 java 类的编译执行的流程,大概如下图:
java 虚拟机把描述类的数据从 .class 文件加载到内存,并对数据进行校验、转换解析和初始化,最终形成可以被虚拟机直接使用的 java 类型,这就是虚拟机的加载机制。
.class 文件由类装载器装载后,在 JVM 中将形成一份描述 Class 结构的元信息对象,通过该元信息对象可以获知 Class 的结构信息:如构造函数,属性和方法等
Java允许用户借由这个Class 相关的元信息对象间接调用 Class 对象的功能, 这里就是我们经常能见到的 Class 类。如果你有看过前两篇文章关于反射的介绍:《java反射机制原理剖析》、《Java注解(批注)的基本原理》,你就知道,我们在反射中用到的 Class 对象其实就是从这里来的了。
本文主要介绍的就是其中的 类加载器 的工作。
类的加载过程
类从被加载到虚拟机内存中开始,到卸载出内存为止,它的整个生命周期包括:加载、验证、准备、解析、初始化、使用和卸载七个阶段。这七个阶段的发生顺序如下图所示:
其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段,这五个阶段的工作分别如下:
2.1. 加载:查找并加载类的二进制数据
加载是类加载过程的第一个阶段,在加载阶段,虚拟机需要完成以下三件事情:
通过一个类的全限定名来获取定义此类的的二进制字节流。
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
在内存中生成一个代表这个类的 java.lang.Class 对象, 作为方法区这个类的各种数据的访问入口。
相对于类加载的其他阶段而言,加载阶段(准确地说,是加载阶段获取类的二进制字节流的动作)是可控性最强的阶段,因为开发人员既可以使用系统提供的类加载器来完成加载,也可以自定义自己的类加载器来完成加载。下面我们会着重讲解类加载器这部分内容。
加载阶段完成后,虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中,而且在Java堆中也创建一个 java.lang.Class 类的对象,这样便可以通过该对象访问方法区中的这些数据。
2.2. 校验:检查载入Class文件数据的正确性
验证的目的是为了确保Class文件中的字节流包含的信息符合当前虚拟机的要求,而且不会危害虚拟机自身的安全。不同的虚拟机对类验证的实现可能会有所不同,但大致都会完成以下四个阶段的验证:
文件格式的验证:验证字节流是否符合Class文件格式的规范,并且能被当前版本的虚拟机处理,该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后,字节流才会进入内存的方法区中进行存储,后面的三个验证都是基于方法区的存储结构进行的。
元数据的验证:对类的元数据信息进行语义校验(其实就是对类中的各数据类型进行语法校验),保证不存在不符合Java语法规范的元数据信息。
字节码验证:该阶段验证的主要工作是进行数据流和控制流分析,对类的方法体进行校验分析,以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。
符号引用验证:这是最后一个阶段的验证,它发生在虚拟机将符号引用转化为直接引用的时候(解析阶段中发生该转化,后面会有讲解),主要是对类自身以外的信息(常量池中的各种符号引用)进行匹配性的校验。
2.3. 准备:给类的静态变量分配存储空间
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些内存都将在方法区中分配。对于该阶段有以下几点需要注意:
这时候进行内存分配的仅包括类变量(static),而不包括实例变量,实例变量会在对象实例化时随着对象一块分配在 java 堆中。
这里所设置的初始值通常情况下是数据类型默认的零值(如0、0L、null、false等),而不是被在 java 代码中被显式地赋予的值。
假设一个类变量的定义为:public static int value = 3;
那么变量 value 在准备阶段过后的初始值为 0,而不是 3,因为这时候尚未开始执行任何 java 方法,后面的初始化阶段会执行这个赋值语句,将 value 赋值为 3。
如果类字段的字段属性表中存在常量属性,即同时被 final 和 static 修饰,那么在准备阶段变量 value 就会被初始化为常量属性所指定的值。
假设上面的类变量 value 被定义为:public static final int value = 3;
编译时 javac 将会为 value 生成常量属性,在准备阶段虚拟机就会根据常量的设置将 value 赋值为 3。
2.4. 解析:将符号引用转成直接引用
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程,解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。符号引用就是一组符号来描述目标,可以是任何字面量。直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
2.5. 初始化:对类的静态变量,静态代码块执行初始化操作
初始化是类加载过程的最后一步,到了此阶段,才真正开始执行类中定义的 java 程序代码。在准备阶段,类变量已经被赋过一次系统要求的初始值,而在初始化阶段,则是根据程序员通过程序指定的主观计划去初始化类变量和其他资源,或者可以从另一个角度来表达:初始化阶段是执行类构造器 <clinit>()
方法的过程。
这里简单说明下 <clinit>()
方法的执行规则:
<clinit>()
方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的,编译器收集的顺序是由语句在源文件中出现的顺序所决定的,静态语句块中只能访问到定义在静态语句块之前的变量,定义在它之后的变量,在前面的静态语句中可以赋值,但是不能访问。<clinit>()
方法与实例构造器<init>()
方法(类的构造函数)不同,它不需要显式地调用父类构造器,虚拟机会保证在子类的<clinit>()
方法执行之前,父类的<clinit>()
方法已经执行完毕。因此,在虚拟机中第一个被执行的<clinit>()
方法的类肯定是 java.lang.Object。<clinit>()
方法对于类或接口来说并不是必须的,如果一个类中没有静态语句块,也没有对类变量的赋值操作,那么编译器可以不为这个类生成<clinit>()
方法。接口中不能使用静态语句块,但仍然有类变量(final static)初始化的赋值操作,因此接口与类一样会生成
<clinit>()
方法。但是接口与类不同的是:执行接口的<clinit>()
方法不需要先执行父接口的<clinit>()
方法,只有当父接口中定义的变量被使用时,父接口才会被初始化。另外,接口的实现类在初始化时也一样不会执行接口的<clinit>()
方法。虚拟机会保证一个类的
<clinit>()
方法在多线程环境中被正确地加锁和同步,如果多个线程同时去初始化一个类,那么只会有一个线程去执行这个类的<clinit>()
方法,其他线程都需要阻塞等待,直到活动线程执行<clinit>()
方法完毕。如果在一个类的<clinit>()
方法中有耗时很长的操作,那就可能造成多个线程阻塞,在实际应用中这种阻塞往往是很隐蔽的。
3. 触发类加载的条件
虚拟机规范严格规定了有且只有5中情况(jdk1.7)必须对类进行“初始化”(而加载、验证、准备自然需要在此之前开始):
遇到 new,getstatic,putstatic,invokestatic 这些字节码指令时,如果类没有进行过初始化,则需要先触发其初始化。生成这4条指令的最常见的 java 代码场景是:使用 new 关键字实例化对象的时候、读取或设置一个类的静态字段(被 final 修饰、已在编译器把结果放入常量池的静态字段除外)的时候,以及调用一个类的静态方法的时候。
使用 java.lang.reflect 包的方法对类进行反射调用的时候,如果类没有进行过初始化,则需要先触发其初始化。
当初始化一个类的时候,如果发现其父类还没有进行过初始化,则需要先触发其父类的初始化。
当虚拟机启动时,用户需要指定一个要执行的主类(包含main()方法的那个类),虚拟机会先初始化这个主类。
当使用 jdk1.7 动态语言支持时,如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getstatic, REF_putstatic, REF_invokeStatic 的方法句柄,并且这个方法句柄所对应的类没有进行初始化,则需要先出触发其初始化。
4. 类加载器
在 java 中内置有三类 ClassLoader:启动类加载器(Bootstrap ClassLoader)、扩展类加载器(ExtClassLoader)、应用类加载器(AppClassLoader)。不同的类加载器负责不同区域的类的加载。
启动类加载器:这个加载器不是一个 java 类,而是由底层c++实现的,负责加载存放在 $JAVA_HOME/jre/lib 目录中的类库,或者被
-Xbootclasspath
参数所指定的路径中的类库,比如 rt.jar。因为启动类加载器不属于 java 类库,无法被 java 程序直接引用,用户在编写自定义类加载器时,如果需要把加载请求委派给引导类加载器,那直接使用 null 代替即可。扩展类加载器:由 sun.misc.Launcher$ExtClassLoader 实现。负责加载 $JAVA_HOME/jre/lib/ext 目录下的,或者被 java.ext.dirs 系统变量所指定的路径中的所有类库,开发者可以直接使用扩展类加载器。
应用类加载器:由 sun.misc.Launcher$AppClassLoader 实现的。由于这个类加载器是 ClassLoader 中的 getSystemClassLoader 方法的返回值,所以也叫系统类加载器。它负责加载用户类路径(CLASSPATH)上所指定的类库,可以被直接使用。如果未自定义类加载器,默认为该类加载器。
我们可以通过这种方式打印加载路径及相关jar:
package qiushao.net; public class App { public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException { System.out.println("boot:" + System.getProperty("sun.boot.class.path")); System.out.println("ext:" + System.getProperty("java.ext.dirs")); System.out.println("app:" + System.getProperty("java.class.path")); } }
4.1 双亲委派模型
类加载器查找 Class(也就是在loadClass时)所采用的是双亲委托模式,所谓双亲委托模式就是:
首先判断该 Class 是否已经加载
如果没有加载则委托给父加载器进行查找,这样依次的进行递归,直到委托到最顶层的 Bootstrap ClassLoader
如果 Bootstrap ClassLoader 找到了该 Class,就会直接返回
如果没找到,则继续依次向下查找,如果还没找到则最后会交由自身去查找
具体流程见下图:
(图片来自http://liuwangshu.cn/application/classloader/1-java-classloader-.html)
红色虚线的箭头代表向上委托的方向,如果当前的类加载器没有从缓存中找到这个 Class 对象,就会请求父加载器进行操作。直到 Bootstrap ClassLoader。
黑色虚线的箭头代表的是查找方向,若 Bootstrap ClassLoader 可以从 $JAVA_HOME/jre/lib目录或者 -Xbootclasspath 指定目录查找到,就直接返回该对象,否则就让 ExtClassLoader 去查找。
ExtClassLoader 就会从 $JAVA_HOME/jre/lib/ext 或者 -Djava.ext.dir 指定位置中查找,找不到时就交给 AppClassLoader。
App ClassLoade 查找 CLASSPATH 目录下或者 -Djava.class.path 选项所指定的目录下的 jar 包和 .class文件,如果找到就返回,找不到交给我们自定义的类加载器 CustomClassLoader。
CustomClassLoader 是我们自定义的加载器,就要看我们怎么实现自定义 ClassLoader 的 findClass 方法了。
双亲委派模型是为了保证 java 核心库的类型安全。所有 java 应用都至少需要引用 java.lang.Object 类,在运行时这个类需要被加载到 java 虚拟机中。如果该加载过程由自定义类加载器来完成,可能就会存在多个版本的 java.lang.Object 类,而且这些类之间是不兼容的。通过双亲委派模型,对于 java 核心库的类的加载工作由启动类加载器来统一完成,保证了 java 应用所使用的都是同一个版本的 java 核心库的类,是互相兼容的。
下面我们来看一下双亲委派模型的代码是如何实现的。其实非常简单,相关的代码在 ClassLoader 类的 loadClass 方法:
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { //首先判断指定类是否已经被加载过 Class<?> c = findLoadedClass(name); if (c == null) { try { if (parent != null) { //如果当前类没有被加载且父类加载器不为null,则请求父类加载器进行加载操作 c = parent.loadClass(name, false); } else { //如果当前类没有被加载且父类加载器为null,则请求根类加载器进行加载操作 c = findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // ClassNotFoundException thrown if class not found // from the non-null parent class loader } if (c == null) { //如果父类加载器加载失败,则由当前类加载器进行加载 c = findClass(name); } } return c; }
4.2 自定义类加载器
系统提供的类加载器只能够加载系统配置目录下的 jar 包和 .class文件, 如果想要加载网络上或者指定的目录下的 jar 包或者 class 文件,我们可以实现一个自己的类加载器。自定义类加载器只需要继承 java.lang.ClassLoader 类,然后重写 findClass(String name) 方法即可,在方法中指明如何获取类的字节码流。下面来写个 Demo 试试看。
我们先编写一个测试类,用来被我们自定义的类加载器加载:
package qiushao.net; public class Person { public void say() { System.out.println("hello class loader"); } }
我们编译这个类生成 Person.class 文件,把这个文件放到 /home/qiushao/test/classloader/qiushao/net 目录下,然后删除 Person.java 源文件。
接下来我们就定义一个可以从指定目录加载 .class 文件的类加载器 TestClassloader:
接下来我们就可以使用这个自定义的类加载器来加载我们之前编译的 .class了
结果如下:
的确加载到了我们指定路径下的 Class。
参考文章:
类加载机制内容,来源于: qiushao.net/2020/02/18/Java/Java-类的加载机制介绍/
转载本站文章《Java类的运行顺序与Java加载机制》,
请注明出处:https://www.zhoulujun.cn/html/java/KeyConcepts/7704.html
延伸阅读:
- Chrome的控制台:Console标签调试代码的函数分析
- Javascript模块化编程
- js基础知识思维导图—JavaScript各个知识模块图解
- ECMAScript进化史(1):话说Web脚本语言王者JavaScript的加冕历史
- 再谈Java数据结构—分析底层实现与应用注意事项
- @SuppressWarnings(unchecked)作用解释.doc
- JSHint 配置详解与使用说明
- jsp和php综合性对比
- php vs jsp
- 从λ演算到函数式编程聊闭包(1):闭包概念在Java/PHP/JS中形式
- 浏览器把JSON导出转为excel下载到本地
- JS关键字和保留字汇总
- 从λ演算到函数式编程聊闭包(2):彻底理解JavaScript闭包规则
- ECMAScript进化史(3):ES5/ES6/ES7/ES8/ES9/ES10新特性大盘点
- 基于ZooKeeper的分布式Session实现
- session机制详解以及session的相关应用
- Java方法重载
- JavaBean的详细及引用
- 各个JSON技术的比较
- json字符串多层嵌套解释成java对象——java解释多层嵌套json
- Java中print、printf、println的区别
- java中HashMap类用法
- WEB-INF目录下的jsp页面如何访问WebRoot中的CSS和JS文件
- jsp <% <% ! 区别
- JSP总结
- JSP中动态include与静态include的区别介绍