Java中类加载机制及反射

曾经终败给现在 2022-06-17 11:48 189阅读 0赞

JVM 全称是Java Virtual Machine ，Java 虚拟机，也就是在计算机上再虚拟一个计算机，这和我们使用 VMWare 不一样，那个虚拟的东西你是可以看到的，这个JVM 你是看不到的，它存在内存中。我们知道计算机的基本构成是：运算器、控制器、存储器、输入和输出设备，那这个JVM 也是有这成套的元素，运算器是当然是交给硬件CPU 还处理了，只是为了适应“一次编译，随处运行”的情况，需要做一个翻译动作，于是就用了JVM 自己的命令集，这与汇编的命令集有点类似，每一种汇编命令集针对一个系列的CPU ，比如8086 系列的汇编也是可以用在8088 上的，但是就不能跑在8051 上，而JVM 的命令集则是可以到处运行的，因为JVM 做了翻译，根据不同的CPU ，翻译成不同的机器语言。

JVM 中我们最需要深入理解的就是它的存储部分，存储？硬盘？NO ，NO ， JVM 是一个内存中的虚拟机，那它的存储就是内存了，我们写的所有类、常量、变量、方法都在内存中，这决定着我们程序运行的是否健壮、是否高效，接下来的部分就是重点介绍之。

我们先把JVM 这个虚拟机画出来，如下图所示：

![这里写图片描述][SouthEast]

从这个图中可以看到，JVM 是运行在操作系统之上的，它与硬件没有直接的交互。我们再来看下JVM 有哪些组成部分，如下图所示：  
![这里写图片描述][SouthEast 1]  
该图参考了网上广为流传的JVM 构成图，大家看这个图，整个JVM 分为四部分：

1、Class Loader 类加载器  
类加载器的作用是加载类文件到内存，比如编写一个HelloWord.java 程序，然后通过javac 编译成class 文件，那怎么才能加载到内存中被执行呢？Class Loader 承担的就是这个责任，那不可能随便建立一个.class 文件就能被加载的，Class Loader 加载的class 文件是有格式要求，在《JVM Specification 》中式这样定义Class 文件的结构：

ClassFile {
          u4 magic;
          u2 minor_version;
           u2 major_version;
          u2 constant_pool_count;
          cp_info constant_pool[constant_pool_count-1];
          u2 access_flags;
          u2 this_class;
          u2 super_class;
          u2 interfaces_count;
          u2 interfaces[interfaces_count];
          u2 fields_count;
          field_info fields[fields_count];
          u2 methods_count;
          method_info methods[methods_count];
          u2 attributes_count;
          attribute_info attributes[attributes_count];
        }

需要详细了解的话，可以仔细阅读《JVM Specification 》的第四章“The class File Format ”，这里不再详细说明。  
友情提示：Class Loader 只管加载，只要符合文件结构就加载，至于说能不能运行，则不是它负责的，那是由Execution Engine 负责的。

2、Execution Engine 执行引擎

执行引擎也叫做解释器(Interpreter) ，负责解释命令，提交操作系统执行。

3、Native Interface 本地接口

本地接口的作用是融合不同的编程语言为Java 所用，它的初衷是融合C/C++ 程序，Java 诞生的时候是C/C++ 横行的时候，要想立足，必须有一个聪明的、睿智的调用C/C++ 程序，于是就在内存中专门开辟了一块区域处理标记为native 的代码，它的具体做法是Native Method Stack 中登记native 方法，在Execution Engine 执行时加载native libraies 。目前该方法使用的是越来越少了，除非是与硬件有关的应用，比如通过Java 程序驱动打印机，或者Java 系统管理生产设备，在企业级应用中已经比较少见，因为现在的异构领域间的通信很发达，比如可以使用Socket 通信，也可以使用Web Service 等等，不多做介绍。  
4、Runtime data area 运行数据区  
运行数据区是整个JVM 的重点。我们所有写的程序都被加载到这里，之后才开始运行，Java 生态系统如此的繁荣，得益于该区域的优良自治，下一章节详细介绍之。

整个JVM 框架由加载器加载文件，然后执行器在内存中处理数据，需要与异构系统交互是可以通过本地接口进行，瞧，一个完整的系统诞生了！

JVM加载class文件的原理机制

