Java的设计初衷是主要面向嵌入式领域,对于自己定义的一些类,考虑使用依需求载入原则。即在程序使用到时才载入类,节省内存消耗,这时就可以通过类载入器来动态载入。
假设你平时仅仅是做web开发,那应该非常少会跟类载入器打交道,但假设你想深入学习tomcatserver的架构,它是不可缺少的。所谓类载入器。就是用于载入Java类到Java虚拟机中,它负责读取Java字节码。并转换成java.lang.Class类的一个实例。使字节代码.class文件得以执行。
一般类载入器负责依据一个指定的类找到相应的字节代码,然后依据这些代码定义成一个Java类。另外还负责载入资源。包含图像文件和配置文件。
类载入器在实际使用中给我们带来的优点是。它能够使Java类动态地载入到JVM并执行。就可以在程序执行时再载入类,提供了非常灵活的动态载入方式。
比如我们熟悉的Applet,从远程server下载字节码到client动态载入到JVM便能够执行。
在Java的庞大体系中,能够将系统分为三种类载入器,各自是:
① 启动类载入器(Bootstrap ClassLoader):载入对象是Java核心库。把一些关键的Java类载入进JVM,这个载入器使用原生代码(C/C++)实现的。并非继承java.lang.ClassLoader,它是全部其它类载入器的终于父载入器,负责载入<JAVA_HOME>/jre/lib文件夹下且被JVM指定的类库。事实上它属于JVM总体的一部分,JVM一启动就将这些指定的类载入到内存中,避免以后过多的I/O操作。提高系统的执行效率。
启动类载入器无法被Java程序直接使用。
② 扩展类载入器(Extension ClassLoader):载入的对象为Java的扩展库。即载入<JAVA_HOME>/jre/lib/ext文件夹里面的类。
这个类由上面的Bootstrap ClassLoader载入,但因为Bootstrap ClassLoader并不是用Java实现,已经脱离了Java体系,所以假设尝试调用扩展类载入器的getParent()方法获取父载入器会得到null,但它的父类载入器是Bootstrap ClassLoader。
Java中能够直接使用扩展类载入器。
③ 应用程序类载入器(Application ClassLoader):亦叫系统类载入器(System ClassLoader),它负责载入用户类路径(CLASSPATH)指定的类库。假设程序没有自定义类载入器。就默认使用应用程序类载入器。它也由Bootstrap ClassLoader载入。但它的父载入类被设置成了Extension ClassLoader。
假设要使用这个载入器,可通过ClassLoader.getSystemClassLoader()获取。
假如有一天你心血来潮也想自己写一个类载入器,那么你仅仅须要继承java.lang.ClassLoader类就可以。于是能够用以下的图2-4-1来清晰表示出各种类载入器的关系,Bootstrap ClassLoader是最根本的类载入器,其不存在父类载入器,Extension ClassLoader由Bootstrap ClassLoader载入。所以它的父类载入器是Bootstrap ClassLoader。Application ClassLoader也是由Bootstrap ClassLoader载入,但它的父载入器被指向了Extension
ClassLoader,而其它全部用户自己定义的类载入器都由Application ClassLoader载入。
由此能够看出越重要的类载入器就越早被JVM载入,这是考虑到安全性。由于先载入的类载入器会充当下一个类载入器的父载入器,在双亲委派模型机制下,就能确保安全性。
那么什么是双亲委派模型?比方爷爷、爸爸、你三代单传,你们家族都遗传懒惰基因,每当遇到事情都互相推脱,如今须要一个人去买一包盐,不然今晚的菜就有色无味了。而你第一个被托付去超市买,但因为你的懒惰。你向你爸爸撒了一顿娇,你爸爸受不了你仅仅能答应帮你去,在懒惰的驱使下,你爸爸最后找了一个借口说要赶工作。让你爷爷出去走动走动顺便买一包盐,就这样你爷爷仅仅能乖乖去超市买盐。
双亲委派模型就类似这种机制。类载入器载入类时首先托付给父类载入器载入。除非父类载入器不能载入才自己载入。
这样的模型要求除了顶层的启动类载入器外,其它的类载入器都要有自己的父类载入器。假如有一个类要载入进来。一个类载入器并不会立即尝试自己将其载入,而是委派到父类载入器。父类载入器收到后又尝试委派到其父类载入器,以此类推,直到委派到启动类载入器,这样一层一层往上委派。仅仅有当父类载入器反馈自己没法完毕这个载入时,子载入器才会尝试自己载入。通过这个机制。保证了Java应用所使用的都是同一个版本号的Java核心库的类。同一时候这个机制也保证了安全性,设想假设Application ClassLoader想要载入一个有破坏性的java.lang.System类,双亲委派模型会一层层向上委派,终于委派给Bootstrap
ClassLoader,而Bootstrap ClassLoader检查到缓存中已经有了这个类。并不会再载入这个有破坏性的System类。
另外,类载入器还拥有全盘负责机制,即当一个ClassLoader载入一个类时,这个类所依赖的、引用的其它全部类都由这个ClassLoader载入,除非在程序中显性地指定另外一个ClassLoader载入。
图2-4-1 类载入器关系
在Java中。我们用全然匹配类名来标识一个类。即用包名和类名。而在JVM中。一个类由全然匹配类名和一个类载入器的实例ID作为唯一标识。
即是说同一个虚拟机能够有两个包名、类名都相同的类。仅仅要他们由两个不同类载入器载入。
于是当我们在Java中常常说两个类相不相等,必须是针对同一个类载入器载入的前提下才有意义。否则就算是相同的字节代码,由不同类载入器载入,这两个类也不是相等的。这样的特征为我们提供了隔离机制,在tomcatserver中是十分实用的。
了解了JVM的类载入器的各种机制后,看看一个类是如何被类载入器载入进来的。一个类准备载入,类载入器先推断此类是否已经被载入过(载入过的类会被缓存在内存中),假设缓存中存在此类则直接返回这个类。
否则获取父类载入器,假设父类载入器为null,则由Bootstrap ClassLoader载入并返回Class。假设父类载入器不为null,则由父类载入器载入。载入成功就返回Class,载入失败则依据类路径查找class文件,找到就载入此class并返回Class,找不到就抛出ClassNotFoundException异常。
图2-4-2 类载入过程
类载入器属于JVM级别的设计,我们非常多时候基本不会跟他打交道,可是假如你想了解整个JAVA体系是怎样工作的,假如你要设计开发自己的框架或中间件或一个较庞大的java软件。那么你必须熟悉类载入器的相关机制,在现实的设计中,依据实际情况利用类载入器能够提供类库的隔离及共享,保证你的软件不同级别的逻辑切割程序不会互相影响,提供更好的安全性。
喜欢研究java的同学能够交个朋友,以下是本人的微信号: