jvm classloader

Java类加载机制详解

最新推荐文章于 2024-01-05 15:22:07 发布

最新推荐文章于 2024-01-05 15:22:07 发布 · 152 阅读

文章标签：

#JVM #OSGI #Java #虚拟机 #EXT

JAVA 专栏收录该内容

11 篇文章

订阅专栏

本文通过实例演示了Java中URLClassLoader的使用方法，包括如何从文件系统和远程服务器加载类。同时介绍了Java类加载器的基本架构，展示了双亲委派模型的工作原理。

1. 从一个简单小实验开始：

(1) Eclipse下建一简单Java project，写一个简单程序，如下：

package com.javaeye.loader;

public class URLClassLoaderTest {
	public void show() {
		System.out.println("I am running...");
	}
}

(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，建立完成后我们可以访问如下图：

(5) 给出两端端测试代码：

                @Test
	public void testInWeb() throws Exception{
		URL[] urls = new URL[]{new URL("http://192.168.66.250/root/java/")};
		URLClassLoader loader = new URLClassLoader(urls);
		Class clas = loader.loadClass("com.javaeye.loader.URLClassLoaderTest");
		Method m = clas.getMethods()[0];
		Object o = clas.newInstance();
		m.invoke(o);
	}
	@Test
	public void testInFileSystem() throws Exception{
		URL[] urls = new URL[]{new URL("file:/C:/java/")};
		URLClassLoader loader = new URLClassLoader(urls);
		Class clas = loader.loadClass("com.javaeye.loader.URLClassLoaderTest");
		Method m = clas.getMethods()[0];
		Object o = clas.newInstance();
		m.invoke(o);
	}

分别运行两端代码他们输出结果都是:

I am running...

分析：

为什么会出现上述运行结果，很明显是因为com.learn.loader.URLClassLoaderTest对象被加载到内存，此对象中的show方法被执行；

思考：

Java 语言由于在 Java 虚拟机 (JVM) 上运行而显得与众不同，之所以与众不同是因为Java中已编译的程序是一种特殊的、独立于平台的格式，并非依赖于它们所运行的机器。在很大程度上，这种格式不同于传统的可执行程序格式。与 C 或 C++ 编写的程序不同，Java 程序并不是一个可执行文件，而是由许多独立的类文件组成，每一个文件对应于一个 Java 类。此外，这些类文件并非立即全部都装入内存，而是根据程序需要装入内存。ClassLoader 是 JVM 中将类装入内存的工具。

2.jvm classLoader architecture

同样给出一个例子代码：

public void testClassLoader2() throws Exception{
		URL[] urls = new URL[]{new URL("http://192.168.66.250/root/java/")};
		URLClassLoader loader = new URLClassLoader(urls);
		System.out.println(loader.getClass());
		System.out.println(loader.getParent().getClass());
		System.out.println(loader.getParent().getParent().getClass());
		System.out.println(loader.getParent().getParent().getParent());
	}

运行结果如下：

class java.net.URLClassLoader
class sun.misc.Launcher$AppClassLoader
class sun.misc.Launcher$ExtClassLoader
null

要解释这个运行结果需要说明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；