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)所指定的类库;
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。
解析:将常量池中的符号引用替换为直接引用,主要针对类或接口、字段、类方法、接口方法四类的符号引用的解析。
初始化:类第一次被使用时,才会初始化;主要是执行类构造器<client>()方法,执行类变量的赋值操作和静态代码块。
初始化发生的时机:
new关键字实例化对象;
调用类的静态方法:
给类的静态域赋值;
使用反射调用时,如果类没初始化,需要先触发其初始化;
初始化一个类时,如果父类没有初始化,则需先触发其父类的初始化;
虚拟机启动时,用户指定执行的主类,虚拟机需要初始化这个主类。
破坏双亲委派:
第一次破坏:发生在双亲委派模型出现之前--即JDK1.2之前。JDK1.2之前,用户自定义类加载器是继承ClassLoader重写loadClass()方法,因为虚拟机在进行类加载时会调用加载器的私有方法loadClassInternal(),而这个方法的唯一逻辑是调用自己的loadClass()方法。JDK1.2之后,不提倡用户再去覆盖loadClass()方法,而是把自己的类加载逻辑写到findClass()逻辑中。
第二次破坏:模型自身缺陷导致。JNDI服务采用线程上下文类加载器去加载所需要的SPI代码,也就是父类加载器采用子类加载器去完成类加载的动作,java中所有涉及SPI的加载动作基本都是采用这种方式,例如JNDI、JDBC、JCE、JAXB和JBI等。
第三次破坏:用户对程序动态性的追求而导致的。在OSGi环境下,类加载器不再是双亲委派中的树状结构,而是进一步发展为网状结构。
自定义ClassLoader:
package com.ran.test02; public class Test01 { public Test01() { System.out.println("This is Test01"); } }
package com.ran.test02; import java.io.*; public class PathClassLoader extends ClassLoader{ private String classPath; private String packageName = "com.ran.classpath"; public PathClassLoader(String classPath){ this.classPath = classPath; } protected Class<?> findClass(String name) throws ClassNotFoundException{ if(name.startsWith(packageName)){ byte[] classData = getData(name); if(classData == null){ throw new ClassNotFoundException(); } else { return defineClass(name, classData, 0, classData.length); } } else { return super.loadClass(name); } } private byte[] getData(String className) { String path = classPath + File.separatorChar + className.replace('.', File.separatorChar) + ".class"; try{ InputStream is = new FileInputStream(path); ByteArrayOutputStream baos = new ByteArrayOutputStream(); byte[] buffer = new byte[2048]; int num = 0; while((num = is.read(buffer)) != -1){ baos.write(buffer, 0, num); } return baos.toByteArray(); } catch(IOException e){ e.printStackTrace(); } return null; } public static void main(String[] args) throws Exception { String path = ClassLoader.getSystemResource("").getPath().substring(1); PathClassLoader loader = new PathClassLoader(path); System.out.println(loader.findClass("com.ran.test02.Test01").newInstance()); } }
本文参考《深入理解虚拟机》
更多相关知识,可参考http://www.hollischuang.com/archives/201
http://www.hollischuang.com/archives/199