1.Java中的所有类，必须被装载到jvm中才能运行，这个装载工作是由jvm中的类装载器完成的,类装载器所做的工作实质是把类文件从硬盘读取到内存中

2.java中的类大致分为三种：  
1.系统类  
2.扩展类  
3.由程序员自定义的类

3.类装载方式，有两种  
1.隐式装载， 程序在运行过程中当碰到通过new 等方式生成对象时，隐式调用类装载器加载对应的类到jvm中，  
2.显式装载， 通过class.forname()等方法，显式加载需要的类  
隐式加载与显式加载的区别：  
两者本质是一样?  
4.类加载的动态性体现  
一个应用程序总是由n多个类组成，Java程序启动时，并不是一次把所有的类全部加载后再  
运行，它总是先把保证程序运行的基础类一次性加载到jvm中，其它类等到jvm用到的时候再加载，这样的好处是节省了内存的开销，因为java最早就是为嵌入式系统而设计的，内存宝贵，这是一种可以理解的机制，而用到时再加载这也是java动态性的一种体现

5．java类装载器  
Java中的类装载器实质上也是类，功能是把类载入jvm中，值得注意的是jvm的类装载器并不是一个，而是三个，层次结构如下：

Bootstrap Loader  - 负责加载系统类 
                        | 
              - - ExtClassLoader - 负责加载扩展类                           | 
                          - - AppClassLoader - 负责加载应用类

为什么要有三个类加载器，一方面是分工，各自负责各自的区块，另一方面为了实现委托模型，下面会谈到该模型

1.  类加载器之间是如何协调工作的  
    前面说了，java中有三个类加载器，问题就来了，碰到一个类需要加载时，它们之间是如何协调工作的，即java是如何区分一个类该由哪个类加载器来完成呢。  
    在这里java采用了委托模型机制，这个机制简单来讲，就是“类装载器有载入类的需求时，会先请示其Parent使用其搜索路径帮忙载入，如果Parent 找不到,那么才由自己依照自己的搜索路径搜索类”，注意喔，这句话具有递归性 。

public   class TestClass {   
        /** * @param args */   
        public   static   void  main(String[] args)   throws  Exception{  
            //调用class加载器 
            ClassLoader cl = TestClass.class .getClassLoader();  
            System.out.println(cl);  
            //调用上一层Class加载器 
            ClassLoader clParent = cl.getParent();  
            System.out.println(clParent);  
            //调用根部Class加载器 
            ClassLoader clRoot = clParent.getParent();  
            System.out.println(clRoot);  
    
        }  
    
    }

Result代码

Run， Console中出现的log信息如下：  
    sun.misc.Launcher$AppClassLoader@7259da  
    sun.misc.Launcher$ExtClassLoader@16930e2  
    null

可以看出TestClass是由AppClassLoader加载器加载的  
AppClassLoader的Parent 加载器是 ExtClassLoader  
但是ExtClassLoader的Parent为 null 是怎么回事呵，朋友们留意的话，前面有提到Bootstrap Loader是用C++语言写的,依java的观点来看，逻辑上并不存在Bootstrap Loader的类实体，所以在java程序代码里试图打印出其内容时，我们就会看到输出为null 。

【注：以下内容大部分引用java深度历险】  
弄明白了上面的示例，接下来直接进入类装载的委托模型实例，写两个文件，如下：

public class Test1 {  
    
        public static void main(String[] args) throws  Exception {  
            System.out.println(Test1.class .getClassLoader());  
    
            Test2 test2 = new Test2();  
    
            test2.print();  
        }  
    
    }  
    
    public   class  Test2 {  
        public   void  print(){  
            System.out.println(Test2.class );  
            System.out.println(this .getClass());  
            System.out.println(Test2.class .getClassLoader());  
        }  
    }

Result代码

Run,Console出现log如下：   
    sun.misc.Launcher$AppClassLoader@7259da   
    class com.java.test.Test2   
    class com.java.test.Test2   
    sun.misc.Launcher$AppClassLoader@7259da

1.  预先加载与依需求加载

Java 运行环境为了优化系统，提高程序的执行速度，在 JRE 运行的开始会将 Java 运行所需要的基本类采用预先加载（ pre-loading ）的方法全部加载要内存当中，因为这些单元在 Java 程序运行的过程当中经常要使用的，主要包括 JRE 的 rt.jar 文件里面所有的 .class 文件。

