深入理解java虚拟机学习笔记（五）－－虚拟机类加载机制

第七章 虚拟机类加载机制
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目录中的，或者被-Xbootclasspath参数所指定的中午中的，并且虚拟机识别的类库加载到虚拟机内存中。启动类加载器无法被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）否则，类查找失败。