Bootstrap、Extension、ApplicationClassLoader

        Bootstrap Class Loader &＃xff0c;Extension Class Loader &＃xff0c;Application Class Loader三种Class Loader是JVM 系统已经事先实现。
        Bootstrap Class Loader 采用的是C或其他相应语言编写&＃xff08;根据JRE 操作系统版本不同而不同&＃xff09;&＃xff0c;其他两种Class Loader 均采用Java 语言编写&＃xff0c;他们的实现为ExtClassLoader 与AppClassLoader 两个内部静态类&＃xff0c;位于sun.misc.Launcher内&＃xff0c;而Launcher则位于rt.jar中。
        以下网址可以下载JDK 的源码实现&＃xff1a;
        http://download.java.net/openjdk/jdk6/
        通过源码可以是我们更进一步了解Class Loader 的内部实现及流程。

        Bootstrap Class Loader
        Bootstrap Class Loader 的实现位于${openjdk}\hotspot\src\share\vm\classfile 目录下的 classLoader.cpp 与classLoader.hpp&＃xff0c;打开源代码可以发现Bootstrap Class Loader是采用C&＃43;&＃43; 编写的&＃xff0c;这就是上一节代码中为什么得不到Bootstrap Class Loader 对象的原因。

        该ClassLoader 可以做到根据类文件名来加载类&＃xff0c;这其实就和java.lang.ClassLoader 的loadClass 功能非常相近了。

ClassFileStream* ClassPathDirEntry::open_stream(const char* name) {...jio_snprintf(path, sizeof(path), "%s%s%s", _dir, os::file_separator(), name)...
}

        可以看到path&＃61;_dir &＃43; 文件分隔符 &＃43; name&＃xff0c;得到path 后&＃xff0c;就是读取文件并存放到byte[] 的过程了。

要想path 直接可用&＃xff0c;得有两个前提&＃xff1a;

        (1) _dir事先已经配置好;
        (2)name 也应该先经过了处理;
        例如&＃xff1a;
        java.lang.String&＃xff0c;会先被转换成java/lang/String.class;
        又假如:
        _dir 为/usr/local/java/src;
        name 为com/test/HelloWorld.class;
        path 最终即为/usr/local/java/src/com/test/HelloWorld.class;

        加载类文件过程&＃xff1a;

instanceKlassHandle ClassLoader::load_classfile(symbolHandle h_name, TRAPS) {ResourceMark rm(THREAD);EventMark m("loading class " INTPTR_FORMAT, (address)h_name());ThreadProfilerMark tpm(ThreadProfilerMark::classLoaderRegion);stringStream st;// st.print() uses too much stack space while handling a StackOverflowError// st.print("%s.class", h_name->as_utf8());st.print_raw(h_name->as_utf8());st.print_raw(".class");char* name &＃61; st.as_string();// Lookup stream for parsing .class fileClassFileStream* stream &＃61; NULL;int classpath_index &＃61; 0;{PerfClassTraceTime vmtimer(perf_sys_class_lookup_time(),((JavaThread*) THREAD)->get_thread_stat()->perf_timers_addr(),PerfClassTraceTime::CLASS_LOAD);ClassPathEntry* e &＃61; _first_entry;while (e !&＃61; NULL) {stream &＃61; e->open_stream(name);if (stream !&＃61; NULL) {break;}e &＃61; e->next();&＃43;&＃43;classpath_index;}}instanceKlassHandle h(THREAD, klassOop(NULL));if (stream !&＃61; NULL) {// class file found, parse itClassFileParser parser(stream);Handle class_loader;Handle protection_domain;symbolHandle parsed_name;instanceKlassHandle result &＃61; parser.parseClassFile(h_name,class_loader,protection_domain,parsed_name,false,CHECK_(h));// add to package tableif (add_package(name, classpath_index, THREAD)) {h &＃61; result;}}return h;
}

        初始化过程&＃xff1a;

