classloader就是把类文件加载到jvm*虚拟机使用,先看一个magic小例子:
首先,我定义一个alex/vicky包,然后在这个包内定义一个接口:
public interfaceIService {
voidservice();
}
然后使用这个接口定义一个实现类:
public classService extendsIService{
@Override
publicvoidservice(){
System.out.println("Alex");
}
}
然后把这个类定义删掉,把这个类生成的class文件放到c:/alex/vicky文件夹下.
再做一个实现类:
public classMain {
public static voidmain(String[] args) throwsException {
URLu = newURL("file:c:/");
URLClassLoaderucl = newURLClassLoader(newURL[] { u });
Classc = ucl.loadClass("alex.vicky.Service");
IServiceobj = (IService) c.newInstance();
obj.service();
}
}
可以看到,我们通过URL方式,远程加载了类文件.
一旦一个类被载入JVM中，同一个类就不会被再次载入了（切记，同一个类）。在Java中，一个类用其完全匹配类名(fullyqualified classname)作为标识，这里指的完全匹配类名包括包名和类名。但在JVM中一个类用其全名和一个加载类ClassLoader的实例作为唯一标识。
java的几种ClassLoader：
在java中，我们可以取得这么以下三个ClassLoader类：
一． ClassLoader基本概念
1．ClassLoader分类
类装载器是用来把类(class)装载进JVM的。
JVM规范定义了两种类型的类装载器：启动内装载器(bootstrap)和用户自定义装载器(user-definedclass loader)。
JVM在运行时会产生三个ClassLoader:BootstrapClassLoader、ExtensionClassLoader和AppClassLoader。Bootstrap是用C++编写的，我们在Java中看不到它,是Null,是JVM自带的类装载器，用来装载核心类库，如java.lang.*等。
AppClassLoader的Parent是ExtClassLoader，而ExtClassLoader的Parent为BootstrapClassLoader。
Java提供了抽象类ClassLoader，所有用户自定义类装载器都实例化自ClassLoader的子类。系统类装载器可以通过ClassLoader.getSystemClassLoader()方法得到。
系统为什么要分别指定这么多的ClassLoader类呢？
答案在于因为java是动态加载类的，这样的话，可以节省内存，用到什么加载什么，就是这个道理，然而系统在运行的时候并不知道我们这个应用与需要加载些什么类，那么，就采用这种逐级加载的方式
(1)首先加载核心API，让系统最基本的运行起来
(2)加载扩展类
(3)加载用户自定义的类
publicstatic void main(String[] args) {
System.out.println(System.getProperty("sun.boot.class.path"));
System.out.println(System.getProperty("java.ext.dirs"));
System.out.println(System.getProperty("java.class.path"));
}
程序结果为：
E:\Myeclipse6.0\jre\lib\rt.jar;E:\Myeclipse 6.0\jre\lib\i18n.jar;E:\Myeclipse6.0\jre\lib\sunrsasign.jar;E:\MyEclipse6.0\jre\lib\JSse.jar;E:\MyEclipse 6.0\jre\lib\jce.jar;E:\MyEclipse6.0\jre\lib\charsets.jar;E:\MyEclipse 6.0\jre\classes
E:\MyEclipse6.0\jre\lib\ext
E:\workspace\ClassLoaderDemo\bin
在上面的结果中，你可以清晰看见三个ClassLoader分别加载类的路径；也知道为什么我们在编写程序的时候，要把用到的jar包放在工程的classpath下面啦，也知道我们为什么可以不加载java.lang.*包啦！其中java.lang.*就在rt.jar包中；
ClassLoader的加载机制：
现在我们设计这种一下Demo:
packagejava.net;
publicclass URL {
privateString path;
publicURL(String path) {
this.path= path;
}
publicString toString() {
returnthis.path + " new Path";
}
}
packagejava.net;
importjava.net.*;
publicclass TheSameClsDemo {
publicstatic void main(String[] args) {
URLurl = new URL("http://www.baidu.com");
System.out.println(url.toString());
}
}
在这种情况下，系统会提示我们出现异常，因为我们有两个相同的类，一个是真正的URL，一个是我在上面实现的伪类；出现异常是正常的，因为你想想，如果我们在执行一个applet的时候，程序自己实现了一个String的类覆盖了我们虚拟机上面的真正的String类，那么在这个String里面，不怀好意的人可以任意的实现一些功能；这就造成极不安全的隐患；所以java采用了一种名为“双亲委托”的加载模式；
以下是jdk源代码：
protectedsynchronized Class<?> loadClass(String name, boolean resolve)
throwsClassNotFoundException
{
//First, check if the class has already been loaded
Classc = findLoadedClass(name);
if(c == null) {
try{
if(parent != null) {
c= parent.loadClass(name, false);
}else {
c= findBootstrapClass0(name);
}
}catch (ClassNotFoundException e) {
//If still not found, then invoke findClass in order to find theclass.
c= findClass(name);
}
}
if(resolve) {
resolveClass(c);
}
returnc;
}
在上面的代码中，我们可以清晰的看见，我们调用一个ClassLoader加载程序的时候，这个ClassLoader会先调用设置好的parentClassLoader来加载这个类，如果parent是null的话，则默认为BootClassLoader类，只有在parent没有找的情况下，自己才会加载，这就避免我们重写一些系统类，来破坏系统的安全；
类与它所依赖的类的classloader机制:
如果一个类是由某个classloader加载，那么这个类依赖的类（非显式的通过某个classloader加载）必须也由该classloader或其父classloader加载，无视子classloader
通过thread.getContextClassloader:
thread.getContextClassloader默认返回AppClassLoader,除非你显式setContextClassloader
来看一下jdbc中如何使用classloader:
一般我们写一个jdbc程序都会这样:
Class.forName("com.mysql.jdbc.Driver");
Stringurl ="jdbc:mysql://127.0.0.1/test?useUnicode=true&characterEncoding=utf-8";
Stringuser = "root";
Stringpsw = "yanyan";
Connectioncon = DriverManager.getConnection(url,user, psw);
为什么需要第一句话?
其实第一句话可以用下面这句话替代:
com.mysql.jdbc.Driverdriver = new com.mysql.jdbc.Driver();
其他都不用变化,有人会问,driver对象从来没有用到.对,它的效果就是在调用DriverManager的getConnection方法之前，保证相应的Driver类已经被加载到jvm中，并且完成了类的初始化工作就行了.注意了，如果我们进行如下操作，程序是不能正常运行的，因为这样仅仅使Driver类被装载到jvm中，却没有进行相应的初始化工作。
com.mysql.jdbc.Driverdriver = null;
//or：
ClassLoadercl = new ClassLoader();
cl.loadClass("com.mysql.jdbc.Driver");
我们都知道JDBC是使用Bridge模式进行设计的，DriverManager就是其中的Abstraction，java.sql.Driver是Implementor，com.mysql.jdbc.Driver是Implementor的一个具体实现（请参考GOF的Bridge模式的描述）。大家注意了，前一个Driver是一个接口，后者却是一个类，它实现了前面的Driver接口。
Bridge模式中，Abstraction（DriverManager）是要拥有一个Implementor（Driver）的引用的，但是我们在使用过程中，并没有将Driver对象注册到DriverManager中去啊，这是怎么回事呢？jdk文档对Driver的描述中有这么一句：
Whena Driver class is loaded, it should create an instance of itself andregister it with the DriverManager
哦，原来是com.mysql.jdbc.Driver在装载完后自动帮我们完成了这一步骤。源代码是这样的：
packagecom.mysql.jdbc
publicclass Driver extends NonRegisteringDriver implements java.sql.Driver{
static{
try{
java.sql.DriverManager.registerDriver(newDriver());
}catch (SQLException E) {
thrownew RuntimeException("Can't register driver!");
}
}
publicDriver() throws SQLException {
//Required for Class.forName().newInstance()
}
}
再看一下DriverManager.getConnection(url,user, psw);方法:
ClassLoadercallerCL = DriverManager.getCallerClassLoader();
getConnection(url,info, callerCL)
==>
if(callerCL== null){
callerCL= Thread.currentThread().getContextClassLoader();
}
上面的意思是:代码意思是如果DriverManager类的类加载器为空的话，就使用当前线程的类加载器。仔细想想，DriverManager在rt.jar包中，它是由JDK的启动类加载器加载的,而启动类加载器是C编写的，所以取得的都是空，再者，使用当前线程类加载器的话，那么交由程序编写者来保证能够加载驱动类。而不至于驱动器类无法加载。非常高明的手段~!
Class的这种设计引入了一个有趣的模式:
某个框架制定某个API，而这些api的实现是有其他供应商来提供，为了能让框架类（处于较高层次的classloader）使用api的实现(处于较低层次的classloader)
通过thread.getContextClassloader是来传递classloader（有时候需要thread.setContextClassloader设置好api实现的classloader）,用此classloader.getResources找出所有的api实现的具体类名，再用classloader加载之,此时框架都不需要知道api的实现类的类名就能加载之，程序显示了良好的动态性和可扩展性。