JAVA 类加载器

  今天我们将类加载机制5个阶段中的第一个阶段，加载，又叫做装载。为了便于阅读，以下都叫做装载。

  装载的第一步就是要获得二进制的字节流，它可以从读.class文件获得，也可以从网络中接收别人发送的字节流。反正只要符合虚拟机规定的字节流格式都可以进入这个阶段。

  有了字节流之后，要进行装载还需要一个工具，那就是加载器了。加载器既可以使用系统提供的引导类加载器，也可以使用用户自己定义加载器，只需要继承ClassLoader，再重写loadClass()方法就可以实现一个自己的简单加载器。

  像上面的代码那样，就是一个简单的类加载器。当我们要自己加载某个类的时候，就可自己调用loadClass方法，参数通常为要加载类的全类名，再根据name获得文件，得到字节流后便可加载，如图。

  一般的工作情况下我们不会自己去实现加载器，都是采用系统默认的加载器。绝大部分Java程序都会使用到系统提供的以下3种加载器：

• Bootstrap ClassLoader：启动类加载器。负责加载JAVA_HOME/lib/里所有能被虚拟机识别的类（如：rt.jar）。无法被Java程序直接引用，由C++实现，不是ClassLoader子类。
• Extension ClassLoader：扩展类加载器。负责加载java平台中扩展功能的一些jar包，包括JAVA_HOME/lib/ext/目录中的或java.ext.dirs系统变量指定目录下的所有类库。是ClassLoad的子类，开发者可以直接使用该加载器。

• App ClassLoader：应用程序类加载器。负责加载classpath中指定的jar包及目录中class。getSystemClassLoader()的返回值就是该加载器，开发者可以直接使用该加载器。

    本篇博文先了解这些知识点，在下篇博文中我们会讲解虚拟机如何运用这些加载进行搭配工作。

    对于刚刚上面的代码，小伙伴可以自己尝试着写写。字节流可以读文件，也可以通过网络获得，得到后进行加载，再通过反射执行loadClass()返回的对象的相关方法。

JAVA 双亲委派模型

  在上一篇博文中，我们知道了如何获得二进制的字节流，并根据获得的字节流去装载一个类。同时也了解到类加载器的存在，每个加载器对应着不同的加载目录，相互配合着，从而使整个加载过程稳定而安全。

  那么他们是如何配合的呢？如果我自己写一个类，名字叫做String可以吗？

  首先我们来看一张图：

  图中除了最底下的那个加载器是我们没有讲到的，其余的都有说到过。其实底下那个就是我们自己实现的类加载器，用于自定义加载class。

  在虚拟机中，类的加载采用的是双亲委派模型。该模型需要有一个前提条件：除了顶层的类加载器之外，其余的类加载器都应该有自己的父加载器，这里的父加载器指的不是继承，而是组合，即App ClassLoader加载器里面应该要有Extension ClassLoader加载器的引用（为什么用组合而不用继承，大家可以想想其中的利弊）。

  基本工作过程就是：当一个类加载器收到了类加载的请求，他首先不会尝试自己去加载这个类，而是将这次的请求委派给自己的父类加载器去加载。如果父类加载器依然不能加载，则继续用父加载器的父加载器去加载（有点拗口）。层层如此，如果都不能加载，则最终的结果就是到达顶层——启动类加载器Bootstrap ClassLoader。每一层的类加载器都会根据请求所要加载的类去自己应该加载的目录中搜索有没有对应的类和查看该类是否已经被加载。如果有，那么该层加载器加载并返回，如果到达了启动类加载器后还是不能加载，那么就由最初接收到类加载请求的那个类加载器进行加载。

  因此，可以从图或者刚刚的工作过程看出：要加载类就先要检查是否已经加载了和是不是自己应该要加载的类，这个过程是自底向上的。那么如果上层反馈说该类没有被加载，并且我和我的父加载器都不能加载，你自己加载吧，这个过程是从上往下的。

  通过findLoadedClass判断是否已经加载了，如果加载了，则返回这个类，否则就判断有没有父加载器，如果有就交给父加载器加载。如果祖先都不能加载，就交给当前的加载器加载。

  双亲委派模式很好地解决了各个类加载器的基础类统一问题，越基础的类由越上层的类加载器进行加载。分工与责任明确，解决部分安全问题，如自定义的加载器不能加载根加载器应该加载的类，很好的避免了恶意写入基础类。

  例子：我们常用的String类位于rt.jar下。由上一博文的知识可以知道，该jar包是由Bootstrap ClassLoader进行加载的，那么如果我们自己写一个类也叫作String，那么当加载的时候，就会先检查出该类已经被加载了，所以不再允许其他的加载器重新加载，因此我们自己写的String类也就不能用了，所以我们不能自己写一个叫做String的类。