当 java.exe 虚拟机开始运行以后，它会找到安装在机器上的 JRE 环境，然后把控制权交给 JRE ， JRE 的类加载器会将 lib 目录下的 rt.jar 基础类别文件库加载进内存，这些文件是 Java 程序执行所必须的，所以系统在开始就将这些文件加载，避免以后的多次 IO 操作，从而提高程序执行效率。

图（ 2 ）我们可以看到多个基础类被加载， java.lang.Object,java.io.Serializable 等等。  
相对于预先加载，我们在程序中需要使用自己定义的类的时候就要使用依需求加载方法（ load-on-demand ），就是在 Java 程序需要用到的时候再加载，以减少内存的消耗，因为 Java 语言的设计初衷就是面向嵌入式领域的。  
8. 自定义类加载机制

之前我们都是调用系统的类加载器来实现加载的，其实我们是可以自己定义类加载器的。利用 Java 提供的 java.NET.URLClassLoader 类就可以实现。下面我们看一段范例：

try {   
    URL url = new  URL( "file:/d:/test/lib/" );   
    URLClassLoader urlCL = new  URLClassLoader( new  URL[]{url});   
    Class c = urlCL.loadClass("TestClassA" );   
    TestClassA object = (TestClassA)c.newInstance(); 
    object.method();   
    }catch (Exception e){   
    e.printStackTrace();   
    }

我们通过自定义的类加载器实现了 TestClassA 类的加载并调用 method （）方法。分析一下这个程序：首先定义 URL 指定类加载器从何处加载类， URL 可以指向网际网络上的任何位置，也可以指向我们计算机里的文件系统 ( 包含 JAR 文件 ) 。上述范例当中我们从 file:/d:/test/lib/ 处寻找类；然后定义 URLClassLoader 来加载所需的类，最后即可使用该实例了。

1.  类加载器的阶层体系

讨论了这么多以后，接下来我们仔细研究一下 Java 的类加载器的工作原理：

当执行 java *\**.class 的时候， java.exe 会帮助我们找到 JRE ，接着找到位于 JRE 内部的 jvm.dll ，这才是真正的 Java 虚拟机器 , 最后加载动态库，激活 Java 虚拟机器。虚拟机器激活以后，会先做一些初始化的动作，比如说读取系统参数等。一旦初始化动作完成之后，就会产生第一个类加载器―― Bootstrap Loader ， Bootstrap Loader 是由 C++ 所撰写而成，这个 Bootstrap Loader 所做的初始工作中，除了一些基本的初始化动作之外，最重要的就是加载 Launcher.java 之中的 ExtClassLoader ，并设定其 Parent 为 null ，代表其父加载器为 BootstrapLoader 。然后 Bootstrap Loader 再要求加载 Launcher.java 之中的 AppClassLoader ，并设定其 Parent 为之前产生的 ExtClassLoader 实体。这两个加载器都是以静态类的形式存在的。这里要请大家注意的是， LauncherExtClassLoader.class与LauncherAppClassLoader.class 都是由 Bootstrap Loader 所加载，所以 Parent 和由哪个类加载器加载没有关系。

下面的图形可以表示三者之间的关系：  
BootstrapLoader <—(Extends)—-ExtClassLoader <—(Extends)—-AppClassLoader

这三个加载器就构成我们的 Java 类加载体系。他们分别从以下的路径寻找程序所需要的类：

BootstrapLoader ： sun.boot.class.path  
ExtClassLoader: java.ext.dirs  
AppClassLoader: java.class.path

这三个系统参量可以通过 System.getProperty() 函数得到具体对应的路径。大家可以自己编程实现查看具体的路径。

一、Java类加载机制  
1．概述

Class文件由类装载器装载后，在JVM中将形成一份描述Class结构的元信息对象，通过该元信息对象可以获知Class的结构信息：如构造函数，属性和方法等，Java允许用户借由这个Class相关的元信息对象间接调用Class对象的功能。
    
      虚拟机把描述类的数据从class文件加载到内存，并对数据进行校验，转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。

2．工作机制

