Kclass模型和JVM类加载过程详解_沮丧的南瓜-CSDN博客_kclass
一、Klass模型
Java的每个类,在JVM中,都有一个对应的Klass类实例与之对应,存储类的元信息如:常量池、属性信息、方法信息…… 看下klass模型类的继承结构 从继承关系上也能看出来,类的元信息是存储在原空间的; 普通的Java类在JVM中对应的是instanceKlass类的实例,再来说下它的三个字类
-
InstanceMirrorKlass:用于表示java.lang.Class,Java代码中获取到的Class对象,实际上就是这个C++类的实例,存储在堆区,学名镜像类
-
InstanceRefKlass:用于表示java/lang/ref/Reference类的子类
-
InstanceClassLoaderKlass:用于遍历某个加载器加载的类 Java中的数组不是静态数据类型,是动态数据类型,即是运行期生成的,Java数组的元信息用ArrayKlass的子类来表示:
-
TypeArrayKlass:用于表示基本类型的数组
-
ObjArrayKlass:用于表示引用类型的数组
二、类加载过程
1、加载
1、通过类的全限定名获取存储该类的class文件(没有指明必须从哪里获取); 2、解析运行时数据区,即instanceKlass实例,存放在方法区; 3、在堆区生成该类的Class对象,即instanceMirrorKlass对象。
1.2、何时加载
1、new、getstatic、putstatic、invokestatic 2、反射 3、初始化一个类的子类会去加载其父类 4、启动类(main函数所在类) 5、当使用jdk1.7动态语言支持时,如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getstatic,REF_putstatic,REF_invokeStatic的方法句柄,并且这个方法句柄所对应的类没有进行初始化,则需要先出触发其初始化(可以忽略)
预加载:包装类、String、Thread
1.3、从哪里加载 因为没有指明必须从哪获取class文件,脑洞大开的工程师们开发了这些 1、从压缩包中读取,如jar、war 2、从网络中获取,如Web Applet 3、动态生成,如动态代理、CGLIB 4、由其他文件生成,如JSP 5、从数据库读取 6、从加密文件中读取
2、验证
1、文件格式验证 2、元数据验证 3、字节码验证 4、符号引用验证
3、准备
为静态变量分配内存、赋初值 实例变量是在创建对象的时候完成赋值的,没有赋初值一说 如果被final修饰 ,在编译的时候会给属性添加ConstantValue属性,准备阶段直接完成赋值,即没有赋初值这一步。
4、解析
间接引用:指向运行时产量池的引用,符号引用,比如#32这个符号对应的是某个类的全限定名的字符串而已; 直接引用:类的内存地址,不再指向常量池
将常量池中的符号引用转为直接引用 解析后的信息存储在ConstantPoolCache类实例中 1、类或接口的解析 2、字段解析 3、方法解析 4、接口方法解析
我们使用javap -verbose Test_1.class 来查看静态常量池(查看的是class文件的):
public class Test_1 { public static void main(String[] args) { System.out.println("test_1"); } } Constant pool: #1 = Methodref #6.#20 // java/lang/Object."<init>":()V #2 = Fieldref #21.#22 // java/lang/System.out:Ljava/io/PrintStream; #3 = String #23 // test_1 #4 = Methodref #24.#25 // java/io/PrintStream.println:(Ljava/lang/String;)V #5 = Class #26 // com/jihu/test/jvm/Test_1 #6 = Class #27 // java/lang/Object #7 = Utf8 <init> #8 = Utf8 ()V #9 = Utf8 Code #10 = Utf8 LineNumberTable #11 = Utf8 LocalVariableTable #12 = Utf8 this #13 = Utf8 Lcom/jihu/test/jvm/Test_1; #14 = Utf8 main #15 = Utf8 ([Ljava/lang/String;)V #16 = Utf8 args #17 = Utf8 [Ljava/lang/String; #18 = Utf8 SourceFile #19 = Utf8 Test_1.java #20 = NameAndType #7:#8 // "<init>":()V #21 = Class #28 // java/lang/System #22 = NameAndType #29:#30 // out:Ljava/io/PrintStream; #23 = Utf8 test_1 #24 = Class #31 // java/io/PrintStream #25 = NameAndType #32:#33 // println:(Ljava/lang/String;)V #26 = Utf8 com/jihu/test/jvm/Test_1 #27 = Utf8 java/lang/Object #28 = Utf8 java/lang/System #29 = Utf8 out #30 = Utf8 Ljava/io/PrintStream; #31 = Utf8 java/io/PrintStream #32 = Utf8 println #33 = Utf8 (Ljava/lang/String;)V 1234567891011121314151617181920212223242526272829303132333435363738394041
可以看到这里的class只是一个符号引用。
然后我们启动并阻塞代码,使用HSDB来查看动态常量池:
public class Test_1 { public static void main(String[] args) { System.out.println("test_1"); while (true); } } 1234567
当运行代码后,此时类已经被解析了。此时可以看到,类的引用是真实的内存地址引用,不再指向常量池。
每一个类都拥有一个常量池!!!
5、初始化
类初始阶段,JVM底层会加锁,解决并发问题!
执行静态代码块,完成静态变量的赋值 静态字段、静态代码段,字节码层面会生成clinit方法 方法中语句的先后顺序与代码的编写顺序相关
定义一个static属性,JVM会自动生成一个clinit。 生成的clinit方法,代码顺序跟定义的顺序保持一致。
大家猜一下下面代码的运行结果:
结果是:1,1。 这里和定义的顺序有关系,存在值的覆盖。开始默认值为0, val2++之后为1,然后又设置为1.
三、JVM加载类模式是懒加载 Lazy loading
我们都知道rt.jar是有根加载器bootStrap加载的,事实上也只会加载一部分类,不是全部的类,这叫做预加载。预先加载的类是一些常用类,比如String,Thread, Integer等。
我们来看下面程序的运行结果: 类是在使用的时候加载,Test_1_B必须要要实例化对象,因为是静态字段,也没有任何调用,所以不需要初始化类。
我们再来看下面的代码: 此时需要实例化类对象才能访问到属性,所以会初始化类。
我们再来看下面的代码: 加载一个类的时候会优先加载父类!
再来看下面的代码: 再看看下面这个,你还能猜对的吗?
此时只是定义了数据类型,并没有实例化对象。
再来看一个final的:
final修饰的静态变量在准备阶段已经赋好了初始值,所以获取的时候不需要加载类。 final String str被写入了类Test_6_A的类常量池中,我们使用javap -verbose来查看class的静态常量池:
我们再来看一个UUID的: 是不是有点好奇?Why? 因为UUID.randomUUID()是动态运行的,JVM没办法确定该值,无法将其写入到类的常量池中!
反射也会加载类。
这里可能我们会有些迷惑,为什么子类对静态属性的操作没有生效呢?
我们要明确一点,JVM首先会判断类是否加载,只有当一个类加载后才会进行初始化操作!上面的代码中不需要加载子类,自然就不会初始化子类,即不会执行子类的静态代码块。
四、读取静态变量的底层实现
可以看到,在类Test1_A中是存在静态属性的,JDK6之后,静态属性是存在于镜像类instanceMirrorKlass中的;JDK6之前是存储在instanceKlass中的。
我们再来看看Test1_B中是否存在该静态属性:
此时我们发现没有找到Test1_B,因为在代码中我们调用的是:System.out.println(Test1_A.str); ,此时值加载了类Test_A这个父类,不需要加载Test1_B子类,所以没有在加载的类列表中找到该类。
我们修改代码: 此时是通过子类调用父类的属性,我们可以看到父类和子类都已经被加载了,这也验证了JVM类加载是懒加载,按需加载。
我们来看子类的instanceMirrowKlass中是否存在属性str: 从结果来看,该属性是不存在子类的镜像类中的。
可以猜得到,通过子类Test1_B访问父类Test1_A的静态字段有两种实现方式: 1、先去Test_1_B的镜像类中去取,如果有直接返回;如果没有,会沿着继承链将请求往上抛。很明显,这种算法的性能随继承链的death而上升,算法复杂度为O(n) 2、借助另外的数据结构实现,使用K-V的格式存储,查询性能为O(1)
Hotspot就是使用的第二种方式,借助另外的数据结构ConstantPoolCache,常量池类ConstantPool中有个属性_cache指向了这个结构。每一条数据对应一个类ConstantPoolCacheEntry。
ConstancePoolCache主要用于存储某些字节码指令所需的解析(resolve)好的常量项,例如给[get|put]static、[get|put]field、invoke[static|special|virtual|interface|dynamic]等指令对应的常量池项用。
ConstantPoolCacheEntry在哪呢?在ConstantPoolCache对象后面,看代码 \openjdk\hotspot\src\share\vm\oops\cpCache.hpp
ConstantPoolCacheEntry* base() const { return (ConstantPoolCacheEntry*)((address)this + in_bytes(base_offset())); } 123
这个公式的意思是ConstantPoolCache对象的地址加上ConstantPoolCache对象的内存大小
ConstantPoolCache
常量池缓存是为常量池预留的运行时数据结构。保存所有字段访问和调用字节码的解释器运行时信息。缓存是在类被积极使用之前创建和初始化的。每个缓存项在解析时被填充
如何读取 \openjdk\hotspot\src\share\vm\interpreter\bytecodeInterpreter.cpp
CASE(_getstatic): { u2 index; ConstantPoolCacheEntry* cache; index = Bytes::get_native_u2(pc+1); // QQQ Need to make this as inlined as possible. Probably need to // split all the bytecode cases out so c++ compiler has a chance // for constant prop to fold everything possible away. cache = cp->entry_at(index); if (!cache->is_resolved((Bytecodes::Code)opcode)) { CALL_VM(InterpreterRuntime::resolve_get_put(THREAD, (Bytecodes::Code)opcode), handle_exception); cache = cp->entry_at(index); } …… 1234567891011121314151617
从代码中可以看出,是直接去获取ConstantPoolCacheEntry.