JVM学习第二篇思考：一个Java代码是怎么运行起来的-下篇

在上一篇《JVM学习第一篇思考：一个Java代码是怎么运行起来的-上篇》中咱们知道类一个Java类的生命周期需要经历以下七个阶段：类加载、验证、准备、解析、初始化、使用、卸载。同时，我们对每个阶段都做了简单介绍。于是我们就得到了如下的：

编辑

今日目标：

jvm在什么时候会去加载一个类？

类加载器和双亲委派机制是什么？

上一篇问题思路解析

jvm在什么时候会去加载一个类？

我们既然知道了一个Java类的生命周期。那么一个类在什么时候被加载呢？类加载的时机是什么？什么是主动引用？什么是被动引用呢？

在Java的虚拟机规范中，没有对加载阶段作出明确约束。但是在初始化阶段，Java虚拟机严格规定了有且只有在以下几种情况下，类必须立即进行初始化的(注意初始化阶段在类生命周期中哪个阶段)

1.1：使用new关键字实例化对象的时候

当我们使用new关键字来创建(实例化)对象的时候，读取和设置类的静态的变量(static int = 1;)、静态非字面值常量(静态字面值常量除外。如：static Person )的时候，调用静态方法的时候(如：staitc String getName();)。

1.2：在进行反射调用的时候

编辑

1.3：当初始化一个类的是，如果父类没有进行初始化，需要先初始化父类

这个很好理解，当你想要使用一个类的子类的时候，父类没有被初始化加载，子类是不能直接使用的

1.4：启动程序所使用的的main方法所在的类

这个也很好理解，因为main方法是程序的入口。程序要启动，不加载对应的类，怎么启动？

1.5：当使用了1.7新特性-动态语音支持时候

简单总结：

1：使用关键字new一个对象的是

2：对类中的静态字段(非final修饰的)进行set或get的时候

(当被final修饰后，回顾下final关键字的特性)

3：调用了一个类中的静态方法的时候

都会触发加载需要的类加载。上面这些加载是主动加载的，所以被称为主动引用。

当然，有了主动引用当然会有被动引用，被动引用有以下几种种情况：

• 通过子类引用了父类的静态字段。只会触发父类的初始化，而不会触发子类的初始化。

根据Java面向对象的多态特性，子类可以执行父类的。这里通过子类引用父类的静态字段，操作的是父类，而非子类自己。所以子类不会被触发初始化。

• 定义对象为数组或集合的时候，这种情况，不会触发该类的初始化

数组或集合虽然也是对象，但是这些对象是由JVM处理的。所以，不会触发的

• 类A引用了类B的static final常量不会导致B初始化

这里需要注意，静态常量必须是 字面值常量。不然还是会触发B的初始化

这个怎么理解呢？比如：static final str = "132";这个时候，A类虽然引用了B类的str.但是因为str这个字面值被fianl关键字修饰了，此时的“132”进入了常量池中了。

• 通过类名获取该类的Class对象，不会触发类的初始化

比如：sysout(Person.class);这个方法的时候，是不会调用类的初始化

编辑

• 通过Class.forName加载指定类的时候，如果指定了参数initialize=false时候

这个好理解，因为设置了懒加载，所以不会里面被初始化的

• 通过ClassLoader默认的loadClass方法，也不会触发初始化动作

类加载器和双亲委派机制是什么？

一个类既然有加载，那么它是怎么被加载的？这个时候，类加载器就该出场了。

类加载器

类加载器分类：

• 引导类加载器

bootstrap class loader：引导类加载器

1：该加载器加载的是我们Java的核心库.路径为：JAVA_HOME/jre/lib/rt.jar,sun.boot.class.path这两个路径下的内容。

2：加载扩展类、应用程序的类加载器(如果有用户自定义的类加载器的话，也加载)。并为这类类加载器指定他们的父类加载器。

ps:rt.jar是Java的runtim需要的jar

• 扩展类加载器

extensions class loader：扩展类加载器

1：该类加载器加载的是Java扩展库。其加载的路径为：