void ClassLoader::initialize() {...// lookup zip library entry pointsload_zip_library();// initialize search pathsetup_bootstrap_search_path();...
}

        其中load_zip_library() 即加载zip 类库&＃xff0c;从而便于处理jar (可以认为jar 是一种特殊的zip 压缩)&＃xff1b;而setup_bootstrap_search_path() 即为初始化BootstrapClassLoader 的查找路径&＃xff0c;其实就是在初始化上文中每个ClassPathEntry 的_dir。

        打开${openjdk}\hotspot\src\share\vm\runtime\os.cpp 文件&＃xff0c;找到set_boot_path()方法&＃xff0c;会发现Bootstrap Class Loader 已经将所要加载的类库jar 文件固化至代码中了&＃xff0c;这些就是JVM 启动时必须要加载的文件。

bool os::set_boot_path(char fileSep, char pathSep) {const char* home &＃61; Arguments::get_java_home();int home_len &＃61; (int)strlen(home);static const char* meta_index_dir_format &＃61; "%/lib/";static const char* meta_index_format &＃61; "%/lib/meta-index";char* meta_index &＃61; format_boot_path(meta_index_format, home, home_len, fileSep, pathSep);if (meta_index &＃61;&＃61; NULL) return false;char* meta_index_dir &＃61; format_boot_path(meta_index_dir_format, home, home_len, fileSep, pathSep);if (meta_index_dir &＃61;&＃61; NULL) return false;Arguments::set_meta_index_path(meta_index, meta_index_dir);// Any modification to the JAR-file list, for the boot classpath must be// aligned with install/install/make/common/Pack.gmk. Note: boot class// path class JARs, are stripped for StackMapTable to reduce download size.static const char classpath_format[] &＃61;"%/lib/resources.jar:""%/lib/rt.jar:""%/lib/sunrsasign.jar:""%/lib/jsse.jar:""%/lib/jce.jar:""%/lib/charsets.jar:"// ## TEMPORARY hack to keep the legacy launcher working when// ## only the boot module is installed (cf. j.l.ClassLoader)"%/lib/modules/jdk.boot.jar:""%/classes";char* sysclasspath &＃61; format_boot_path(classpath_format, home, home_len, fileSep, pathSep);if (sysclasspath &＃61;&＃61; NULL) return false;Arguments::set_sysclasspath(sysclasspath);return true;
}

        本人对C&＃43;&＃43; 不甚了解&＃xff0c;所以无法就代码及流程做更进一步的讲解&＃xff0c;希望大家谅解&＃xff0c;也欢迎大家补充。

        AppClassLoader 与ExtClassLoader

        打开sun.misc.Launcher 的源代码&＃xff0c;源代码位置在${openjdk}\jdk\src\share\classes\sun\misc\Launcher.java &＃xff0c;ExtClassLoader 与AppClassLoader 是Launcher 类的内部类&＃xff0c;代码如下&＃xff1a;

/*
* The class loader used for loading installed extensions.
*/
static class ExtClassLoader extends URLClassLoader {}/**
* The class loader used for loading from java.class.path.
* runs in a restricted security context.
*/
static class AppClassLoader extends URLClassLoader {}

        从继承关系可以向上一直追溯直至java.lang.ClassLoader 实现类&＃xff0c;两者的继承关系如下&＃xff1a;

java.lang.Object--- java.lang.ClassLoader--- java.security.SecureClassLoader--- java.net.URLClassLoader--- sun.misc.Launcher$ExtClassLoaderjava.lang.Object--- java.lang.ClassLoader--- java.security.SecureClassLoader--- java.net.URLClassLoader--- sun.misc.Launcher$AppClassLoader

        从下图可以更直观的观察出他们的继承关系(引用自网络)&＃xff1a;

        AppClassLoader 与ExtClassLoader 基本都是调用父类的方法&＃xff0c;只是在其中加入了一些相应的业务逻辑&＃xff0c;所以这里就不分析他们了&＃xff0c;在ClassLoader这节中会更详细的分析。