ClassLoader:类加载器。Java中所有的类都通过类加载器j进行加载,包含几种加载器:
BootStrapClassLoader 使用C++编写属于Java的JVM层面。用于加载核心类库(lib)下的类库
ExtensionClassLoader 用于加载Java lib/ext下的类库
ApplicationClassLoader 也称SystemClassLoader 用于加载classPath下的类库
首先Java中类加载有五个过程:加载、验证、准备、解析、初始化。类加载器通过类全名读取类的二进制z字节流到JVM,然后转化成一个与目标类d对应的Class实例。JVM提供上面三种类加载器。一个类由不同加载器实例加载时,会在方法区产生不同类,但是彼此不可见,在堆中产生不同class实例。
ApplicationClassLoader的parent是ExtensionClassLoader,ExtensionClassLoader的parent是BootStrapClassLoader。
我们使用Java类库中的类进行获取ClassLoader:
System.out.println(String.class.getClassLoader());
System.out.println(ArrayList.class.getClassLoader());
结果:
这是因为Java环境获取不到对应class,Java的类或者说jre/lib包下的类,由根加载器BootStrapClassLoader加载,环境在C++中。
我们编写任意一个类AA,使用
System.out.println(AA.class.getClassLoader());
得到如下结果:
得到的结果是AppClassLoader也就是之前说的ApplicationClassLoader,再使用
System.out.println(AA.class.getClassLoader().getParent());
得到如下结果
再使用
System.out.println(AA.class.getClassLoader().getParent().getParent());
得到的结果便是null了。因为拿不到BootStrapClassLoader
调用对象的getClass()方法是获取当前对象类的类型,该部分数据存储在方法区中,getClass().getClassLoader()方法是获取当前类型的类加载器。由于Java中所有类都通过类加载器加载到jvm中,且各个类加载器存在父子关系,子知道父的存在,父不知道子的存在,由于此不同子之间加载的类型是无法互相访问的(虽然都在方法区中),正是因为这样,通过当前类的加载器加载资源能够保证是同一个类加载器加载的。
InputStream resourceAsStream = AA.class.getClassLoader().getResourceAsStream("aa.txt");
JVM加载一个类时由BootStrapClassLoader首先进行查找加载,找不到时再有其子类ExtensionClassLoader查找加载,再找不到时由ApplicationClassLoader查找加载。这也就是“双亲委派机制”。
2.线程中的ClassLoader
每个运行中的线程都有成员ContextClassLoader线程上下文ClassLoader,用于在运行时动态加载其它类。通过
ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
可以获取当前运行线程的上下文ClassLoader。通过
Thread.currentThread().setContextClassLoader(new ClassLoader() {
@Override
public Class> loadClass(String name) throws ClassNotFoundException {
return super.loadClass(name);
}
});
可以设置当前线程的ContextClassLoader
事实上所有Java程序都运行在线程中,若一个程序没有通过上述方法设置过ContextClassLoader,对于一般的jJava类下面两个方法获取的ClassLoader一般是同一个:
this.getClass().getClassLoader();
Thread.currentThread().getContextClassLoader();
上述两个方法区别:
第一个得到的是静态的ClassLoader,表明类的加载者
第二个得到的是动态的ClassLoader,表明当前线程。对于单例模式的类、静态的类载入一次后可能被其它多个线程调用,对于这些类,载入的ClassLoader和执行的线程的ClassLoader通常不同。
3.web应用中ClassLoader
以tomcat中webapp的ClassLoader来说,这类Class Loader与之前说过的机制略有不同,web应用线程会尝试自己加载(ContextPath/web-inf/....)中的类,若是加载不到,再请求父加载器加载。对于webapp线程,他的contextCloassloader是WebAppClassLoader,对于tomcat Server线程,他的ContextClassLoader是catalinaClassLoader。除了上述获取动态ClassLoader和获取静态ClassLoader外还可通过:
ClassLoader.getSystemClassLoader();
获取系统入口点所使用的ClassLoader。此类SystemClassLoader与根ClassLoader不同,JVM下SystemClassLoader通常为AppClassLoader。
ClassLoader可广泛用于资源载入层面,对于类资源,类可通过new,文件可进行IO。
类资源:
1.Class clazz=Class.forName("com.dabai.AA");
AA aa=(AA)clazz.newInstance():2.AA aa=newAA();3.ClassLoader cl;
Class clazz=cl.loadClass("com.dabai.AA");
AA aa=clazz.newInstance();
文件资源:
假设AA类想要读取 com/dabai/conf/ 下文件conf.properties,我们可以通过绝对路径和相对路径读取,绝对路径自然是包括磁盘符的,相对路径的值是相对ClassLoader。将ClassLoader视为一棵树,相对与该ClassLoader路径后的资源都能被加载到
InputStream resourceAsStream3 = Thread.currentThread().getContextClassLoader().getResourceAsStream("com/dabai/conf/conf.properties");
获取文件URL绝对路径:
URL resource = BB.class.getClassLoader().getResource("com/dabai/Test/conf/conf.properties");
System.out.println(resource);
Java中getResource()会进入到ClassLoader getResource()中,通过main方法启动时,当前ClassLoader就是AppClassLoader,其parent就是ExtensionClassLoader,再其parent就是BootStrapClassLoader。当BootStrapResource都无法找到对应资源时,就从findResource(name)中将返回值返回。
4.其它
ClassLoader的线程安全问题
类加载器需要b保证线程安全,当装载一个不存在的类时,由于双亲委派机制的存在,强制加载会报错SecurityException。
自定义类加载器的话可继承ClassLoader并重写findClass方法
随口一说:类加载器不加载接口,嗯。