JAVA_HOME/jre/lib/ext/*.jar 或者java.ext.dirs路径下的内容。Java虚拟机会提供一个扩展库目录。该类加载器就是在加载扩展库目录中插找并加载对应的Java的class文件

2：有sun.misc.Launcher$ExtClassLoader实现

• 应用程序类加载器

application class loader：应用程序类加载器

就是我们自己写的应用

1：该加载器根据Java引用的类路径(classpath,java.class.path路径下的内容)来加载类。

一般来说，Java应用的类都是有这个类加载器来完成的

2：是由sun.misc.Launcher$AppClassLoader实现的

• 用户自定义类加载器

开发人员(我们)可以通过基础java.lang.ClassLoader类的方式实现自己的类加载器，以满足一些特殊需求。

classLoader类的作用：

java.class .ClassLoader类的基本职责就是根据一个指定的类的名称，找到或者生成其对应的字节码代码(class文件)，然后从这些字节码中定义出一个Java类，既是：java.lang.Class类的实例。

ClassLoader还负责加载Java应用所需要的资源。比如图片文件、配置文件等。

四种类加载器的关系：

编辑

上图亲子层级结构，就有一个：双亲委派的机制。

扩展：

比较两个类是否相等的前提条件：两个类必须是同一个类加载器加载的。如果没有这个前提条件。比较的话，就是耍流氓。

比如：我要给你货币(法币)：30000.当听到这个时候你是不是会很高兴呢？但是如果这3W是越南盾呢？或者是天地银行呢？所以，要有个前提条件。

双亲委派机制

双亲委派机制流程：

假设我们自己写的应用程序(这个应用的类加载器是：应用程序类加载器)需要加载一个类来使用，那么应用程序会先把这个查找类的任务交给他的父类加载器，也就是扩展类加载器，扩展类加载器收到查找任务后，转手将这个查找类的任务交给了其父类加载器，也就是引导类加载器。如果引导类加载器在自己管辖范围内没有查找到，所需要查找的类，就会向下推，把加载查找权力交个自己的子类加载器。依次类推。当所有的类加载器都查找一遍，没有找到的话，就会抛出classnotFund这个。

上面这么多文字，太复杂了，能具体点吗？可以，咱们举个例子：

比如上文中当我们启动main方法的时候，使用了Son这个类。这个类的全路径：com.kaigejava.jvm.Son.那么这个类是怎么被加载器加载的呢？

编辑

委派：

main方法所在的类的类加载器是：应用程序类加载器 委派 其父类加载器==>扩展类加载器

扩展类加载器 委派 其父类加载器==>引导类加载器。

我们知道Son这个类编译成class文件后，所在目录是在classpath下的。所以，引导类启动加载器是肯定找不到的。

加载权限下放：

引导类加载器找不到后，就把 加载权限下放 给其子类加载器==>扩展类加载器。同样，扩展类加载器在自己的归属范围内没找到需要加载的类后。继续加载权限下放

扩展类加载器的子类加载器(应用程序类加载器)就在自己归属地classpath下找到了son类。然后将其加载到虚拟机内存中。

这种模式就是双亲委派机制。

一句话：往上捅。当上面找不到后，在自己找找看。

好处：

这种机制是为了保证Java核心类库(rt.jar)的安全性。比如：如果我们自己写了个String类。全类路径：com.kaigejava.jvm.String这个类。因为有了双亲委派机制的存在，我在Son类或者是在Father类中使用的String类都是同一个。

上一篇思考题解答

在上一篇结束的时候，凯哥(凯哥Java:kaigejava)留下了一个思考：

当一个类存在父类的时候，初始化过程如下图：

编辑

运行结果：

编辑

从运行的结果中我们可以确实可以得到如下结论：

当一个类存在父类的时候，在初始化该类的时候，会先初始化其父类中的静态代码块中方法，然后在执行子类中静态代码块，接着执行父类非静态代码块，接着父类构造方法，接着子类非静态代码块，最后才是子类的构造方法。

具体的完整的初始化顺序(存在父类情况下):

这个也是很常见的一个面试题。希望大家能够记住。

当是接口的时候，初始化过程：

编辑

运行结果：

编辑

从运行结果我们可以得到如下结论：

接口中不能使用静态代码块，但可使用静态变量。与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有父接口中定义的变量被使用时父接口才会被初始化，另外，接口的实现类在初始化时页一样不会执行接口的<clinit>()方法。

本文思考题：

既然双亲委派机制有好处，那么在实际工作中，有没有打破双亲委派机制的呢？

下一篇文章预告：

思路：我们已经已经知道了一个类怎么被加载到Java的虚拟机中了，同时我们 也知道了类加载器，双亲委派机制等。那么，我们写的类中声明的变量(局部变量、全局变量)、声明的对象等这些，在Java虚拟机中是怎么存在的？都存放在什么位置呢？这就是我们接下来要讲解的：Java虚拟机的内存模型。欢迎大家继续和凯哥(kaigejava)一起学习。

凯哥有什么理解不对的地方，欢迎大家留言批评。凯哥在此先谢过各位