深入理解Java虚拟机 - 类加载器

引子:
 
    类加载器(classloader)是独立于虚拟机之外,可以独立实现的代码模块。
    OSGi使用了类加载器的这一特点实现其热插拔的特性
 
    Java同C++等语言不通,其连接操作不是在编译期间进行的,而是在程序运行期间进行的,这也就为java的动态扩展的语言特性提供了基础。
 

首先介绍下虚拟机的类加载机制:

    类加载的时机:
 
        类被从加载到虚拟机内存开始,到卸出内存为止,整个生命周期包括了以下七个过程:
 
        加载 - 验证 - 准备 - 解析 - 初始化 - 使用 - 卸载 
 
    加载:
 
        1. 通过一个类的全限定名获取定义此类的二进制流(决定了这个类的二进制流可以从zip包、jar包、计算时生成、网络甚至数据库中读取)
 
        2. 将字节流代表的静态存储结构转化为方法区的运行时数据结构
 
        3. 在java堆中生成一个代表该类的class对象
 
    验证:
    
        首先java编译器会对代码进行验证,不合要求的指令不会通过编译,但虚拟机因执行字节码,也需要对字节码进行验证。
 
        不同的虚拟机实现对验证有着不同的定义
 
    准备、解析、初始化
 
下面是类加载器:
 
    类加载器在Java虚拟机外部去实现,以便让应用程序自己去获取所需要的类。
 
    类加载器虽然只用于实现类的加载动作,但都需要类加载器和类本身来共同确认两个类是否相同,也就是说如果同一个class类被不同的类加载器加载,这两个类仍然是不同的
 
    双亲委派模型:
 
        从java虚拟机的角度来看,只有两种不同的类加载器:一种是启动类加载器(Bootstrap ClassLoader),该加载器由C++实现,是虚拟机的一部分
 
        另外一种就是其他的类加载器,这些加载器由Java实现,独立于虚拟机外并且全部继承自抽象类java.lang.ClassLoader
 
        如果更为细分,可以分为如下三种:
 
            深入理解Java虚拟机 - 类加载器启动类加载器(BootStrap ClassLoader)
 
                        该类负责加载存放在<JAVA_HOME>\lib目录中的,或者被-Xbootclasspath参数制定的,并且是虚拟机识别(文件名唯一识别,否则不加载,即使放到了对应目录下)的类库加载到虚拟机内存中去,该启动类无法被Java程序直接引用。
 
            深入理解Java虚拟机 - 类加载器扩展类加载器(Extension ClassLoader)
 
                        该加载器由sun.misc.Launcher$ExtClassLoader实现,负责加载<JAVA_HOME>\lib\ext目录中的,或者被java.ext.dirs系统变量所指定的类库,可以直接使用
 
            深入理解Java虚拟机 - 类加载器应用程序类加载器(Application ClassLoader)
 
                        由sun.misc.Lanucher$AppClassLoader实现,该加载器是ClassLoader中的getSystemClassLoader()方法的返回值,所以一般也称系统类加载器。负责加载用户路径(-classpath)上的类库,开发者可以直接使用该加载器,如果没有显示定义,一般情况下使用的就是该类加载器
 
        下图为类加载器的双亲委派模型:
 
    深入理解Java虚拟机 - 类加载器  深入理解Java虚拟机 - 类加载器
 
        双亲委派模型除了顶层的启动类加载器外,其余的类加载器都应当有自己的父类实现,该实现不是通过继承来实现的,而是通过组合来实现的,通过这样的层次关系,实现了类加载的优先级。
 
破坏双亲委派模型:
 
    双亲委派模型并非强制性约束,而是java设计者推荐的类加载器实现模型。破坏双亲委派模型的两个典型是:
 
    JDNI和OSGi
 
    OSGi实现其热部署的关键是其自定义类加载器的实现,每个程序模块(Bundle)都有自己的一个实现,当需要替换bundle时,会将类加载器一同替换以实现热替换。OSGi中的类加载器已经不再具有双亲委派这种具有典型层次结构特征了,而是更加类似于网状结构。
 
    
    
上一篇:【C/C++】Linux下system()函数引发的错误


下一篇:iOS 简单音乐播放器 界面搭建