java ClassLoader与文件定位

要利用ClassLoader获取文件,首先要了解ClassLoader的工作原理:

程序编制一般需经编辑、编译、连接、加载和运行几个步骤。在我们的应用中，有一些公共代码是需要反复使用，就把这些代码编译为“库”文件；在连接步骤中，连接器将从库文件取得所需的代码，复制到生成的可执行文件中。这种库称为静态库，其特点是可执行文件中包含了库代码的一份完整拷贝；缺点就是被多次使用就会有多份冗余拷贝。

为了克服这个缺点可以采用动态连接库。这个时候连接器仅仅是在可执行文件中打上标志，说明需要使用哪些动态连接库；当运行程序时，加载器根据这些标志把所需的动态连接库加载到内存。

另外在当前的编程环境中，一般都提供方法让程序在运行的时候把某个特定的动态连接库加载并运行，也可以将其卸载（例如Win32的LoadLibrary()&FreeLibrary()和Posix的dlopen()&dlclose()）。这个功能被广泛地用于在程序运行时刻更新某些功能模块或者是程序外观。

What is ClassLoader?

与普通程序不同的是，Java程序（class文件）并不是本地的可执行程序。当运行Java程序时，首先运行JVM（Java虚拟机），然后再把Java class加载到JVM里头运行，负责加载Java class的这部分就叫做Class Loader。

JVM本身包含了一个ClassLoader称为Bootstrap ClassLoader，和JVM一样，Bootstrap ClassLoader是用本地代码实现的，它负责加载核心Java Class（即所有java.*开头的类）。另外JVM还会提供两个ClassLoader，它们都是用Java语言编写的，由Bootstrap ClassLoader加载；其中Extension ClassLoader负责加载扩展的Java class（例如所有javax.*开头的类和存放在JRE的ext目录下的类），Application ClassLoader负责加载应用程序自身的类。AppClassLoader的Parent是ExtClassLoader，而ExtClassLoader的Parent为Bootstrap ClassLoader。需要指出的是，Class Loader是对象，它的父子关系和类的父子关系没有任何关系。


When to load the class?

什么时候JVM会使用ClassLoader加载一个类呢？当你使用java去执行一个类，JVM使用Application ClassLoader加载这个类；然后如果类A引用了类B，不管是直接引用还是用Class.forName()引用，JVM就会找到加载类A的ClassLoader，并用这个ClassLoader来加载类B。

Why use your own ClassLoader?

似乎JVM自身的ClassLoader已经足够了，为什么我们还需要创建自己的ClassLoader呢？

因为JVM自带的ClassLoader只是懂得从本地文件系统加载标准的java class文件，如果编写你自己的ClassLoader，你可以做到：
1）在执行非置信代码之前，自动验证数字签名
2）动态地创建符合用户特定需要的定制化构建类
3）从特定的场所取得java class，例如数据库中
4) 等等

事实上当使用Applet的时候，就用到了特定的ClassLoader，因为这时需要从网络上加载java class，并且要检查相关的安全信息。

目前的应用服务器大都使用了ClassLoader技术，即使你不需要创建自己的ClassLoader，了解其原理也有助于更好地部署自己的应用。

ClassLoader Tree & Delegation Model

当你决定创建你自己的ClassLoader时，需要继承java.lang.ClassLoader或者它的子类。在实例化每个ClassLoader对象时，需要指定一个父对象；如果没有指定的话，系统自动指定ClassLoader.getSystemClassLoader()为父对象。如下图：


在Java 1.2后，java class的加载采用所谓的委托模式（Delegation Modle），当调用一个ClassLoader.loadClass()加载一个类的时候，将遵循以下的步骤：
1）检查这个类是否已经被加载进来了？
2）如果还没有加载，调用父对象加载该类
3）如果父对象无法加载，调用本对象的findClass()取得这个类。

所以当创建自己的Class Loader时，只需要重载findClass()这个方法。

Unloading? Reloading?

当一个java class被加载到JVM之后，它有没有可能被卸载呢？我们知道Win32有FreeLibrary()函数，Posix有dlclose()函数可以被调用来卸载指定的动态连接库，但是Java并没有提供一个UnloadClass()的方法来卸载指定的类。

在Java中，java class的卸载仅仅是一种对系统的优化，有助于减少应用对内存的占用。既然是一种优化方法，那么就完全是JVM自行决定如何实现，对Java开发人员来说是完全透明的。

在什么时候一个java class/interface会被卸载呢？Sun公司的原话是这么说的："class or interface may be unloaded if and only if its class loader is unreachable. Classes loaded by the bootstrap loader may not be unloaded."

事实上我们关心的不是如何卸载类的，我们关心的是如何更新已经被加载了的类从而更新应用的功能。JSP则是一个非常典型的例子，如果一个JSP文件被更改了，应用服务器则需要把更改后的JSP重新编译，然后加载新生成的类来响应后继的请求。

其实一个已经加载的类是无法被更新的，如果你试图用同一个ClassLoader再次加载同一个类，就会得到异常（java.lang.LinkageError: duplicate class definition），我们只能够重新创建一个新的ClassLoader实例来再次加载新类。至于原来已经加载的类，开发人员不必去管它，因为它可能还有实例正在被使用，只要相关的实例都被内存回收了，那么JVM就会在适当的时候把不会再使用的类卸载。


