第七章 虚拟机类加载机制
1、类加载的时机
类从被加载到虚拟机
内存中开始,到
卸载出内存为止,它的整个生命周期包括了:加载(Loading)、验证(Verification)、准备(Preparation)、
解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)七个阶段。其中验证、准备和解析三个部分统称为连接(Linking)。
4种必须对类进行“初始化”的情景;
1)遇到new、getstatic、putstatic或invokestatic这4笨拙字节码指令时,如果没有进行过初始化,则需要先
触发其初始化。
2)使用java.lang.reflect包的方法对类进行反射调用的时候,如果类没有进行过初始化,则需要先触发其初始化。
3)当初始化一个类的时候,如果
发现其父类还没有进行初始化,则需要先触发其父类初始化。
4)当虚拟机启动时,用户需要指定一个要执行的主类,虚拟机会先初始化这个主类。
通过-XX:+TraceClassLoading可以查看类的加载信息
2、类加载器--双新委派模型
在java虚拟机的角度,只有两种不同的类加载器:一种是启动类加载器(Bootstrap ClassLoader),这个类加载器使用
C++语言实现,是虚拟机自身的一部分;另外一种就是所有其他的类加载器,这些类加载器都由JAVA语言实现,独立于虚拟机外部,并且全都继承自抽象类java.lang.ClassLoader。
从开发人员角度分得更细一些:
a:启动类加载器(Bootstrap ClassLoader):负责将存放在<JAVA_HOME>/lib目录中的,或者被-Xboot
classpath参数所指定的中午中的,并且虚拟机识别的类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用。
b:扩展类加载器(Extension ClassLoader):这个加载器由sum.misc.Launcher$ExtClassLoader实现,它负责加载<JAVA_HOME>/lib/ext目录中的,或者被java.ext.dirs系统变量所指定的路径中的所有类库,开发者可以直接使用扩展类加载器。
c:应用程序类加载器(Application ClassLoader):这个类加载器由sum.misc.Launcher$AppClassLoader来实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回在值,所民一般也称它为系统类加载器。它负责加载用户类路径上所指定的类库,开发者可以直接使用这个类加载器,如果应用程序中没有
自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。
OSGI类加载的顺序
1)将以java.*形状的类,委派给父类加载器加载。
2)否则,将委派列表名单内的类,委派给父类加载器加载。
3)否则,将Import列表中的类,委派给Export这个类的Bundle的类加载器加载。
4)否则,查找当前Bundle的ClassPath,使用自己的类加载器加载。
5)否则,查找类是否在自己的Fragment Bundle中,如果在,则委派给Fragment Bundle的类加载器加载。
6)否则,查找Dynamic Import列表的Bundle,委派给对应Bundle的类加载器加载。
7)否则,类查找失败。