java的类加载机制java的类加载器ClassLoader是一个抽象类，主要是用于将.class文件加载到JVM内存中，并转换成JVM可以识别的Class对象。ClassLoader类结构分析：      经常会用或扩展ClassLoader的几个方法及其重载方法有：      1). Class>   defineClass(byte[], int, int)             用来将byte字节流解析成JVM能够识别的Class对象，一般和findClass方法一起使用，通过直接覆盖ClassLoader父类的findClass方法来实现类的加载规则，从而取得加载类的字节码，再通过defineClass方法获取类的Class对象.在运行时能加载自己指定的类，可以用下面的方法获取：     this.getClass().getClassLoader().loadClass("com.ran.test2.Test");     com.ran.test2.Test为含包名的类名      2). Class>   findClass(String)            实现类的加载规则，从而取得加载类的字节码        3). Class>   loadClass(String)           获取指定类的Class对象      4). void   resolveClass(Class>)           在对象真正实例化时才调用

ClassLoader的等级加载机制：加载机制：双亲委派机制双亲委派机制的过程是：一个类加载器收到类加载的请求时，会先请示父类加载器进行加载，如果父类加载器找不到(在其搜索范围内没有找到)，那么才会由该类加载器自己进行加载。

从java虚拟机角度讲，只存在两种不同的类加载器：启动类加载器(BootStrap ClassLoader)：使用C++实现，是虚拟机自身一部分；其他类加载器：使用Java实现，独立于虚拟机外部，都继承抽象类ClassLoader；

从Java开发角度讲，可分为下面三种不同的加载器： 启动类加载器(BootStrap ClassLoader): 主要加载JVM自身需要的类(JavaHome的lib目录中且是虚拟机识别的类库，如rt.jar)，只是一个类加载工具，没有父加载器和子加载器； 扩展类加载器(ExtClassLoader)：主要负责加载JavaHome的lib/ext目录中和java.ext.dirs系统变量指定路径中的类库； 应用程序类加载器(AppClassLoader)：主要负责加载用户路径上(ClassPath)所指定的类库；

JVM加载class文件到内存有两种方式：1).隐式加载：不通过在代码中调用ClassLoader来加载需要的类，而是通过JVM来自动加载需要的类到内存。2).显示加载：在代码中通过调用ClassLoader来加载一个类的方式，如： 如：this.getClass().getClassLoader().loadClass("com.ran.test2.Test")，Class.forName("com.ran.test2.Test")或者自己实现ClassLoader的findClass()方法

Class文件的加载过程： 类加载的全过程包括五个阶段：加载、验证、准备、解析、初始化，其中验证、准备、解析三个过程称为连接。

加载：找到.class文件并把文件包含的字节码加载到内存中验证：确保class文件的字节流中包含的信息符合虚拟机的要求，主要包含四个检验过程：文件格式严验证、元数据验证、字节码验证、符号引用验证。准备：为类变量(static修饰的变量)分配内存并设置初始值(此时虽然有初始值，但不执行java代码，不进行初始化)，默认基本类型初始值为0，引用类型为null。解析：将常量池中的符号引用替换为直接引用，主要针对类或接口、字段、类方法、接口方法四类的符号引用的解析。初始化：类第一次被使用时，才会初始化；主要是执行类构造器()方法，执行类变量的赋值操作和静态代码块。初始化发生的时机：       new关键字实例化对象；       调用类的静态方法：       给类的静态域赋值；      使用反射调用时，如果类没初始化，需要先触发其初始化； 初始化一个类时，如果父类没有初始化，则需先触发其父类的初始化； 虚拟机启动时，用户指定执行的主类，虚拟机需要初始化这个主类。

破坏双亲委派：第一次破坏：发生在双亲委派模型出现之前--即JDK1.2之前。JDK1.2之前，用户自定义类加载器是继承ClassLoader重写loadClass()方法，因为虚拟机在进行类加载时会调用加载器的私有方法loadClassInternal()，而这个方法的唯一逻辑是调用自己的loadClass()方法。JDK1.2之后，不提倡用户再去覆盖loadClass()方法，而是把自己的类加载逻辑写到findClass()逻辑中。第二次破坏：模型自身缺陷导致。JNDI服务采用线程上下文类加载器去加载所需要的SPI代码，也就是父类加载器采用子类加载器去完成类加载的动作，java中所有涉及SPI的加载动作基本都是采用这种方式，例如JNDI、JDBC、JCE、JAXB和JBI等。第三次破坏：用户对程序动态性的追求而导致的。在OSGi环境下，类加载器不再是双亲委派中的树状结构，而是进一步发展为网状结构。

自定义ClassLoader:

packagecom.ran.test02;public classTest01{

publicTest01() {

System.out.println("This is Test01");}

}packagecom.ran.test02;importjava.io.*;public classPathClassLoaderextendsClassLoader{

privateStringclassPath;privateStringpackageName= "com.ran.classpath";publicPathClassLoader(StringclassPath){

this.classPath= classPath;}

protectedClass> findClass(Stringname) throwsClassNotFoundException{

if(name.startsWith(packageName)){

byte[] classData = getData(name);if(classData == null){

throw newClassNotFoundException();} else{

returndefineClass(name,classData,0,classData.length);}

} else{

return super.loadClass(name);}

}

private byte[] getData(StringclassName) {

Stringpath = classPath+ File.separatorChar+ className.replace('.',File.separatorChar) + ".class";try{

InputStreamis = newFileInputStream(path);ByteArrayOutputStreambaos = newByteArrayOutputStream();byte[] buffer = new byte[2048];intnum = 0;while((num = is.read(buffer)) != -1){

baos.write(buffer,0,num);}

returnbaos.toByteArray();} catch(IOExceptione){

e.printStackTrace();}

return null;}

public static voidmain(String[] args) throwsException{

Stringpath = ClassLoader.getSystemResource("").getPath().substring(1);PathClassLoaderloader = newPathClassLoader(path);System.out.println(loader.findClass("com.ran.test02.Test01").newInstance());}

}

本文参考《深入理解虚拟机》

更多相关知识，可参考http://www.hollischuang.com/archives/201

http://www.hollischuang.com/archives/199