天天看点

java破坏双亲委派_java的类加载机制-双亲委派,破坏双亲委派

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)所指定的类库;

java破坏双亲委派_java的类加载机制-双亲委派,破坏双亲委派

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

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

java破坏双亲委派_java的类加载机制-双亲委派,破坏双亲委派

加载:找到.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