系统类加载器继承层次图
通过图一和图二我们可以看出,类加载器均是继承自 java.lang.ClassLoader
抽象类。我们下面我们就看简要介绍一下 java.lang.ClassLoader 中几个最重要的
方法:
//加载指定名称(包括包名)的二进制类型,供用户调用的接口
public Class<?> loadClass(String name) throws
ClassNotFoundException{//…}
//加载指定名称(包括包名)的二进制类型,同时指定是否解析(但是,这里的
resolve 参数不一定真正能达到解析的效果~_~),供继承用
protectedsynchronized Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException{//…}
//findClass 方法一般被 loadClass 方法调用去加载指定名称类,供继承用
protected Class<?> findClass(String name) throws ClassNotFoundException
{//…}
//定义类型,一般在 findClass 方法中读取到对应字节码后调用,可以看出不可继
承(说明:JVM 已经实现了对应的具体功能,解析对应的字节码,产生对应的内
部数据结构放置到方法区,所以无需覆写,直接调用就可以了)
protected final Class<?> defineClass(String name, byte[] b, int off, int len)
throws ClassFormatError{//…}
通过进一步分析标准扩展类加载器(sun.misc.Launcher$ExtClassLoader)
和系统类加载器(sun.misc.Launcher$AppClassLoader)的代码以及其公共父类
(java.net.URLClassLoader 和 java.security.SecureClassLoader)的代码可以看
出 , 都 没 有 覆 写 java.lang.ClassLoader 中 默 认 的 加 载 委 派 规 则 ---
loadClass(…)方法。既然这样,我们就可以通过分析 java.lang.ClassLoader
中的 loadClass(String name)方法的代码就可以分析出虚拟机默认采用的双亲
委派机制到底是什么模样:
评论0
最新资源