实验简介
JVM为Java程序提供运行时环境,其中一项重要的任务就是管理类和对象的生命周期。类的生命周期从类被加载、连接和初始化开始,到类被卸载结束。当类处于生命周期中时,它的二进制数据位于方法区内,在堆区内还会有一个相应的描述这个类的Class对象。只有当类处于生命周期中时,Java程序才能使用它,比如调用类的静态属性和方法,或者创建类的实例。
预期效果
了解类成为对象的加载过程。
实验目的
1.了解类加载器。
2.了解加载流程。
实验流程
JVM将类加载过程分为三个步骤:装载(Load),链接(Link)和初始化(Initialize),链接又分为三个步骤:
装载:查找并加载类的二进制数据;
链接:
验证:确保被加载类的正确性;
准备:为类的静态变量分配内存,并将其初始化为默认值;
解析:把类中的符号引用转换为直接引用;
初始化:为类的静态变量赋予正确的初始值;
实例化:类成为对象
类加载过程
类的加载
是指把类的.class文件中的二进制数据读入到内存中,把它存放在运行时数据区的方法区内,然后再堆区创建一个java.lang.class对象,用来封装类在方法区内的数据结构。
Java虚拟机能够从多种来源加载类的二进制数据,包括:
从本地文件系统中加载类的.class文件,这是最常见的加载方式。
通过网络下载类的.class文件。
从ZIP、JAR或其他类型的归档文件中提取.class文件。
从一个专有数据库中提取.class文件。
把一个Java源文件动态编译为.class文件。
类的加载的最终产品是位于运行时数据区的堆区的Class对象。Class对象封装了类在方法区内的数据结构,并且向Java程序提供了访问类在方法区的数据结构的接口。
Class对象是Java程序与类在方法区内的数据结构的接口
类的加载是由类加载器完成的。类加载器可分为两种:
Java虚拟机自带的加载器,包括启动类加载器、扩展类加载器和系统类加载器。
用户自定义的类加载器。是java.lang.ClassLoader类的子类的实例,用户可以通过它来定制类的加载方式。
类的验证
当类被加载后,就进入连接阶段。连接就是把已读入到内存的类的二进制数据合并到虚拟机的运行时环境中去。连接的第一步是类的验证,保证被加载的类有正确的内部结构,并且与其他类协调一致。
类的验证主要包括以下内容。
类文件的结构检查:确保类文件遵从Java类文件的固定格式。
语义检查:确保类本身符合Java语言的语法规定,比如验证final类型的类没有子类,以及final类型的方法没有被覆盖。
字节码验证:确保字节码流可以被Java虚拟机安全地执行。字节码流代表Java方法(包括静态方法和实例方法),它是由被称做操作码的单字节指令组成的序列,每一个操作码后都跟着一个或多个操作数。字节码验证步骤会检查每个操作码是否合法,即是否有着合法的操作数。
二进制兼容的验证:确保相互引用的类之间协调一致。
类的准备
在准备阶段,Java虚拟机为类的静态变量分配内存,并设置默认的初始值。
类的解析
在解析阶段,Java虚拟机会把类的二进制数据中的符号引用替换为直接引用。
类的初始化
在初始化阶段,Java虚拟机执行类的初始化语句,为类的静态变量赋予初始值。在程序中,静态变量的初始化有两种途径:
(1)在静态变量的声明处进行初始化;
(2)在静态代码块中进行初书化。
例如在以下代码中,静态变量a和b都被显式初始化。而静态变量c没有被显式初始化,它将保持默认值0。
public class Sample { private static int a=1; //在静态变量的声明处进行初始化 public static long b; public static long c; static{ b=2; //在静态代码块中进行初始化 } ... }
静态变量的声明语句,以及静态代码块都被看做类的初始化语句,Java虚拟机会按照初始化语句在类文件中的先后顺序来依次执行它们。
Java虚拟机初始化一个类包含以下步骤。
假如这个类还没有被加载和连接,那就先进行加载和连接。
假如类存在直接的父类,并且这个父类还没有被初始化,那就先初始化直接的父类。
假如类中存在初始化语句,那就依次执行这些初始化语句。
当初始化一个类的直接父类时,也需要重复以上步骤,这会确保当程序主动使用一个类时,这个类及所有父类(包括直接父类和间接父类)都已经被初始化。程序中第一个被初始化的类是Object类。在例程(InitTester.java)中,Sub类是Base类的子类,因此当初始化Sub类时,会先初始化Base类。
类的初始化的时机
Java虚拟机只有在程序首次主动使用一个类或接口时才会初始化它。只有6种活动被看做是程序对类或接口的主动使用。
创建类的实例。用new语句创建实例,或者通过反射、克隆及反序列化手段来创建实例。
调用类的静态方法。
访问某个类或接口的静态变量,或者对该静态变量赋值。
调用Java API中某些反射方法,比如调用Class.forName(“Worker”)方法。
初始化一个类的子类,例如对Sub类的初始化,可看做是对它父类Base类的主动使用,因此会先初始化Base类。
Java虚拟机启动时被标明为启动类的类。
除了上述6种情形,其它使用Java类的方式都被看做是被动使用,都不会导致类的初始化。[[T] 下面结合具体的例子来解释类的初始化的时机。
1.对于final类型的静态变量,如果在编译时就能计算出变量的取值,那么这种变量被看做编译时常量。Java程序中对类的编译时常量的使用,被看做是对类的被动使用,不会导致类的初始化。当Sample类访问“Tester.a”时,并没有导致Tester类的初始化。
class Tester { public static final int a=2*3; //变量a是编译时常量 //public static final int a=(int)(Math.random()*5); //变量a不是编译时常量 static{ System.out.println(“int Tester”); } } public class Sample { public static void main(String args[]){ System.out.println(“a=”+Tester.a); //打印a=6 } }
2.当Java编译器生成Sample类的.class文件时,它不会在main()方法的字节码流中保存一个表示“Tester.a”的符号引用,而是直接在字节码流中嵌入常量值6。因此当程序访问“Tester.a”时,客观上无须初始化Tester类。
3.对于final类型的静态变量,如果在编译时不能计算出变量的取值,那么程序对类的这种变量的使用,被看做是对类的主动使用,会导致类的初始化。
4.当Java虚拟机初始化一个类时,要求它的所有父类都已经被初始化,但是这条规则并不适用于接口。
在初始化一个类时,并不会先初始化它所实现的接口。
在初始化一个接口时,并不会先初始化它的父接口。
因此,一个父接口并不会因为它的子接口或者实现类的初始化而初始化。只有当程序首次使用特定接口的静态变量时,才会导致该接口的初始化。
1.只要当程序访问的静态变量或静态方法的政权在当前类或接口中定义时,才可看做是对类或接口的主动使用。例如在例程10-2的Sample类的main()方法中访问“Sub.a”和“Sub.method()”,由于静态变量a和静态方法method()在Base父类中定义,因此Java虚拟机仅仅初始化Base类,而没有初始化Sub类。
2.调用ClassLoader类的loadClass()方法加载一个类,并不是对类的主动使用,不会导致类的初始化,例如在例程10-3(ClassB.java)中,先用系统类加载器加载ClassA,尽管ClassA被加载,但是没有被初始化。当程序调用Class类的静态方法——forName(“ClassA”)方法显式初始化ClassA时,才是对ClassA的主动使用,将导致ClassA被初始化,它的静态代码块被执行。
类加载器用来把类加载到Java虚拟机中。从JDK1.2版本开始,类的加载过程采用父亲委托机制,这种机制能更好地保证Java平台的安全。在此委托机制中,除了Java虚拟机自带的根类加载器以外,其余的类加载器都有且只有一个父加载器。当Java程序请求加载器loader1加载Sample类时,loader1首先委托自己的父加载器去加载Sample类,若父加载器能加载,则由父加载器完成加载任务,否则才由加载器loader1本身加载Sample类。
类加载器
Java虚拟机自带了一下几种加载器。
根(Bootstrap)类加载器:该加载器没有父加载器。它负责加载虚拟机的核心类库。根类加载器从系统属性sun.boot.class.path所指定的目录中加载类库。根类加载器的实现依赖于底层操作系统,属于虚拟机的实现的一部份,它并没有继承java.lang.ClassLoader类。
扩展(Extension)类加载器:它的父加载器为根类加载器。它从java.ext.dirs系统属性所指定的目录中加载类库,或者从JDK的安装目录的jre\lib\ext子目录(扩展目录)下加载类库,如果把用户创建的JAR文件放在这个目录下,也会自动由扩展类加载器加载。扩展类加载器是纯Java类,是java.lang.ClassLoader类的子类。
系统(System)类加载器:也称为应用类加载器,它的父加载器为扩展类加载器。它从环境变量classpath或者系统属性java.class.path所指定的目录中加载类,它是用户自定义的类加载器的默认父加载器。系统类加载器是纯Java类,是java.lang.ClassLoader类的子类。
除了以上虚拟机自带的加载器以外,用户还可以定制自己的类加载器(User-defined Class Loader)。Java提供了抽象类java.lang.ClassLoader,所有用户自定义的类加载器应该继承ClassLoader类。下图为各个加载器之间的父子关系。
类加载的双亲委托(Parent Delegation)机制
在双亲委托机制中,各个加载器安装父子关系形成了树形结构,除了根类加载器以外,其余的类加载器都有且只有一个父加载器。如图6-4所示,loader2的父亲为loader1,loader1的父亲为系统类加载器。下图为类加载器的双亲委托机制
假设Java程序要求loader2加载Sample类,代码如下:
Class sampleClass=loader.loadClass(“Sample”);
需要指出的是,加载器之间的父子关系实际上指的是加载器对象之间的包装关系,而不是类之间的继承关系。一对父子加载器可能是同一个加载器类的两个实例,也可能不是。在子加载器对象中包装了一个父加载器对象。
双亲委托机制的优点是能够提高软件系统的安全性。因为在此机制下,用户自定义的类加载器不可能加载应该由父加载器加载的可靠类,从而防止不可靠甚至恶意的代码代替由父加载器加载的可靠代码。
命名空间
每个类加载器都有自己的命名空间,命名空间由该加载器及所有父加载器所加载的类组成。在同一个命名空间中,不会出现类的完整名字(包括类的包名)相同的两个类;在不同的命名空间中,有可能会出现类的完整名字(包括类的包名)相同的两个类。
运行时包
由同一类加载器加载的属于相同包的类组成了运行时包。决定两个类是不是属于同一运行时包,不仅要看它们的包名是否相同,还要看定义类加载器是否相同。只有属于同一运行时包的类才能互相访问包可见(即默认访问级别)的类和类成员。这样的限制避免用户自定义的类冒充核心类库德类,去访问核心类库德包可见成员。
URLClassLoader类
在JDK的java.net包中,提供了一个功能比较强大的URLClassLoader类,它扩展了ClassLoader类。它不仅能从本地文件系统中加载类,还可以从网上下载类。Java程序可直接用URLClassLoader类作为用户自定义的类加载器。URLClassLoader类提供了以下形式的构造方法:
URLClassLoader(URL[] urls) //父加载器为系统类加载器
URLClassLoader(URL[] urls, ClassLoader parent) //parent参数指定父加载器
以上构造方法中的参数urls用来存放所有的URL路径,URLClassLoader将从这些路径中加载类。下面的代码片段演示了演示了URLClassLoader类的用法。
以上程序的打印结果如下:
Sample is loaded by java.net.URLClassLoader@5d87b2
Dog is loaded by java.net.URLClassLoader@5d87b2
用户自定义加载器
在JVM中允许用户自定义类加载器。在自定义加载器过程中,用户只需要继承ClassLoader类并重写loadClass方法,并完成自己想要的加载过程代码就行。但严格的来说,instanceof是否返回true,类型是否一致,最根本的判断是否由同一个类加载器进行类加载。换言之,如果同一个类,但被加载的过程中是由两个不同的类加载器完成,那么instanceof将返回为false。因此在JDK5.0以后用户自定义加载器时,JVM给用户提供了一个findClass方法以便于重写。用户自定义加载器时,利用双亲委托模型当父类loadClass无法加载时会自动调用findClass方法
类卸载
当Sample类被加载、连接和初始化后,它的生命周期就开始了。当代表Sample类的Class对象不再被引用,即不可触及时,Class对象就会结束生命周期,Sample类在方法区内的数据也会被卸载,从而结束Sample类的生命周期。由此可见,一个类何时结束生命周期,取决于代表它的Class对象何时结束生命周期。
由Java虚拟机自带的类加载器所加载的类,在虚拟机的生命周期中,始终不会被卸载。Java虚拟机自带的类加载器包括根类加载器、扩展加载器和系统加载器。Java虚拟机本身会始终引用这些类加载器,而这些类加载器则会始终引用它们所加载的类的Class对象,因此这些Class对象始终是可触及的。
由用户自定义的类加载器所加载的类是可以被卸载的。
JVM中的Class只有满足以下三个条件,才能被GC回收,也就是该Class被卸载(unload):
- 该类所有的实例都已经被GC,也就是JVM中不存在该Class的任何实例。
- 加载该类的ClassLoader已经被GC。
- 该类的java.lang.Class 对象没有在任何地方被引用,如不能在任何地方通过反射访问该类的方法.
由Java虚拟机自带的类加载器所加载的类,在虚拟机的生命周期中,始终不会被卸载。 前面介绍过,Java虚拟机自带的类加载器包括根类加载器、扩展类加载器和系统类加载器。 Java虚拟机本身会始终引用这些类加载器,而这些类加载器则会始终引用它们所加载的类的Class对象,因此这些Class对象始终是可触及的。 由用户自定义的类加载器加载的类是可以被卸载的。
loader1变量和obj变量间接应用代表Sample类的Class对象,而objClass变量则直接引用它。
如果程序运行过程中,将上图左侧三个引用变量都置为null,此时Sample对象结束生命周期,MyClassLoader对象结束生命周期,代表Sample类的Class对象也结束生命周期,Sample类在方法区内的二进制数据被卸载。
当再次有需要时,会检查Sample类的Class对象是否存在,如果存在会直接使用,不再重新加载;如果不存在Sample类会被重新加载,在Java虚拟机的堆区会生成一个新的代表Sample类的Class实例(可以通过哈希码查看是否是同一个实例)。
思考总结
1. 想想ClassLoader可以用来完成哪些需求?
下周推送:扩展知识:JVM中对象的分配