类装载器就是寻找类的字节码文件，并构造出类在JVM内部表示的对象组件。在Java中，类装载器把一个类装入JVM中，要经过以下步骤：
    
     (1) 装载：查找和导入Class文件；
    
     (2) 链接：把类的二进制数据合并到JRE中；
    
        (a)校验：检查载入Class文件数据的正确性；
    
        (b)准备：给类的静态变量分配存储空间；
    
        (c)解析：将符号引用转成直接引用；
    
     (3) 初始化：对类的静态变量，静态代码块执行初始化操作

![这里写图片描述][SouthEast 2]

Java程序可以动态扩展是由运行期动态加载和动态链接实现的；比如：如果编写一个使用接口的应用程序，可以等到运行时再指定其实际的实现(多态)，解析过程有时候还可以在初始化之后执行；比如：动态绑定(多态)；

【类初始化】

(1) 遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候，读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
    
      (2) 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
    
      (3) 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
    
      (4)当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。

只有上述四种情况会触发初始化，也称为对一个类进行主动引用，除此以外，所有其他方式都不会触发初始化，称为被动引用。

代码清单1：  
![这里写图片描述][SouthEast 3]  
上述代码运行后，只会输出【—SuperClass init】, 而不会输出【SubClass init】,对于静态字段，只有直接定义这个字段的类才会被初始化,因此，通过子类来调用父类的静态字段，只会触发父类的初始化,但是这是要看不同的虚拟机的不同实现。  
代码清单2：  
![这里写图片描述][SouthEast 4]

