【深入理解java虚拟机】-- 虚拟机类加载机制

本系列内容,大量引用自《深入理解java虚拟机》。

类加载时机

​ 类在虚拟机中整个声明周期包括:加载、验证、准备、解析、初始化、使用和卸载7个阶段。其中验证、准备、解析3个部分统称为连接。

​ 加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的(按照顺序按部就班的开始,是不是按照顺序完成就不一定了),而解析阶段则不一定:它在某种情况下可以在初始化阶段之后再开始,这是为了支持Java语言的运行时绑定(也称为动态绑定或晚期绑定)。

类加载过程

加载

“加载”是“类加载”过程的一个阶段,在加载阶段,虚拟机需要完成三件事情:

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

“通过一个类的全限定名来获取定义此类的二进制字节流”,并没有指明二进制字节流要从要给Class文件中获取,准确的说是根本没有指明要从哪里获取,怎样获取。

  • 从ZIP包获取,我们常见的JAR,EAR,WAR
  • 从网络获取,这种场景最典型的就是Applet
  • 运行时计算生成,这种场景使用得最多的就是动态代理技术,在java.lang.reflect.Proxy中,就是用了proxyGenerator.generateProxyClass来为特定接口生成形式为“*$Proxy”的代理类的二进制字节流。
  • 其他文件生成,典型的就是由JSP文件生成对应的Class类。
  • 从数据库读取,比较少见。有些中间件服务器可以选择把程序安装到数据库中来完成程序代码在集群间的分发

相对于类加载过程的其他阶段,一个非数组类的加载阶段是开发人员可控性最强的,可以选择使用系统提供的引导类加载器来完成,也可以由用户自定义的类完成(例如重写一个类加载器的loadClass方法)。

​ 而数组类本身不通过类加载器创建,它是由虚拟机直接创建的。但是数组类与类加载器仍然存在关系,因为数组类的元素类型最终是要由类加载器去创建,一个数组类创建的过程遵循以下规则:

  • 如果数组的组件类型是引用类型,那就递归加载过程去加载这个组件类型。

  • 如果不是组件类型(例如int[]),java虚拟机会将把数组标记为与与引导类加载器关联。

  • 数组类的可见性与其他的组件类型的可见性一直,如果组件类型不是引用类型,那数组类的可见性将默认为public。

​ 加载阶段完成后,虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区。然后再内存中实例化一个Java.lang.Class类对象。这个对象将作为程序访问方法区中的这些类型数据的外部接口。

验证

​ 验证时连接阶段的第一步,确保Class文件的字节流包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全。

​ 验证阶段大致上会完成下面4个阶段的校验动作:

  1. 文件格式验证

    1. 是否以魔数0xCAFEBABE开头。
    2. 主、次版本号是否在当前虚拟机处理范围之内。
    3. 常量池中的常量是否有不被支持的常量类型(检查常量tag标志)。
    4. CONSTANT_Utf8_info类型的常量中是否有不符合UTF8编码的数据。
    5. Class文件中各个部分及文件本身是否有被删除的或者附加的其他信息
    6. ……
  2. 元数据验证

    1. 这个类是否有父类(除了java.lang.Object之外,所有类都应该有父类)
    2. 这个类是否继承了不允许被继承的类(被final修饰的类)
    3. 如果不是抽象类,是否实现了其父类或接口中要求实现的所有方法
    4. 类中的字段、方式是否与父类产生矛盾(例如覆盖了父类的final字段,或者出现不符合规范的方法重载)
  3. 字节码验证

    第三阶段时整个验证过程中最复杂的阶段,主要目的是通过数据流和控制流分析,确定程序语义是否合法、符合逻辑。保证被校验类的方法在运行时不会出现危害虚拟机安全的事件
    1. 保证任何时刻操作数栈的数据类型与指令代码序列都能配合工作。例如不会出现:在操作数栈方值了一个int类的的数据,使用时却按照long类型来加入到本地变量表中。
    2. 保证跳转指令不会跳转到方法体以外的字节码指令上。
    3. 保证方法体中的类型转换是有效的,例如把父类对象赋值给子类数据类型,甚至把对象赋值给与他毫无继承关系、完全不相干的一个数据类型,则是危险且不合法的。
  4. 符号引用验证

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

    1. 符号引用中通过字符串描述的全限定名是否能找到对应的类。

    2. 在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段。

    3. 符号引用中的类、字段、方法的访问性是否可以被当前类访问

    ​ 如果无法通过符号引用验证,那么会抛出一个java.lang.IncompatibleClassChangeError异常的子类,如java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。

    ​ 对于虚拟机类加载机制来说,验证是一个非常重要的的、但不一定必须要的阶段(对运行期无影响)。如果所运行的全部代码(包括自己编写的代码)都已经被反复使用和验证过,那么可以考虑使用-Xverify:none参数来关闭大部分的类验证措施,以缩短虚拟机类加载时间。

准备

​ 准备阶段是正式为类变量分配内存并设置类变量初始值的阶段,这些变量所使用的内存都将在方法区中进行分配。注意,类变量(被static修饰的变量)不包括实例变量,实例变量会在对象实例化时随对象一起分配在Java堆中。其次,这里说的初始值“通常情况”时数据类型的零值,假设一个类变量定义为:

1
public static int value = 123;

那变量value在准备阶段过后的初始值为0为不是123,把value赋值为123的动作将在初始化阶段才会执行。有一个例外,如果字段属性表中存在ConstantValue属性,那么在准备阶段就会初始为ConstantValue属性指定的值,例如:

1
public static final int value = 123;

解析

​ 解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程,符号引用前面讲Class文件格式出现过多次,在Class文件中它以CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等类型的常量出现,那么解析阶段所说的直接引用与符号引用的关系又有什么关联呢?

  • 符号引用:以一组符号来描述所引用的目标,符号可以是任何形式的字面量,只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现地内存布局不管,引用的目标并不一定已经加载到内存中。各种虚拟机实现的内存布局可以各不相同,但是它们能接受地符号引用必须是一致的,因为符号引用的字面量形式明确定义在java虚拟机规范的Class文件格式中。
  • 直接引用:直接引用可以是直接指向目标的指针、相对偏移量或是一个能直接定位到目标的句柄。直接引用和虚拟机实现的内存布局相关,同一个符号引用在不同虚拟机实力上翻译出来的直接引用一般不会相同。如果有了直接引用,那引用的目标必定已经在内存中存在。

初始化

​ 类初始化阶段是类加载过程的最后一步。到了初始化,才真正开始执行类中定义的Java程序代码

​ java虚拟机规范并没有强制约束类什么时候加载,但是对于初始化阶段,虚拟机严格规定了5种情况必须对类进行“初始化”(加载、验证、准备自然需要在此之前开始):

  1. 需要new、getstatic、putstatic或invokestatoc这4条字节码指令时,如果类没有进行过初始化。则需要先触发其初始化。使用整个4条指令常见的Java代码场景时:使用new实例化对象、读取或者设置一个类的静态字段(不包括被final修饰的,因为编译的时候已经把结果放入到了常量池中),以及调用一个类的静态方法的时候。
  2. 使用Java.lang.reflect包的方法对类进行反射调用的时候,如果类没有进行过初始化,则需要先触发其初始化。
  3. 当初始化一个类,如果发现父类还没有进行过初始化,则需要先触发父类的初始化。
  4. 虚拟机启动时,用户需要指定一个要执行的主类,虚拟机会先初始化这个主类(包括main()方法的那个类)。
  5. 当使用动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_pubStatic、REF_invokeStatic的方法句柄、并且这个方法句柄所对应的类没有进行过初始化、则需要先触发其初始化。

​ 对于这5中会触发类进行初始化的场景、虚拟机规范中使用了一个很强烈的限定语:“有且只有”,这5中场景中的行为称为对一个类进行主动引用。除此之外,所有引用类的方法都不会触发初始化,称为被动引用。例如:通过子类引用父类的静态字段。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Father{
static{
System.out.print('father init');
}
public static int value = 123;
}

class Children extends Father{
System.out.print('children init');
}

main(){
System.out.print(Children.value);
}

​ 此时只会输出“father init”,而不会输出“children init”。对于静态字段,只有直接定义这个字段的类才会被初始化,因此通过其子类来引用父类中定义的静态字段,只会触发父类的初始化而不会触发子类的初始化。致于是否要触发子类的加载和验证,虚拟机终规范中没有明确规定。对于Hot Spot虚拟机来说,可通过-XX:+TraceClassLoading参数观察到此操作会导知子类的加载。

类加载器

类与类加载器

​ 类加载虽然只用于实现类的加载动作,但是它的作用远远不限于此。对于任意一个类,都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性,每一个类加载器,都拥有一个独立的类名称空间。通俗点就是说,两个类是否相等,不仅需要来源同一个Class文件,还需要被同一个虚拟机架加载。

​ 这里的”相等”,包括代表类的Clas对象的equals()方法,isAssignableForm()方法、isInstance()方法的返回结果,也包括使用instanceof判定对象所属关系等情况。

双亲委派模型

从java虚拟机的角度来讲,只存在两种不同加载器:

  1. 启动类加载器(Bootstrap ClassLoader),这个类加载器使用C++语言实现,是虚拟机自身的一部分
  2. 所有其他类加载器,都有java语言实现,独立于虚拟机外部,并且全部都继承自抽象类java.lang.ClassLoader。

从java开发人员角度来看,类加载器可以分的更细致,绝大部分java程序都会使用以下三种系统提供的类加载器。

  1. 启动类加载器(Bootstrap ClassLoader),就是上面介绍的,主要负责讲存在\lib目录中的,或者被-Xbootclasspath参数所指定的路径中的,并且是虚拟机识别的类库加载到虚拟机内存中。启动类加载器无法被java程序直接引用,用户在编写自定义类加载器时,如果需要把加载请求委派给引导类加载器,那直接使用null代替即可。

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

  3. 引用程序类加载器(Application ClassLoader):这个类加载由sun,misc.Launcher$App-ClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值,所以一般也称它为系统类加载器。它负责加载用户类路径(ClassPath)上所指定的类库,开发者可以直接使用这个类加载器,如果应用程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。

    我们应用程序都是由这三种类加载机相互配合加载的,如果有必要还可以加入自己定义的类加载器。它们之间的关系如图:

​ 图中展示的类加载器之间的这种层级关系,称之为类加载器的双亲委派模型。双亲委派模型要求除了顶层的启动类加载器外、其余的类加载器都应当有自己的父类加载器。这里的类加载器之间的关系一般不会以继承的关系实现,而是都使用组合关系来复用父加载器的代码。

双亲委派模型的工作过程是:如果一个类收到了类加载的请求,他首先不会自己去尝试加载这个类,而是把这个请求委托给父类加载器去完成,每一个层级的类加载器都是如此,因此所有的加载请求最终都应该传送到顶层的启动类加载器,只有当父类加载器反馈自己无法完成这个加载请求时(它的搜索范围类没有找到所需的类),子加载器才会尝试自己去加载。

​ 双亲委派模型好处就是Java类随着它的类加载器一起具备了一种带有优先级的层级关系。例如类Java.lang.Object,存放在rt.jar之中,无论哪一个类加载器要加载这个类,最终都是委派给处于模型最顶端的启动类加载器进行加载,因此Object类在程序的各种类加载器环境中都是同一个类。如果用户没有使用双亲委派模型,由各个类加载器自行去加载的话,如果用户自己编写了一个称为Java.lang.Object的类(实际上虚拟机不允许用户自己加载以“java.lang”开头的类,会抛出异常),并存放在程序的ClassPath中,那么系统中将会出现多个不同的Object类,java类型体系中最基础的行为也无法保证,引用程序也将会变得一片混乱。

​ 双亲委派模型实现非常简单,实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法中。大致流程:先检查是否已经被加载过,如果没有则调用父加载器的loadClass()方法,若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败,抛出ClassNotFoundException异常后,再调用自己的findClass()方法进行加载。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
//如果父类不为null,那么使用父类加载
if (parent != 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) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
//通过findClass方法,搜索class文件
c = findClass(name);

// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}

破坏双亲委派模型

​ 双亲委派并不是强制性的约束模型,而是java设计者推荐给开发者的类加载器实现方式。如果某些情况我们要突破这种模型的限制该如何做:其实java中也出现过双亲模型被破坏的情况。

  1. 上面loadClass方法的代码,就是一个被破坏的入口,当用户去继承java.lang.ClassLoader并重写loadClass方法,那么双亲委派模型就会被打破,想符合双亲委派模型也很简单,只需要重写findclass方法,最终通过defineClass方法将找到的类加入到虚拟机即可。

  2. 还有一种情况是由这个模型自身缺陷所导致的,双亲委派模型中,我们加载类都是委托给父类加载,最终经过启动类加载器,可能访问到启动类加载器中加载的java.lang.Object类,如果此时Object需要调回用户代码的时候呢。

    一个典型的例子便是JNDI,JNDI现在已经时java标准服务,他的代码由启动类加载器去加载,但是JNDI的目的就是对资源进行集中管理和查找,它需要调用由独立厂商实现并部署在引用程序的ClassPath下的JDNI接口提供者(SPI,Service Provider Interface)的代码,但是启动类加载器不可能”认识“这些代码。为了解决这个问题,java设计团队引入了一个不太优雅的设计:线程上下文加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置,如果创建线程时还未被设置,它将从父线程中继承一个,如果应用在全局范围内都没有设置过,那这个类加载器默认就是应用程序类加载器。

    ​ 有了线程上下文加载器,JDNI服务就可以使用这个线程上下文加载器去加载所需要的SPI代码,也就是父类记载器亲求子类加载器去完成类加载的动作,通过逆向使用类加载器,实际上已经违背了双亲委派模型的一般性原则。

  3. 第三次被“破坏”是由于用户对程序动态性的追求而导知的,这里说的“动态性”指的是:代码热替换(HotSwap)、模块部署(Hot Deployment)等。OSGI中实现模块化热部署的关键是它自定义的类加载器机制的实现。每个程序模块(OSGI中称为Bundle)都有一个自己的类加载器,当需要更换一个Bundle时,就要把Bundle连同类加载器一起替换掉一实现代码的热替换。

    在OSGI环境下,类加载不再是双亲委派模型中的树状结构,而是进一步发展为更加复杂的网状结构,当收到类加载请求时,OSGI将按照下面的顺序进行类搜索:
    1. 将以java.*开头的类委派给父类加载器加载。

    2. 否则,将委派列表名单内的类委派给父类加载器加载。

    3. 否则,将Import列表中的类委派给Export这个类的Bundle的类加载器加载。

    4. 否则,查找当前Bundle的ClassPath,使用自己的类加载器加载。

    5. 否则,查找类是否在自己的Fragment Bundel中,如果在,则委派给Fragment Bundel的类加载器加载

    6. 否则,查找Dynamic Import列表的Bundle,委派给对应Bundle的类加载器加载

    7. 否则,类查找失败。

      上面的查找顺序只有开头两点符合双亲委派规则,其余的类查找都是在平级的类加载器中进行的。

# ,

评论

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×