[u][b]而在使用ClassLoader的getResource方法的时候，永远是以Classpath为直接起点开始寻找
资源的。不用担心从什么包开始寻找的问题。

用Class.getResource不加/就是从当前包开始找，用ClassLoader.getResource不加/就是
直接从Classpath的起点开始寻找。

Class.getResource从根目录查找使用/,ClassLoader从根目录查找使用\\
[/b][/u]


用JAVA获取文件，听似简单，但对于很多像我这样的新人来说，还是掌握颇浅，用起来感觉颇深，大常最经常用的，就是用JAVA的File类，如要取得c:/test.txt文件，就会这样用File file = new File("c:/test.txt");这样用有什么问题，相信大家都知道，就是路径硬编码，对于JAVA精神来说，应用应该一次成型，到处可用，并且从现实应用来讲，最终生成的应用也会部署到Windows外的操作系统中，对于linux来说，在应用中用了c:/这样的字样，就是失败，所以，我们应该尽量避免使用硬编码，即直接使用绝对路径。



　　在Servlet应用中，有一个getRealPath(String str)的方法，这个方法尽管也可以动态地获得文件的路径，不秘直接手写绝对路径，但这也是一个不被建议使用的方法，那么，我们有什么方法可以更好地获得文件呢?



那就是Class.getResource()与Class.getResourceAsStream()方法，但很多人还是不太懂它的用法，因为很多人（比如不久前的我）都不知道应该传怎么样的参数给它，当然，有些人己经用得如火纯青，这些人是不需要照顾的，在此仅给不会或者还不是很熟的人解释一点点。





比如我们有以下目录

|--project

|--src

|--javaapplication

|--Test.java

|--file1.txt

|--file2.txt

|--build

|--javaapplication

|--Test.class

|--file3.txt

|--file4.txt



在上面的目录中，有一个src目录，这是JAVA源文件的目录，有一个build目录，这是JAVA编译后文件(.class文件等）的存放目录

那么，我们在Test类中应该如何分别获得

file1.txt file2.txt file3.txt file4.txt这四个文件呢？



首先讲file3.txt与file4.txt

file3.txt:

方法一：File file3 = new File(Test.class.getResource("file3.txt").getFile());

方法二：File file3 = new File(Test.class.getResource("/javaapplication/file3.txt").getFile());

方法三：File file3 = new File(Test.class.getClassLoader().getResource("javaapplication/file3.txt").getFile());



file4.txt:

方法一：File file4 = new File(Test.class.getResource("/file4.txt").getFile());

方法二：File file4 = new File(Test.class.getClassLoader().getResource("file4.txt").getFile());



很好，我们可以有多种方法选择，但是file1与file2文件呢？如何获得？

答案是，你只能写上它们的绝对路径，不能像file3与file4一样用class.getResource()这种方法获得，它们的获取方法如下

假如整个project目录放在c:/下，那么file1与file2的获取方法分别为

file1.txt

方法一：File file1 = new File("c:/project/src/javaapplication/file1.txt");

方法二：。。。没有



file2.txt

方法一：File file2 = new File("c:/project/src/file2.txt");

方法二：。。。也没有



总结一下，就是你想获得文件，你得从最终生成的.class文件为着手点，不要以.java文件的路径为出发点，因为真正使用的就是.class，不会拿个.java文件就使用，因为java是编译型语言嘛



至于getResouce()方法的参数，你以class为出发点，再结合相对路径的概念，就可以准确地定位资源文件了，至于它的根目录嘛，你用不同的IDE build出来是不同的位置下的，不过都是以顶层package作为根目录，比如在Web应用中，有一个WEB-INF的目录，WEB-INF目录里面除了web.xml文件外，还有一个classes目录，没错了，它就是你这个WEB应用的package的顶层目录，也是所有.class的根目录“/”，假如clasaes目录下面有一个file.txt文件，它的相对路径就是"/file.txt"，如果相对路径不是以"/"开头，那么它就是相对于.class的路径。


http://gavin-chen.iteye.com/blog/261151

----------------------------------------------------------------------

public class LoaderSample1 {
	public static void main(String[] args) {
		Class c;
		ClassLoader cl;

		cl = ClassLoader.getSystemClassLoader();
		System.out.println("aa  " + cl+"   "+(cl instanceof ClassLoader));

		while (cl != null) {
			cl = cl.getParent();
			System.out.println("bb  " + cl+"   "+(cl instanceof ClassLoader));
		}

		try {
			c = Class.forName("java.lang.Object");
			cl = c.getClassLoader();
			System.out.println("java.lang.Object’s loader is " + cl +"  "+(cl instanceof ClassLoader));

			c = Class.forName("LoaderSample1");
			cl = c.getClassLoader();
			System.out.println("LoaderSample1’s loader is " + cl +"  "+ (cl instanceof ClassLoader));
			//System.out.println(ClassLoader);
		} catch (Exception e) {
			e.printStackTrace();
		} 
	}
}

运行结果:
aa  sun.misc.Launcher$AppClassLoader@19821f   true
bb  sun.misc.Launcher$ExtClassLoader@addbf1   true
bb  null   false
java.lang.Object’s loader is null  false
LoaderSample1’s loader is sun.misc.Launcher$AppClassLoader@19821f  true