JVM学习第二篇思考:一个Java代码是怎么运行起来的-下篇
在上一篇《JVM学习第一篇思考:一个Java代码是怎么运行起来的-上篇》中咱们知道类一个Java类的生命周期需要经历以下七个阶段:类加载、验证、准备、解析、初始化、使用、卸载。同时,我们对每个阶段都做了简单介绍。于是我们就得到了如下的:
编辑
今日目标:
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处理的。所以,不会触发的
这里需要注意,静态常量必须是 字面值常量。不然还是会触发B的初始化
这个怎么理解呢?比如:static final str = "132";这个时候,A类虽然引用了B类的str.但是因为str这个字面值被fianl关键字修饰了,此时的“132”进入了常量池中了。
比如:sysout(Person.class);这个方法的时候,是不会调用类的初始化
编辑
这个好理解,因为设置了懒加载,所以不会里面被初始化的
一个类既然有加载,那么它是怎么被加载的?这个时候,类加载器就该出场了。
类加载器
类加载器分类:
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培训班提供的学习大纲;