1. 从一个简单小实验开始:
(1) Eclipse下建一简单Java project,写一个简单程序,如下:
(2) 到项目对应bin/com/javaeye/loader下找到URLClassLoaderTest.class文件,将此文件保存,然后删除整个project;
(3) 在磁盘任何位置建立文件夹com,在com里建立javaeye,在javaeye里建立loader,我建在C盘java目录下,建立完成后将(2)中保存的URLClassLoaderTest.class文件拷贝到其中,如下:
(4) 在非本地Apache Server上任何位置建立文件夹com,在com里建立javaeye,在javaeye里建立loader文件夹,完成后将(2)中保存的 URLClassLoaderTest.class文件拷贝到其中,我的非本地计算机IP为192.168.66.250,系统为Linux Redhat, 建立完成后我们可以访问如下图:
分别运行两端代码他们输出结果都是:
分析:
为什么会出现上述运行结果,很明显是因为com.learn.loader.URLClassLoaderTest对象被加载到内存,此对象中的show方法被执行;
思考:
Java 语言由于在 Java 虚拟机 (JVM) 上运行而显得与众不同,之所以与众不同是因为Java中已编译的程序是一种特殊的、独立于平台的格式,并非依赖于它们所运行的机器。在很大程度上,这种格 式不同于传统的可执行程序格式。与 C 或 C++ 编写的程序不同,Java 程序并不是一个可执行文件,而是由许多独立的类文件组成,每一个文件对应于一个 Java 类。此外,这些类文件并非立即全部都装入内存,而是根据程序需要装入内存。ClassLoader 是 JVM 中将类装入内存的工具。
2.jvm classLoader architecture
同样给出一个例子代码:
运行结果如下:
要解释这个运行结果需要说明jvm classloader 结构,如下图:
如图所示,为了实现java安全沙箱模型顶层的类加载器安全机制, java默认采用了 " 双亲委派的加载链 " 结构,图中分为四层。和我们上面运行结果是一一对应的
最底层:User Custom ClassLoader/用户自定义类加载器(java.lang.ClassLoader的子类) ,在程序运行期间, 通过java.lang.ClassLoader的子类动态加载class文件, 体现java动态实时类装入特性。显然java.net.URLClassLoader属于此层;
AppClassLoader层:System ClassLoader/系统类加载器,主要负责java -classpath/-Djava.class.path所指的目录下的类与jar包装入工作。 java.lang.ClassLoader.getSystemClassLoader()可以得到他,上述 sun.misc.Launcher$AppClassLoader属于此层;
ExtClassloader层:Extension ClassLoader/扩展类加载器,主要负责jdk_home/lib/ext目录下的jar包或 -Djava.ext.dirs 指定目录下的jar包装入工作,sun.misc.Launcher$ExtClassLoader属于此层;
最顶层:Bootstrap ClassLoader/启动类加载器,主要负责jdk_home/lib目录下的核心 api 或 -Xbootclasspath 选项指定的jar包装入工作,为什么对应这层输出为null?是因为Bootstrap是用C++编写的,我们在Java中看不到它,是null;