从HotSpot虚拟机源码了解Java的访问控制修饰符

云计算 虚拟化
前面Ribbon源码分析文章,有读者留言提问:XX类是包私有的,重写不会报错吗?答案其实是XX类并非包私有,而是一个protected的静态内部类,所以重写不会报错。

 [[340301]]

前面Ribbon源码分析文章,有读者留言提问:XX类是包私有的,重写不会报错吗?答案其实是XX类并非包私有,而是一个protected的静态内部类,所以重写不会报错。

关于Java访问控制修饰符的作用,笔者在初学Java时也是靠记,写多了代码自然也就能理解,但笔者很好奇底层的实现,所以也尝试从HotSpot虚拟机源码寻找答案,解答我多年来的疑惑。

类、字段、方法都有哪些访问控制修饰符?

私有<private>、子类可访问<protected>、公开public、包私有<package>,默认不加访问控制修饰符就是包私有。

访问范围 private package protected public
同一个 可访问 可访问 可访问 可访问
同一包中的其他类 不可访问 可访问 可访问 可访问
不同包中的子类 不可访问 不可访问 可访问 可访问
不同包中的非子类 不可访问 不可访问 不可访问 可访问

包私有<package>指的是只有同一个包下的类可访问,其它包下的类不可访问。

今天我们就深入java虚拟机去探究这些访问控制修饰符语意的实现。

InstanceKlass是HotSpot VM中对应class文件结构的数据结构,InstanceKlass对象是一个Java类被HotSpot VM加载后所生成的C++对象,被存于方法区。我们在Java代码中使用的Class对象实际是InstanceKlass的一个镜像。

Java支持使用"this."、"suppor."、"某个对象."调用一个方法,或"某个类."调用静态方法,在我们看来是调用某个类的静态方法或者对象的方法,但这在虚拟机中并不存在区别,都是一个方法调用。

调用静态方法和对象方法的区别只在于,调用对象的方法需要在方法参数传递一个"this"引用,这是一个隐式参数,在编译器将Java代码编译成字节码时自动添加上。

而Java代码中使用"this."、"suppor."调用自身方法和父类方法的不同,仅仅只是生成方法调用字节码指令的操作数指向的Methodref常量不同,方法的第一个隐式参数传递的对象都是同一个。Methodref常量指代一个方法的符号引用,包括类名、方法名、方法描述符。

我们知道,类加载过程包括加载、链接、初始化三个阶段,其中链接阶段又可细分为验证、准备和解析三个阶段。下面这张图有助于我们理解类加载的几个阶段,但并不准确。

《Java虚拟机规范》只是规定类加载需要完成的事情,而对顺序并没有严格的要求。

下图为笔者阅读HotSpot虚拟机类加载源码总结出的一张流程图,仅供参考。(如需要获取原图,可在公众号回复:"hotspot")

在HotSpot虚拟机中,链接阶段的准备阶段在加载阶段之后完成,链接阶段的验证也分多种验证,其中文件格式验证、元数据验证在加载阶段交叉完成,而字节码验证阶段则在类初始化之前才触发,解析阶段则在类加载完成之后。

引起类初始化的几条指令如new、getstatic、putstatic、invokestatic,虚拟机在执行这些指令时,先判断类是否已经初始化,未初始化则完成类的初始化,链接阶段会在类初始化阶之前触发。

链接阶段的解析阶段是Java虚拟机将常量池内的符号引用替换为直接引用的过程,根据《Java虚拟机规范》规定,在ane-warray、checkcast、getfield、getstatic、instanceof、invokedynamic、invokeinterface、invoke-special、invokestatic、invokevirtual、ldc、mulianewarray、new、putfield、putstatic这些要求操作数指向常量池中的符号引用常量(如:CONSTANT_Class_info、CONSTANT_Field_info、CONSTANT_Methodref_info)的指令执行之前,必须先对使用的符号引用进行解析。

符号引用以一组符号描述引用的目标,如CONSTANT_Class_info表示引用的类、CONSTANT_Field_info表示引用哪个类的哪个字段、CONSTANT_Methodref_info表示引用哪个类的哪个方法。

符号引用验证发生在解析阶段,符号引用验证包括:通过字符串描述的全限定名是否能找到对应的类、在指定的类中是否存在简单名称所描述的方法和字段、符号引用中的类、字段、方法的可访问性( 、public、 )。

在HotSpot虚拟机的实现中,对于解释执行与动态调用(invokedynamic),解析阶段是在符号引用将要被使用前才去解析。

方法调用源码:javaCalls.cpp; 链接解析源码:linkResolver.cpp;

  1. // 检查类 
  2. LinkResolver::check_klass_accessability 
  3. // 检查方法 
  4. LinkResolver::check_method_accessability 
  5. // 检查字段 
  6. LinkResolver::check_field_accessability 

这些方法调用最后都调用Reflection类的对应verify方法完成是否可访问的判断,例如Reflection::verify_field_access方法。

Java虚拟机在解析class文件结构时、在字节码验证阶段,也会对访问控制修饰符进行验证。

例如,在解析class文件结构时,验证是否能够继承父类(Reflection::verify_class_access):

类的访问修饰符决定了一个类是否可以被其它类访问。在解析class文件结构阶段,虚拟机可以验证当前类是否能够继承父类(父类的访问控制修饰符决定)、是否能够实现每个接口(接口的访问修饰符决定)。

在字节码验证阶段则验证当前类是否可以访问目标类的protected修饰的方法或字段:

在字节码验证阶段,虚拟机会对类的每个方法中的每条字节码指令都会进行验证,但虚拟机在字节码验证阶段,只对getfield指令做了check_protected验证。可见,字节码验证阶段没有做过多的访问控制验证。

本文转载自微信公众号「 Java艺术」,可以通过以下二维码关注。转载本文请联系 Java艺术公众号。

[[340304]]

 

责任编辑:武晓燕 来源: Java艺术
相关推荐

2009-06-19 10:51:39

Scalapackage访问修饰符

2009-06-12 13:37:47

访问权限修饰符Java教程

2009-08-24 16:49:39

C#修饰符

2021-09-10 00:34:22

Java 线程启动

2009-09-04 11:06:40

C#访问修饰符

2010-11-05 09:47:11

OracleJava虚拟机

2009-06-12 14:46:05

static修饰符Java教程

2015-08-18 09:25:11

Java修饰符关键词

2011-06-02 14:51:07

JAVA修饰符

2012-08-06 09:26:19

Java虚拟机垃圾回收

2021-11-21 22:36:18

Java修饰符开发

2009-08-27 11:12:03

C# abstract

2009-08-21 13:58:06

C# virtual修

2009-08-27 13:06:13

C# new修饰符

2009-09-02 17:14:28

C#修饰符

2023-12-29 09:01:27

SwiftUI视图修饰符

2009-08-27 11:04:08

C# extern修饰

2023-09-25 08:19:37

LinuxVirtualBox虚拟机

2015-01-06 09:47:55

Java

2009-09-02 17:04:35

C# Extern修饰
点赞
收藏

51CTO技术栈公众号