深入理解JAVA虚拟机学习笔记14——类加载的加载过程

每天进步一点点！

上一篇穿插了一段动态绑定和静态绑定的知识，这一篇我们回归到类加载上来，学习一下类加载的“加载”。

是不是读起来有点拗口，这是什么意思？

别迷糊，还记得上一篇的上一篇学习过的类加载过程吗，里面有一个阶段就是“加载（loading）”。

加载过程主要包括以下三点内容：

1、通过一个类的全限定名来获取定义此类的二进制字节流。

全限定名也就是包名.类名的形式。如下图所示，当我们在同一个类中，引用的两个类名相同的类，都是StringUtils的时候，就需要使用全限定名org.apache.commons.lang.StringUtils进行区分，另一个没有带包名的，则默认使用import引入的包。

注意，这里说的二进制字节流，并没有明确一定是从Class文件中获取，这就演化出了一些其它形式，比如：压缩文件，可以是jar包和war包；Applet可以从网络中获取；使用动态代理技术（CGLIB等）生成的二进制流；通过其它文件生成，如jsp文件生成的class文件。还可以从数据库读取，等等……

另外，还有一个问题，如果我手动写一个java.lang.System打成一个包加载到虚拟机中，是不是会对rt.jar包中的System产生影响呢？这里就要说说类加载器了。

java程序一般会用到三种类加载器：

1)启动类加载器（Bootstrap ClassLoader）：负责加载JAVA_HOME\lib或者被-Xbootclasspath参数所指定的路径中的目录中，并且能被虚拟机识别的类库到JVM内存中，如果名称不符合的类库即使放在lib目录中也不会被加载。这个类加载器是虚拟器自身的一部分，无法被Java程序直接引用（HotSpot中采用C++编写）。

2)扩展类加载器（Extension ClassLoader）：该加载器主要是负责加载JAVA_HOME\lib\ext目录下的类，或者java.ext.dirs指定目录下的类，该加载器可以被开发者直接使用。

java.ext.dirs可以通过-Djava.ext.dirs命令进行设置（web开发中很少会用到），我们可以在系统属性中取到。

运行结果如下。

3)应用程序类加载器（Application ClassLoader）：该类加载器也称为应用程序类加载器，它负责加载用户类路径（Classpath）上所指定的类库，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

既然知道了实现类是什么，我们不妨打开类文件看一眼。

看起来是不是更直观了，我们再生成AppClassLoader的类图简单看一下，对该类的继承关系有一个大概的了解。

在虚拟机实际的工作当中，类加载器之间是存在层次关系的，如下图所示，

这种包含优先级的层次关系被称为双亲委派模型，即如果一个类加载器收到了一个类加载请求，它不会自己去尝试加载这个类，而是把这个请求转交给父类加载器去完成。每一个层次的类加载器都是如此。因此所有的类加载请求都应该传递到最顶层的启动类加载器中，只有到父类加载器反馈自己无法完成这个加载请求（在它的搜索范围没有找到这个类）时，子类加载器才会尝试自己去加载。

那么也就是说当虚拟机发现需要加载java.lang.System类的时候，会最先使用启动类加载器去寻找，避免了类被重复加载。

2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

还记得我们最开始学习的虚拟机管理的数据区域的内容吗，虚拟机加载的类信息，常量，静态变量，即时编译器编译的代码等数据存储在方法区。

3、在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。

Class对象是一个特殊的对象，是用来创建其它对象的对象，经常会用到的如Class.forName("className")方法，如下图所示，

这个方法运行后出现一个有意思的结果，第一个输出为true，第二个为false。

因为作为参照的SameClassNameTest是由应用程序加载器加载的，而obj2是使用自定义的类加载器ClassLoader加载后创建的，所以并不相等，是不是很神奇？

喜欢文章或想一起学习的朋友可以关注我，给我点赞，我将会持续更新，有什么疑问或文中有不当之处请给我留言，真诚地希望能与大家一起交流探讨，学习进步。