此处不会引起SuperClass的初始化，但是却触发了【\[Ltest.SuperClass】的初始化，通过arr.toString()可以看出，对于用户代码来说，这不是一个合法的类名称，它是由虚拟机自动生成的，直接继承于Object的子类，创建动作由字节码指令newarray触发,此时数组越界检查也会伴随数组对象的所有调用过程，越界检查并不是封装在数组元素访问的类中，而是封装在数组访问的xaload,xastore字节码指令中.

代码清单3：  
![这里写图片描述][SouthEast 5]

对常量ConstClass.value 的引用实际都被转化为NotInitialization类对自身常量池的引用，这两个类被编译成class后不存在任何联系。

【装载】
    
    在装载阶段，虚拟机需要完成以下3件事情
    
        (1) 通过一个类的全限定名来获取定义此类的二进制字节流
    
        (2) 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
    
        (3) 在Java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口。
    
    虚拟机规范中并没有准确说明二进制字节流应该从哪里获取以及怎样获取,这里可以通过定义自己的类加载器去控制字节流的获取方式。
    
    
    
         【验证】
    
    虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为载入了有害的字节流而导致系统奔溃。
    
    
    
         【准备】
    
    准备阶段是正式为类变量分配并设置类变量初始值的阶段，这些内存都将在方法区中进行分配,需要说明的是：

这时候进行内存分配的仅包括类变量(被static修饰的变量),而不包括实例变量,实例变量将会在对象实例化时随着对象一起分配在Java堆中;这里所说的初始值“通常情况”是数据类型的零值，假如:

public static int value = 123;

value在准备阶段过后的初始值为0而不是123,而把value赋值的putstatic指令将在初始化阶段才会被执行。

二、类加载器与双亲委派模型

类加载器

(1) Bootstrap ClassLoader : 将存放于<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如 rt.jar 名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用
    
     (2) Extension ClassLoader : 将<JAVA_HOME>\lib\ext目录下的，或者被java.ext.dirs系统变量所指定的路径中的所有类库加载。开发者可以直接使用扩展类加载器。
    
     (3) Application ClassLoader : 负责加载用户类路径(ClassPath)上所指定的类库,开发者可直接使用。
    
                 双亲委派模型

![这里写图片描述][SouthEast 6]

工作过程：如果一个类加载器接收到了类加载的请求，它首先把这个请求委托给他的父类加载器去完成，每个层次的类加载器都是如此，因此所有的加载请求都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它在搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

好处：java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar中，无论哪个类加载器要加载这个类，最终都会委派给启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果用户自己写了一个名为java.lang.Object的类，并放在程序的Classpath中，那系统中将会出现多个不同的Object类，java类型体系中最基础的行为也无法保证，应用程序也会变得一片混乱。

java.lang.ClassLoader中几个最重要的方法:

//加载指定名称（包括包名）的二进制类型，供用户调用的接口
    public Class<?> loadClass(String name);
    //加载指定名称（包括包名）的二进制类型，同时指定是否解析（但是，这里的resolve参数不一定真正能达到解析的效果），供继承用
    protected synchronized Class<?> loadClass(String name, boolean resolve);
    protected Class<?> findClass(String name)
    //定义类型，一般在findClass方法中读取到对应字节码后调用，可以看出不可继承（说明：JVM已经实现了对应的具体功能，解析对应的字节码，产生对应的内部数据结构放置到方法区，所以无需覆写，直接调用就可以了）
    protected final Class<?> defineClass(String name, byte[] b, int off, int len) throws ClassFormatError{}

如下是实现双亲委派模型的主要代码：

![这里写图片描述][SouthEast 7]

三、反射  
Reflection机制允许程序在正在执行的过程中，利用Reflection APIs取得任何已知名称的类的内部信息，包括：package、 type parameters、 superclass、 implemented interfaces、 inner classes、 outer classes、 fields、 constructors、 methods、 modifiers等，并可以在执行的过程中，动态生成instances、变更fields内容或唤起methods。

1、获取构造方法

Class类提供了四个public方法，用于获取某个类的构造方法。

Constructor getConstructor(Class\[\] params)

根据构造函数的参数，返回一个具体的具有public属性的构造函数

Constructor getConstructors()

返回所有具有public属性的构造函数数组

Constructor getDeclaredConstructor(Class\[\] params)

根据构造函数的参数，返回一个具体的构造函数（不分public和非public属性）

Constructor getDeclaredConstructors()

返回该类中所有的构造函数数组（不分public和非public属性）  
![这里写图片描述][SouthEast 8]

2、获取类的成员方法

与获取构造方法的方式相同，存在四种获取成员方法的方式。

Method getMethod(String name, Class\[\] params)

根据方法名和参数，返回一个具体的具有public属性的方法

Method\[\] getMethods()

返回所有具有public属性的方法数组

Method getDeclaredMethod(String name, Class\[\] params)

根据方法名和参数，返回一个具体的方法（不分public和非public属性）

Method\[\] getDeclaredMethods()

返回该类中的所有的方法数组（不分public和非public属性）

![这里写图片描述][SouthEast 9]

3、获取类的成员变量（成员属性）

存在四种获取成员属性的方法

Field getField(String name)

根据变量名，返回一个具体的具有public属性的成员变量

Field\[\] getFields()

返回具有public属性的成员变量的数组

Field getDeclaredField(String name)

根据变量名，返回一个成员变量（不分public和非public属性）

Field\[\] getDelcaredFields()

返回所有成员变量组成的数组（不分public和非public属性）

转自：[http://blog.csdn.net/gfangxiong/article/details/7425563][http_blog.csdn.net_gfangxiong_article_details_7425563]  
[http://www.cnblogs.com/ITtangtang/p/3978102.html][http_www.cnblogs.com_ITtangtang_p_3978102.html]

[SouthEast]: /images/20220617/558ce095fb12483f8c14d2df1fa47f71.png
[SouthEast 1]: /images/20220617/62169a2a2eb541139700fee5dd78f330.png
[SouthEast 2]: /images/20220617/72662f68054645a084d7684cf5617595.png
[SouthEast 3]: /images/20220617/3f3122349f2a483bab05eeea106d4bf8.png
[SouthEast 4]: /images/20220617/f2955111ed4e4bb2b07d5c20e0f2b92b.png
[SouthEast 5]: /images/20220617/f9958fae434648698313f0096df73b6a.png
[SouthEast 6]: /images/20220617/892e4e23232948a3a7d326981cb3cb22.png
[SouthEast 7]: /images/20220617/614fe42f994c468681f80926a024a2f9.png
[SouthEast 8]: /images/20220617/eacd15b9a757429e8afebcd506fcea46.png
[SouthEast 9]: /images/20220617/b14d35481d7c4045bf42c7cdf6e6b869.png
[http_blog.csdn.net_gfangxiong_article_details_7425563]: http://blog.csdn.net/gfangxiong/article/details/7425563
[http_www.cnblogs.com_ITtangtang_p_3978102.html]: http://www.cnblogs.com/ITtangtang/p/3978102.html