Java反射与类加载过程会擦出什么样的火花
Posted 活跃的咸鱼
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Java反射与类加载过程会擦出什么样的火花相关的知识,希望对你有一定的参考价值。
反射与类加载
一,反射机制原理
反射机制介绍
1.反射机制允许程序在执行期借助于ReflectionAPI取得任何类的内部信息(比如成员变量,构造器,成员方法等等)并能操作对象的属性及方法。反射在设计模式和框架底层都会用到.
2.加载完类之后,在堆中就产生了一个Class类型的对象(一 个类只有一个Class对象),这个对象包含了类的完整结构信息。通过这个对象得到类的结构。这个Class对象就像一面镜子,透过这个镜子看到类的结构,所以,形象的称之为:反射
反射机制原理分析
先看需求:通过反射创建出Cat类的对象。
public class Cat
private String name;
public Cat(String name)
this.name = name;
public String getName()
return name;
public void setName(String name)
this.name = name;
public void hi()
System.out.println("hello");
public class TestReflection
public static void main(String[] args) throws Exception
Class<?> clazz = Class.forName("com.Cat");
Constructor<?> constructor = clazz.getDeclaredConstructor(String.class);
Cat tomcat = (Cat)constructor.newInstance("tomcat");
System.out.println(tomcat.getName());
反射机制原理示意图:
Class<?> clazz = Class.forName("com.Cat");
在执行上述代码后会发生触发类加载过程
- Cat.java源文件会被编译为Cat.class字节码文件。
- jvm从本地磁盘中找到Cat.class文件并加载到jvm的内存中并且将类结构消息保存到方法区中。
- jvm在堆中会为每一个类生成一个对应的Class对象,Class对象中保存了该类的所有信息。
- jvm在程序运行时动态加载获取类信息,本质上是jvm得到jvm堆中的Class对象,然后对Class对象进行反编译。
- 得到反编译后的Class对象然后调用相关API操作Cat类中的所有方法和属性。
上述分析蕴含的问题非常多
- 类加载的时机
- 类加载的具体过程
- jvm方法区中存放的内容
- 什么是Class对象
- 哪些类型有Class对象
- 反射获得对象的方式有哪些
- 反射的优缺点
二,反射机制中的问题解答
类加载的时机
- 当创建对象时(new) //静态加载
- 当子类被加载时,父类也加载//静态加载
- 调用类中的静态成员时//静态加载
- 通过反射//动态加载
类加载的具体过程
- 类加载过程图
- 类加载各阶段完成任务
- 加载阶段:JVM在该阶段的主要目的是将字节码从不同的数据源(可能是class文件、也可能是jar包,甚至网络)转化为二进制字节流加载到内存中,并生成一个代表该类的java.lang.Class对象
- 连接阶段-验证:目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求,并且不会危害虚拟机自身的安全。包括:文件格式验证(是否以魔数oxcafebabe开头)、元数据验证、字节码验证和符号引用验证可以考虑使用-Xverify:none参数来关闭大部分的类验证措施,缩短虚拟机类加载的时间。
- 连接阶段-准备:JVM会在该阶段对静态变量,分配内存并默认初始化(对应数据类型的默认初始值,如0、0L、null、 false 等)。这些变量所使用的内存都将在方法区中进行分配
- 连接阶段-解析:虚拟机将常量池内的符号引用替换成直接引用
- Initialization(初始化):该阶段才真正开始执行类中定义的Java程序代码,此阶段是执行< clinit> ()方法的过程。
< clinit>()方法是由编译器按语句在源文件中出现的顺序,依次自动收集类中的所有静态变量的赋值动作和静态代码块中的语句,并进行合并。
虚拟机会保证一 个类的< clinit> ()方法在多线程环境中被正确地加锁、同步,如果多个线程同时去初始化一个类, 那么只会有一个线程去执行这个类的()方法,其他线程都需要阻塞等待,直到活动线程执行< clinit> () 方法完毕.
jvm方法区中存放的内容
方法区用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等。
什么是Class对象
- Class类也是类的一种父类也是Object,与class关键字是不一样的。
- 手动编写的类被编译后会产生一个Class对象,其表示的是创建的类的类型信息,该Class对象保存在同名.class的文件中(即编译后得到的字节码文件)。
- 每个通过关键字class标识的类,在内存中有且只有一个与之对应的Class对象来描述其类型信息,无论创建多少个实例对象,其依据的都是用一个Class对象。
- Class类只存私有构造函数,因此对应Class对象只能有JVM创建和加载
- Class类的对象的作用是运行时提供或获得某个对象的类型信息,这点对于反射技术很重要。
哪些类型有Class对象
外部类,成员内部类,静态内部类,局部内部类,匿名内部类
interface :接口 数组
enum :枚举 annotation :注解
基本数据类型 void
Class<String> cls1 = String.class;//外部类
Class<Serializable> cls2 = Serializable.class;//接口
Class<Integer[]> cls3 = Integer[].class;//数组
Class<float[][]> cls4 = float[][].class;//二维数组
Class<Deprecated> cls5 = Deprecated.class;//注解
Class<Thread.State> cls6 = Thread.State.class;//枚举
Class<Long> cls7 = long.class;//基本数据类型
Class<Void> cls8 = void.class;//void 数据类型
Class<Class> cls9 = Class.class;//Class本身
反射获得对象的方式有哪些
//Class.forName(全路径名)
1.Class.forName("com.Cat");
//类名.class
2. Cat.class;
//对象名.getClass()方法
3. cat.getClass();
反射的优缺点
优点:可以动态的创建和使用对象(也是框架底层核心),使用灵活,没有反射机制,框架技术就失去底层支撑。
缺点:使用反射基本是解释执行,对执行速度有影响。破坏了封装的特性。
三,反射中的常用API
java.lang.Class 类
方法名 | 作用 |
---|---|
getName () | 获取全类名 |
getSimpleName() | 获取简单类名 |
getFields() | 获取所有public修饰的属性,包含本类以及父类的 |
getDeclaredFields() | 获取本类中所有属性 |
getMethods() | 获取所有public修饰的方法,包含本类以及父类的 |
getDeclaredMethods() | 获取本类中所有方法 |
getConstructors() | 获取本类所有public修饰的构造器 |
getDeclaredConstructors() | 获取本类中所有构造器 |
getPackage() | 以Package形式返回包信息 |
getSuperClass() | 以Class形式返回父类信息 |
getInterfaces() | 以Class[]形式返回接口信息 |
getAnnotations() | 以Annotation形式返回注E解信息 |
java.lang.reflect.Field 类
方法名 | 作用 |
---|---|
getModifiers() | 以int形式返回修饰符 |
getName() | 返回属性名 |
getType() | 以Class形式返回类型 |
说明:
default是0,
public是1
private是2
protected是4
static是8
final是16 public(1) + static (8) = 9
java.lang.reflect.Method类
方法名 | 作用 |
---|---|
getModifiers() | 以int形式返回修饰符 |
getName() | 返回方法名 |
getParameter Types() | 以Class[]返回参数类型数组 |
getReturnType() | 返回一个 类对象,它表示由该表示的方法的正式返回类型 方法对象。 |
invoke(Object obj, Object… args) | 在具有指定参数的 方法对象上调用此 方法对象表示的底层方法。 |
java.lang.reflect.Constructor类
方法名 | 作用 |
---|---|
getModifiers() | 以int形式返回修饰符 |
getName() | 返回构造器名(全类名) |
getParameter Types() | 以Class[]返回参数类型数组 |
newInstance() | 使用指定的初始化参数来创建和初始化构造函数的声明类的新实例。 |
四, 类加载过程详解
类加载过程概述
在Java中数据类型分为基本数据类型和引用数据类型。基本数据类型由虚拟机预先定义,引用数据类型则需要进行类的加载。
按照Java虛拟机规范,从class 文件到加载到内存中的类,到类卸载出内存为止,它的整个生命周期包括如下7个阶段:
过程一: Loading (加载)阶段
1,加载完成的操作
加载的理解
所谓加载,简而言之就是将Java类的字节码文件加载到机器内存中,并在内存中构建出Java类的原型一类模板对象。
所谓类模板对象,其实就是Java类在JVM内存中的一个快照,JVM将 从字节码文件中解析出的常量池、类字段、类方法等信息存储到类模板中,这样JVM在运行期便能通过类模板而获取Java类中的任意信息,能够对Java类的成员变量进行遍历,也能进行Java方法的调用。
反射的机制即基于这一基础。 如果JVM没有将Java类的声明信息存储起来,则JVM在运行期也无法反射。
加载完成的操作
加载阶段,简言之,查找并加载类的二进制数据,生成Class的实例。在加载类时,Java虚拟机必须完成以下3件事情:
- 通过类的全名,获取类的二进制数据流。
- 解析类的二进制数据流为方法区内的数据结构(Java类模型)
- 创建java.lang . Class类的实例,表示该类型。作为方法区这个类的各种数据的访问入口
2,二进制流的获取方式
对于类的二进制数据流,虚拟机可以通过多种途径产生或获得。( 只要所读取的字节码符合JVM规范即可)
- 虚拟机可能通过文件系统读入一个class后缀的文件(最常见)
- 读入jar、zip等归档数据包,提取类文件。
- 事先存放在数据库中的类的二进制数据
- 使用类似于HTTP之类的协议通过网络进行加载
- 在运行时生成一段Class的二进制信息等
在获取到类的二进制信息后,Java 虚拟机就会处理这些数据,并最终转为一个java. lang. Class
的实例。
如果输入数据不是ClassFile的结构,则会抛出ClassFormatError.
3,类模型与Class实例的位置
1).类模型的位置
加载的类在JVM中创建相应的类结构,类结构会存储在方法区(JDK1.8之前: 永久代; JDK1.8及之后: 元空间)。
2). Class实例的位置
类将.class文件加载至元空间后,会在堆中创建一个Java. lang. Class对象,用来封装类位于方法区内的数据结构,该Class对象是在加载类的过程中创建的,每个类都对应有一个Class类型的对象。
3).图示
4,数组类的加载
创建数组类的情况稍微有些特殊,因为数组类本身并不是由类加载器负责创建,而是由JVM在运行时根据需要而直接创建的,但数组的元素类型仍然需要依靠类加载器去创建。创建数组类(下述简称A)的过程:
- 如果数组的元素类型是引用类型,那么就遵循定义的加载过程递归加载和创建数组A的元素类型;
- JVM使用指定的元素类型和数组维度来创建新的数组类。
如果数组的元素类型是引用类型,数组类的可访问性就由元素类型的可访问性决定。否则数组类的可访问性将被缺省定义为public。
过程二: Linking (链接)阶段
1-环节1:链接阶段之Verification (验证)
当类加载到系统后,就开始链接操作,验证是链接操作的第一步。它的目的是保证加载的字节码是合法、合理并符合规范的。
验证的内容则涵盖了类数据信息的格式验证、语义检查、字节码验证,以及符号引用验证等。
其中格式验证会和加载阶段一起执行。验证通过之后,类加载器才会成功将类的二进制数据信息加载到方法区中。格式验证之外的验证操作将会在方法区中进行。
具体说明:
- 格式验证:是否以魔数
OxCAFEBABE
开头,主版本和副版本号是否在当前Java虚拟机的支持范围内,数据中每一个项是否都拥有正确的长度等。 - Java虚拟机会进行字节码的语义检查,但凡在语义上不符合规范的,虚拟机也不会给予验证通过 。比如:
1)是否所有的类都有父类的存在(在Java里, 除了object外, 其他类都应该有父类), 是否一些被定义为final的方法或者类被重写或继承了
2)非抽象类是否实现了所有抽象方法或者接口方法, 是否存在不兼容的方法(比如方法的签名除了返回值不同,其他都一样, 这种方法会让虚拟机无从下手调度; abstract情况下的方法,就不能是final的了 ) - Java虛拟机还会进行字节码验证,字节码验证也是验证过程中最为复杂的一个过程。它试图通过对字节码流的分析,判断字节码是否可以被正确地执行。比如:在字节码的执行过程中,是否会跳转到一条不存在的指令, 函数的调用是否传递了正确类型的参数,变量的赋值是不是给了正确的数据类型等
栈映射帧(StackMapTable)就是在这个阶段,用于检测在特定的字节码处,其局部变量表和操作数栈是否有着正确的数据类型。
但遗憾的是,100%准确地判断一段字节码是否可以被安全执行是无法实现的,因此,该过程只是尽可能地检查出可以预知的明显,在前面3次检查中,已经排除了文件格式错误、语义错误以及字节码的不正确性。但是依然不能确保类是没有问题的。 - 校验器还将进行符号引用的验证。Class文件在其常量池会通过字符串记录自己将要使用的其他类或者方法。因此,在验证阶段,虚拟机就会检查这些类或者方法确实是存在的,并且当前类有权限访问这些数据,如果一个需要使用类无法在系统中找到,则会抛出
NoClassDefFoundError
,如果个 方法无法被找到,则会抛出NoSuchMethodError
.此阶段在解析环节才会执行。
2-环节2:链接阶段之Preparation (准备)
准备阶段(Preparation), 简言之,为类的静态变量分配内存,并将其初始化为默认值。当一个类验证通过时, 虚拟机就会进入准备阶段。在这个阶段,虚拟机就会为这个类分配相应的内存空间, 并设置默认初始值。
Java虛拟机为各类型变量默认的初始值如表所示。
注意:
Java并不支持boolean类型,对于boolean类型,内部实现是int,由于int的默认值是0,故对应的,boolean的默认值就是false.
注意:
- 这里不包含基本数据类型的字段用static final修饰的情况, 因为final在编译的时候就会分配了,准备阶段会显式赋值。
- 注意这里不会为实例变量分配初始化,类变量会分配在方法区中,而实例变量是会随着对象一 起分配到Java堆中。
- 在这个阶段并不会像初始化阶段中那样会有初始化或者代码被执行。
对注意中的第1点分析:
以下前3点的前提都是字段已经完成显示赋值(定义的后面已经赋了值)的前提下进行的
1、非final修饰的静态变量会在准备阶段赋初始值,然后在初始化中的方法中显示赋值
2、静态常量(基本数据类型、String类型字面量("XXX"这种情况) )在编译阶段会初始化赋值, 然后在准备阶段就会显示赋值
3、引用数据类型的静态常量,其是new String("XXX )这种形式,都是在初始化中的中进行显示赋值的
4、如果在static静态代码块中具有显示赋值操作(定义的后面没有赋值),那肯定就是在初始化中的 < client>方法中显示赋值
3-环节3:链接阶段之Resolution (解析)
解析阶段(Resolution),简言之,将类、接口、字段和方法的符号引用转为直接引用。
具体描述:
符号引用就是一些字面量的引用,和虚拟机的内部数据结构和和内存布局无关。比较容易理解的就是在Class类文件中,通过常量池进行了大量的符号引用。但是在程序实际运行时,只有符号引用是不够的,比如当如下println( )方法被调用时,系统需要明确知道该方法的位置。
举例:输出操作System. out . println( )对应的字节码:
invokevirtual #24 <java/io/PrintStream. println>
以方法为例,Java虚拟机为每个类都准备了一张方法表,将其所有的方法都列在表中,当需要调用一个类的方法的时候,只要知道这个方法在方法表中的偏移量就可以直接调用该方法。通过解析操作,符号引用就可以转变为目标方法在类中方法表中的位置,从而使得方法被成功调用。
过程三: Iitialization (初始化) 阶段
1-static 与final的搭配问题
/*
*说明:使用static + final修饰的字段的显式赋值的操作,到底是在哪个阶段进行的赋值?
*情况1:在链接阶段的准备环节赋值
*情况2:在初始化阶段<clinit>()中赋值
*结论:
*在链接阶段的准备环节赋值的情况:
* 1.对于基本数据类型的字段来说,如果使用static final 修饰,则显式赋值(直接賦值常量,而非调用方法)通常是在链接阶段的准备坏节进行
* 2.对于String来说, 如果使用字面量的方式赋值,使用static final修饰的话,则显式赋值通常是在链接阶段的准备环节进行
*在初始化阶段<clinit>()中赋值的情况:
*排除上述的在准备环节赋值的情况之外的情况。
*
*/
public class InitializationTest2
public static int a = 1;// 在初始化阶段<clinit>()中赋值
public static final int INT_CONSTANT =10;// 在链接阶段的准备环节赋值
public static final Integer INTEGER_CONSTANT1 =Integer.value0f(100);//在初始化阶段<clinit>()中赋值
public static Integer INTEGER_CONSTANT2 =Integer.value0f(1000);//在初始化阶段<clinit>()中赋值
public static final String s0 = "helloworlde";//在链接阶段的准备环节赋值
public static final String s1 = new String(original:"helloworld1");//在初始化阶段<clinit>()中赋值
public static String s2 = "helloworld2";
public static final int NUM1 = new Random().nextInt(bound:10);//在初始化阶段<clinit>()中赋值
2- < client> ()的线程安全性
对于< clinit>()方法的调用,也就是类的初始化,虚拟机会在内部确保其多线程环境中的安全性。
虚拟机会保证一个类的< clinit>()方法在多线程环境中被正确地加锁、同步,如果多个线程同时去初始化一个类,那么只会有一个线程去执行这个类的< clinit>()方法,其他线程都需要阻塞等待,直到活动线程执行< clinit>()方法完毕。
正是因为函数< clinit>( )带锁线程安全的,因此,如果在一个类的< clinit>()方法中有耗时很长的操作,就可能造成多个线程阻塞,引发死锁。并且这种死锁是很难发现的,因为看起来它们并没有可用的锁信息。
如果之前的线程成功加载了类,则等在队列中的线程就没有机会再执行< clinit>()方法了。那么,当需要使用这个类时,虚拟机会直接返回给它已经准备好的信息。
3-类的初始化情况:主动使用vs被动使用
一、主动使用
Class只有在必须要首次使用的时候才会被装载,Java虛拟机不会无条件地装载Class类型。Java虚拟机规定,一个类或接口在初次使用前,必须要进行初始化。这里指的“使用”,是指主动使用,主动使用只有下列几种情况: (即: 如果出现如下的情况,则会对类进行初始化操作。而初始化操作之前的加载、验证、准备已经完成。)
- 当创建一个类的实例时,比如使用new关键字,或者通过反射、克隆、反序列化。
- 当调用类的静态方法时,即当使用了字节码invokestatic指令。
- 当使用类、接口的静态字段时(final修饰特殊考虑),比如,使用getstatic或者putstatic指令。 (对应访问变量、赋值变量操作)
- 当使用java. lang. reflect包中的方法反射类的方法时。比如: Class. forName( “com. java. Test”)
- 当初始化子类时,如果发现其父类还没有进行过初始化,则需要先触发其父类的初始化。
- 如果一个接口定义了default方法,那么直接实现或者间接实现该接口的类的初始化,该接口要在其之前被初始化。
- 当虚拟机启动时,用户需要指定一个要执行的主类(包含main( )方法的那个类),虚拟机会先初始化这个主类。
- 当初次调用MethodHandle 实例时,初始化该MethodHandle指向的方法所在的类。 (涉及解析REF_ getStatic、 REF_ putStatic、 REF invokeStatic方法句柄对应的类)
针对5,补充说明:
当Java虚拟机初始化一个类时,要求它的所有父类都已经被初始化,但是这条规则并不适用于接口。
在初始化一个类时,并不会先初始化它所实现的接口,在初始化一个接口时,并不会先初始化它的父接口。因此,一个父接口并不会因为它的子接口或者实现类的初始化而初始化。只有当程序首次使用特定接口的静态字段时,才会导致该接口的初始化。
针对7,说明:
JVM启动的时候通过引导类加载器加载-一个初始类。这个类在调用public static void main(String[])方法之前被链 接和初始化。这个方法的执行将依次导致所需的类的加载,链接和初始化。
二、被动使用
除了以上的情况属于主动使用,其他的情况均属于被动使用。被动使用不会引起类的初始化。也就是说:并不是在代码中出现的类,就一定 会被加载或者初始化。如果不符合主动使用的条件,类就不会初始化。
- 当访问一个静态字段时,只有真正声明这个字段的类才会被初始化。当通过子类引用父类的静态变量,不会导致子类初始化
- 通过数组定义类引用,不会触发此类的初始化
- 引用常量不会触发此类或接口的初始化。因为常量在链接阶段就已经被显式赋值了。
- 调用ClassLoader 类的loadClass()方法加载一个类,并不是对类的主动使用,不会导致类的初始化。
过程四:类的Using (使用)
任何一个类型在使用之前都必须经历过完整的加载、链接和初始化3个类加载步骤。一旦一个类型成功经历过这3个步骤之后,便“万事俱备,只欠东风”,就等着开发者使用了。
开发人员可以在程序中访问和调用它的静态类成员信息(比如:静态字段、静态方法),或者使用new关键字为其创建对象实例。
过程五:类的Unloading (卸载)
一、类、类的加载器、类的实例之间的引用关系
在类加载器的内部实现中,用一个Java集合来存放所加载类的引用。另一方面,一个Class对象总是会引用它的类加载器, 调用Class对象的getClassLoader()方法, 就能获得它的类加载器。由此可见,代表某个类的Class实例与其类的加载器之间为双向关联关系.
一个类的实例总是引用代表这个类的Class对象。 在0bject类中定义了getClass()方法,这个方法返回代表对象所属类的Class对象的引用。此外,所有的Java类都有一个静态属性class,它引用代表这个类的Class对象。
二,类的生命周期
当样品类被加载、链接和初始化后,它的生命周期就开始了。当代表样本类的类对象不再被引用,即不可触及时,Class对象就会结束生命周期,Sample类在方法区内的数据也会被卸载,从而结束Sample类的生命周期。
一个类何时结束生命周期,取决于代表它的类对象何时结束生命周期.
三,案例分析
loader1变量和obj变量间接应用代表Sample类的Class对象,而objClass变量则直接引用它。
-
如果程序运行过程中,将上图左侧三个引用变量都置为null,此时Sample对象结束生命周期,MyClassLoader对象结束生命周期,代表Sample类的Class对象也结束生命周期,Sample 类在方法区内的二进制数据被卸载。
-
当再次有需要时,会检查Sample类的Class对象是否存在,如果存在会直接使用,不再重新加载;如果不存在Sample类会被重新加载,在Java虛拟机的堆区会生成一个新的代表Sample类的Class实例(可以通过哈希码查看是否是同一个实例会被重新加载,在java虛拟机的堆区会生成一个新的代表示例类的类实例(可以通过哈希码查看是否是同一个实例)。
四、类的卸载
(1)启动类加载群如载的类型在整个运行期间是不可能被卸载的(jvm和jls规范)
(2)被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载,因为系统类加载器实例或者扩展类的实例基本上在整个运行期间总能直接或者间接的访问的到,其达到unreachable的可能性极小。
(3)被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载,而且一般还要借助于强制调用虚拟机的垃圾收集功能才可以做到。
可以预想,稍微复杂点的应用场景中(比如:很多时候用户在开发自定义类加载器实例的时候采用缓存的策略以提高系统性能),被加载的类型在运行期间也是几乎不太可能被卸载的(至少卸载的时间是不确定的)。
以上是关于Java反射与类加载过程会擦出什么样的火花的主要内容,如果未能解决你的问题,请参考以下文章