准备-解析-初始化

  在类加载机制的五个阶段中，我们已经讲完了第一个阶段。剩下的四个阶段由于涉及到比较多的类文件相关的知识，现在讲了会看得很吃力，所以我们暂时不会一一的去细讲，只说一下大概的用处，让大家有个概念性的认识。

  装载之后的阶段就是校验阶段了，该阶段的目的就是确保上一阶段读进来的二进制字节流中包含的信息符合虚拟机的规范，并且不会危害虚拟机自身。校验主要分为四个方向：文件格式校验、元数据校验、字节码校验和符号引用校验。

  校验过后就是准备阶段了。该阶段就是为类变量分配内存以及设置初始值。注意：这里的分配内存和设置初始值针对仅仅只是类变量，如：public static int val = 123；这种被static修饰的变量，但是这个设置初始值并不是将例子中的123设置给val变量，而是将0设置给该变量。因为这里指的是初始值，也就是默认的值。如boolean型默认的就是false；float型默认的就是0.0f；引用类型就默认为null。

  然后就是解析阶段，该阶段就是将符号引用替换为直接引用的过程。这两个名词我们会在后面讲类文件格式的时候仔细讲，大家先记着有这么一个阶段就好了。

  最后就是初始化的阶段了，到了这个阶段才会开始执行我们自己写在类中的代码。他执行的是类变量和静态块。如下面代码：

  还记得刚刚讲的准备阶段吗？在准备阶段是为类变量设置初始值和分配内存（方法区分配），而在该阶段则是为该变量赋上我们自己设置的值。到此，小伙伴知道为什么类方法（静态方法）不能调用普通方法或者普通变量了吗？因为类变量以及静态块各相关方法都在准备阶段分配了内存，在初始化阶段就赋予了值，而此时其他普通的变量并没有做到这几步，他们都是在生成实例变量的时候才会进行内存的分配（堆中分配），因此如果静态方法调用了一个普通变量，而此时还没有创建该普通变量的对象，这就会导致系统错误。所以为了避免这种情况，就不允许那样调用了。

  这也是为什么main方法是静态方法的原因之一，因为不用创建对象就可调用了。创建对象是要消耗内存的！！

  在类加载的前面四个阶段中，虚拟机都没有硬性的规定在什么情况下才能进行，而初始化阶段则有且只有5种情况下才能进行，基于易理解的角度来考虑，我们暂时只说3种：

1. 当虚拟机启动的时候，虚拟机会初始化包含main方法的那个类。
2. 当初始化一个子类的时候，发现其父类还没有初始化，就会先初始化其父类。
3. 当我们使用反射对类进行调用的时候，如何该类没有进行初始化，就会先初始化。在我们用JDBC的时候，我们经常会看到这样一行代码：

Class.forName(“com.mysql.jdbc.Driver”); 这就是反射调用，加载该类并且初始化。

初识Class文件

  关于类加载机制的相关知识在前面的博文中暂时先讲那么多。中间留下了很多问题，从本篇博文开始，我们来一一解决。

  从我们最陌生而又最熟悉的.class文件开始说起。.class文件是一个由8位二进制构成一个字节的字节码文件，里面的格式都是按照规定好的顺序紧凑的排列在文件中。

  在.class文件中，他的数据都是以无符号数和表的形式存储的，后面我们进行.class文件的分析就是以这个为基础的，所以我们先了解一下基本的概念。

  无符号数用来描述一些东西，比如字符串值、索引、数字、数量值等等。并且使用u1，u2，u4，u8来表示1个字节，2个字节，4个字节，8个字节。

  表就是由多个无符号数或者其他的表来构成的一种复合型的数据结构。

  整个.class文件就是一张很大的表，这张表的数据项如下：

  先来大概解释一下，这张表是以一个4个字节的魔数（图片有误）作为开始。魔数只是.class文件的一个‘身份识别’，唯一的作用就是确定这个文件是否是一个能被虚拟机接受的class文件，虚拟机中目前将他的值定义为“0xCAFEBABE”（这里以16进制表示）。不只是class文件才有魔数，其他的一些文件也有，如一些图片的文件头中也有魔数。

  既然是以魔数开头，那我们就打开任意一个.class文件来看看是怎么一回事吧！这里我采用的工具是JavaClassViewer。他能将我们看不懂的字节码文件转成16进制显示，点击下载。

  好，现在我们现在打开任意一个文件看看：

  如图，这就是class文件的结构，以魔数开头。现在看不懂没关系，以后我们慢慢解释。

Class文件常量池

  接着上一博文所说，魔数后面分别是次版本号和主版本号。由上图可知其分别占用两个字节。

  被蓝色框框住的就是次版本号，划红线的就是主版本号。再次说明，Class文件内部的数据是按照规则紧凑排列的，中间不会有空隙。

  接下来就是说明常量的个数了。代表着常量池中有多少个常量，由于常量池中的常量数量不确定，所以才会有这个数据项。依然看上图可知该数据项是占用2个字节，因此顺着主版本号往后面数两个字节得到：0x002E(16进制)，即十进制的51，也就是说常量池中有50项常量，索引从1到50。

  这里所指的常量与JAVA代码中所说的常量有所不同，这里的常量主要包括字面量和符号引用，这两个概念很好理解。

字面量跟JAVA代码中的常量概念类似，如字符串、常量的值等等。

符号引用指的是类与接口的全限定名、字段、方法的名词和描述符。可以暂时理解为类、接口、字段、方法的名字。这里我们来回忆一下类加载机制中的解析阶段：他是将符号引用转化为直接引用。直接引用指的就是可以直接指向目标的指针。可以粗略的理解为：符号引用只是用一些符号来描述他要引用的目标，而直接引用才是真正的指向了他要引用的目标。

在常量池中的每个数据项都是以表的形式存在的，这里每个表都会有一个标志位tag，来说明自己的是哪一类型的数据。如图：

  根据以上知识和代码，我们继续来看看Class文件接下来的数据。紧接着常量池数量之后的便是常量表了。刚刚也说了，每个表都会有一个一个字节的标志位，那么常量池数量0x002E之后一个字节便是0x0A，这个就是标志位，十进制是10，查表可知是个方法的符号引用。

  因此后面还有4个字节是属于该表的，我们接着看是0x000B和0x001C，也就是说他的CONSTANT_Class_info索引项是11;CONSTANT_NameAndType的索引项是28，也就是常量池中第11项常量和28项常量，我们这里就通过工具来看了。找到第11项常量，查看11项常量的表结构，继续使用刚刚那样的寻找方法，一直找到标志位为1的常量项，也就是CONSTANT_Utf8_info的表结构，这样就可以得出我们最开始查看的那个表结构的一些具体信息了。

  如果觉得查看过程繁琐，可以采用javap -verbose Main来查看：

  如上图：第1项有指向第11和28项的索引，他们的值分别是后面的字符串，代表的是一个默认的空的构造函数。

  查看跟踪的过程比较枯燥无味，但这也是我们深入了解虚拟机的一个非常重要的基础，大家可查阅更多的相关资料进行学习，有困难，迎难而上才会成长！