类加载器是 JVM 执行类加载机制的前提。
ClassLoader的作用:
ClassLoader是Java的核心组件,所有的Class都是由ClassLoader进行加载的,ClassLoader负责通过各种方式将Class信息的二进制数据流读入JVM内部,转换为一个与目标类对应的java.lang.Class
对象实例。然后交给Java虚拟机进行链接、初始化等操作。因此,ClassLoader在整个装载阶段,只能影响到类的加载,而无法通过ClassLoader区改变类的链接和初始化行为。至于它是否可以运行,则由 Execution Engine
决定。
类加载器最早出现在Java1.0版本中,那个时候只是单纯地为了满足Java Applet应用而被研发出来。但如今类加载器却在OSGi、字节码加解密领域大放异彩。这主要归功于Java虚拟机的设计者们当初在设计类加载器时,并没有考虑将它绑定在JVM内部,这样做的好处就是能够更加灵活和动态地执行类加载。
类加载的分类:显式加载 vs 隐式加载
class文件的显式加载与隐式加载是指JVM加载class文件到内存的方式。
在日常开发,以上两种方法一般会混合使用。
一般情况下,Java开发人员并不需要在程序中显式地使用类加载器,但是了解类加载器的加载机制却显得至关重要。从以下几个方面说:
java.lang.ClassNotFoundException
或 java.lang.NoClassDefFoundError
异常时无法判断。只有了解类加载器的加载机制才能够在出现异常时快速根据错误异常日志定位问题、解决问题。对于任意一个类,都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一性。每一个类加载器,都拥有一个独立的类名称空间:比较两个类是否相等,只有在这两个类是由同一个类加载器加载的前提下才有意义。否则,即使这两个类源自同一个Class文件,被同一个虚拟机加载,只要它们的类加载器不同,那这两个类必定不相等。
在大型应用中,我们往往借助这一特性,来运行同一个类的不同版本。
通常类加载机制由三个基本特征:
JVM支持两种类型的类加载器:引导类加载器(Bootstrap ClassLoader)和 自定义类加载器(User-Defined ClassLoader)
从概念上类来讲,自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器,但是Java虚拟机规范却没有这么定义,而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。无论类加载器的类型如何划分,在程序中我们最常见的类加载器结构主要是如下情况:
启动类加载器/引导类加载器(Bootstrap ClassLoader)
JAVA_HOME/jre/lib/rt.jar
或sun.boot.class.path
路径下的内容)。用于提供JVM自身需要的类。java.lang.ClassLoader
,没有父加载器。java
、javax
、sun
等开头的类。可以使用-xx:+TraceClassLoader
参数查看类加载具体流程。
扩展类加载器(Extension ClassLoader)
sun.misc.Launcher$ExtClassLoader
实现。java.ext.dirs
系统属性所指定的目录中加载类库,或从JDK的安装目录的jre/lib/ext
子目录下加载类库。如果用户创建的JAR放在此目录下,也会自动由扩展类加载器加载。系统类加载器 / 应用程序类加载器(Application ClassLoader)
sun.misc.Launcher$AppClassLoader
实现。java.class.path
指定路径下的类库用户自定义类加载器
每个Class对象都会包含一个定义它的ClassLoader的一个引用。
获取ClassLoader的途径
获得当前类的ClassLoader:
Clazz.getClassLoader();
获得当前线程上下文的ClassLoader:
Thread.currentThead().getContextClassLoader();
获得系统的ClassLoader:
ClassLoader.getSystemClassLoader();
说明:
站在程序员的角度看,引导类加载器与另外两种加载器(系统类加载器+扩展类加载器)并不是同一个层次意义上的加载器,引导类加载器由C++语言编写,而另外两种类加载器由Java语言编写。由于引导类加载器并非Java类,因此在Java程序中只能打印出null值。
数组类的Class对象,不是由类加载器去创建的,而是在Java运行期JVM根据需要自动创建的。对于数组类的类加载器来说,是通过Class.getClassLoader()
返回的,与数组当中元素类型的类加载器是一样的;如果数组当中的元素类型是基本数据类型(虚拟机预先定义, 无需类加载),数组类没有类加载器。
数组类 - 举例:
/**
* 不同类加载器-测试
*/
public class ClassLoaderTest {
public static void main(String[] args) {
ClassLoader classLoader1 = (new String[10]).getClass().getClassLoader(); //String : Bootstrap
System.out.println(classLoader1);
ClassLoader classLoader2 = (new int[10]).getClass().getClassLoader(); //int : 基本数据类型
System.out.println(classLoader2);
ClassLoader classLoader3 = (new Application[10]).getClass().getClassLoader(); //JavaFX (JDK 1.8) : Application类(Extension)
System.out.println(classLoader3);
ClassLoader classLoader5 = (new User[10]).getClass().getClassLoader(); //自定义类 : User类(Application)
System.out.println(classLoader5);
}
}
/**
* 用户自定义类
*/
class User {
private int id;
}
测试结果:
ClassLoader与现有类加载器的关系:
除了以上虚拟机自带的加载器外,用户还可以定制自己的类加载器。Java提供了抽象类java.lang.ClassLoader
,所有用户自定义的类加载器都应该继承ClassLoader
类。
ClassLoader的主要方法(内部没有抽象方法)
返回此类加载器的超类加载器。
public final ClassLoader getParent()
加载名称为name的类,返回结果为java.lang.Class
类的实例。如果找不到类,则返回ClassNotFoundException
异常。该方法中的逻辑就是双亲委派模式的实现。
public Class<?> loadClass(String name) throws ClassNotFoundException
核心方法解析:
/**
* 测试代码:ClassLoader.getSystemClassLoader().loadClass("com.ljw.demo.User");
*/
protected Class<?> loadClass(String name, boolean resolve) //resolve:true-加载Class同时进行解析操作
throws ClassNotFoundException {
synchronized (getClassLoadingLock(name)) { //同步操作,保证只能加载一次
// 首先,在缓存中判断是否已经加载同名的类 (First, check if the class has already been loaded)
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
// 获取当前类加载的父加载器
if (parent != null) {
// 如果存在父加载器,则调用父加载器进行类加载
c = parent.loadClass(name, false);
} else { //parent为null: 父类加载器是引导类加载器
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) { // 当前类的加载器的父加载器未加载此类 or 当前类的加载器未加载此类
// 调用当前ClassLoader的findClass()方法
long t1 = System.nanoTime();
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) { // 是否进行解析操作
resolveClass(c);
}
return c; // 返回Class实例
}
}
查找二进制名称为name的类,返回结果为java.lang.Class
类的实例。这是一个受保护的方法,JVM鼓励我们重写此方法,需要自定义类加载器遵循双亲委托机制。该方法会在检查完父加载器后被 loadClass() 方法调用。
在JDK1.2之前,在自定义类加载时,总会继承ClassLoader类并重写loadClass方法,从而实现自定义的类加载器。但是在JDK1.2之后已不再建议用户覆盖loadClass() 方法,而是建议把自定义的类加载逻辑写在findClass()方法中,从前面的分析可知,findClass()方法是在loadClass() 方法中被调用的,当loadClass() 方法中父加载器加载失败后,则会调用自己的findClass来完成类加载,这样就可以保证自定义类加载器也符合双亲委托模型。
需要注意的是ClassLoader类中并没有实现findClass()方法的具体逻辑,取而代之的是抛出
ClassNotFoundException
异常,同时需注意findClass方法通常与defineClass方法一起使用。一般情况下,在自定义类加载器时,会直接覆盖ClassLoader的findClass() 方法并编写加载规则,取得要加载类的字节码后转换成流,然后调用defineClass() 方法生成类的Class对象。URLClassLoader类中有ExtClassLoader、AppClassLoader此方法的具体实现。
protected Class<?> findClass(String name) throws ClassNotFoundException {
throw new ClassNotFoundException(name);
}
根据给定的字节数组b转化为Class的实例,off和len参数表示实际Class信息在byte数组中的位置和长度,其中byte数组b是ClassLoader从外部获取的,这是受保护的方法,只有在自定义ClassLoader子类中可以使用。
defineClass()方法是用来将byte字节流解析成JVM能够识别的Class对象(ClassLoader中已实现该方法逻辑),这个方法不仅能够通过class文件实例化对象,也可以通过其他方式实例化class对象,如通过网络接收一个类的字节码,然后转换为byte字节流创建对应的Class对象。
defineClass()方法通常与findClass()方法一起使用,一般情况下,在自定义类加载器时,会直接覆盖ClassLoader的findClass()方法并编写加载规则,取得要加载类的字节码后转换成流,然后调用defineClass()方法生成类的Class对象。
protected final Class<?> defineClass(String name, byte[] b, int off, int len)
举例:
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
// 获取类的class文件字节数组
byte[] classData = getClassData(name);
if (classData == null) {
throw new ClassNotFoundException();
} else {
// 直接生成Class对象
return defineClass(name, classData, 0, classData.length);
}
}
链接指定的一个Java类。使用该方法可以使用类的Class对象创建完成的同时也被解析。前面我们说连接阶段主要是对字节码进行验证,为类变量分配内存并设置初始值同时将字节码文件的符号引用转化为直接引用。
protected final void resolveClass(Class<?> c)
查找名称为name的已经被加载过的类,返回结果为java.lang.Class
类的实例。这个方法被final修饰,无法被修改。
protected final Class<?> findLoadedClass(String name)
它也是ClassLoader的实例,这个字段表示的ClassLoader也成为这个ClassLoader的双亲。在类加载的过程中,ClassLoader可能会将某些请求交予自己的双亲处理。
private final ClassLoader parent;
SecureClassLoader扩展了ClassLoader,新增了几个与 使用相关的代码 (对代码源的位置及其证书的验证) 和 权限定义类验证 (主要指对class源码的访问权限) 的方法,一般我们不会直接与这个类打交道,更多是与它的子类URLClassLoader有所关联。
前面提到,ClassLoader是一个抽象类,很多方法是空的没有实现(比如 findClass()、findResource() 等)。而URLClassLoader这个实现类为这些方法提供了具体的实现。并新增了URLClassPath类协助取得Class字节码流等功能。在编写自定义类加载器时,如果没有太过于复杂的需求,可以直接继承URLClassLoader类,这样就可以避免自己编写findClass()方法及其获取字节码流的方式,使自定义类加载器编写更加简洁。
扩展类加载器ExtClassLoader 和 系统类加载器AppClassLoader,这两个类都继承自URLClassLoader,并作为sun.misc.Launcher
的静态内部类。
sun.misc.Launcher
主要被系统用于启动主应用程序,而ExtClassLoader和AppClassLoader都是由sun.misc.Launcher
创建的。
ExtClassLoader没有重写loadClass()方法,说明其遵循双亲委派模型。而AppClassLoader重载了loadClass()方法,但最终调用的还是父类loadClass()方法,因此依然遵循双亲委派模型。
Class.forName()
:一个静态方法,最常用的是Class.forName(String className)
;根据传入的类的全限定名返回一个Class对象。该方法在将Class文件加载到内存的同时,会执行类的初始化。(如:Class.forName(“com.ljw.demo.Demo”);)ClassLoader.loadClass()
:一个实例方法,需要一个ClassLoader对象来调用该方法。该方法将Class文件加载到内存时,并不会执行类的初始化,直到这个类第一次使用时才进行初始化。该方法因为需要得到一个ClassLoader对象,所以可以根据需要指定使用哪个类加载器。(如:ClassLoader cl = …; cl.loadClass(“com.ljw.demo.Demo”); )类加载器用于将类加载到Java虚拟机中。从JDK1.2版本开始,类的加载过程采用双亲委派机制,这种机制能更好地保证Java平台的安全。
如果一个类加载器在接到加载类的请求时,它首先不会自己尝试去加载这个类,而是把这个请求任务委托给父加载器去完成,依次递归,如果父加载器可以完成类加载任务,就成功返回。只有父类加载器无法完成此加载任务时,才自己去加载。
规定了类加载的顺序:引导类加载器先加载,若加载不到,则由扩展类加载器加载,若还加载不到,才会由系统类加载器/自定义类加载器进行加载。
避免类的重复加载,确保一个类的全局唯一性
Java类随着它的类加载器一起具备了一种带有优先级的层次关系,通过这种层次关系可以避免类的重复加载,当父加载器已经加载了该类时,就没有必要子加载器再加载一次。
保护程序安全,防止核心API被随意篡改。
双亲委派机制在java.lang.ClassLoader.loadClass(String, boolean)
接口中体现。该接口的逻辑如下:
parent.loadClass(name, false)
接口进行加载。java.lang.ClassLoader
接口的defineClass系列的native接口加载目标Java类。双亲委派模型就隐藏在第2、3步中。
假设当前加载的是java.lang.Obejct
类,显然,此类属于JDK中的核心类,因此只能由Bootstrap引导类加载器进行加载。当JVM准备加载java.lang.Obejct
时,JVM会默认使用系统类加载器加载,按照上面4步加载逻辑,在第1步从系统类的 缓存中肯定查找不到此类,于是进入第2步。由于从系统类加载器的父加载器时扩展类加载器,于是扩展类加载器继续从第1步开始重复。由于扩展类加载器的缓存中也查找不到此类,因此进入第2步,扩展类的父加载器是null,因此系统调用findClass(String),最终通过引导类加载器进行加载。
如果在自定义的类加载器中重写java.lang.ClassLoader.loadClass(String)
或 java.lang.ClassLoader.loadClass(String, boolean)
方法,抹去其中的双亲委派机制,仅保留上面4步中的第1、4步,那么是不是就能够加载核心类库了呢?
不行!因为JDK还为核心类库提供了一层保护机制。无论是自定义的类加载器,还是系统类/扩展类加载器,最终都必须调用java.lang.ClassLoader.defineClass(String, byte[], int, int, ProtectionDomain)
方法,而该方法会执行 preDefineClass()接口,该接口中提供了对JDK核心类库的保护。
检查类是否加载的委托过程是单向的,这个方式虽然从结构上说比较清晰,使各个ClassLoader的职责非常明确,但是同时会带来一个问题,即顶层的ClassLoader无法访问底层ClassLoader所加载的类。
通常情况下,启动类加载器的类为系统核心类,包括一些重要的系统接口,而在应用类加载器中,为应用类。按照这种模式,应用类访问系统类自然是没有问题,但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口,该接口需要在应用类中得以实现,该接口还绑定了一个工厂方法,用于创建该接口的实例,而接口和工厂方法都在启动类加载器中。这时,就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。
由于Java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型,只是建议采用这种方式而已。
比如在Tomcat中,类加载器所采用的加载机制就和传统的双亲委派模型有一定的区别,当缺省的类加载器接收到一个类的加载任务时,首先会由它自行加载,当它加载失败时,才会将类的加载任务委派给它的超类加载器去执行,这同时也是Servlet规范推荐的一种做法。
双亲委派模型并不是一个具有强制性约束的模型,而是Java设计者推荐给开发者们的类加载器实现方式。
在Java的世界中大部分的类加载器都遵循这个模型,但也有例外的情况,直到Java模块化出现为止,双亲委派模型主要出现过3次较大规模 “被破坏” 的情况。
双亲委派模型的第一次 “被破坏” 其实发生在双亲委派模型出现之前——即 JDK 1.2 问世以前的 “远古” 时代。
由于双亲委派模型在 JDK 1.2 之后才被引入,但是类加载器的概念和抽象类java.lang.ClassLoader
则在Java的第一个版本中就已经存在,面对已经存在的用户自定义类加载器的代码,Java设计者们引入双亲委派模型时不得不做出一些妥协,为了兼容这些已有代码,无法再以技术手段避免loadClass()被子类覆盖的可能性,只能在JDK1.2之后的java.lang.ClassLoader
中添加一个新的protected方法findClass(),并引导用户编写的类加载逻辑时尽可能去重写这个方法,而不是在loadClass()中编写代码。上节我们已经分析过loadClass()方法,双亲委派的具体逻辑就实现在这里面,按照loadClass()方法的逻辑,如果父类加载失败,会自动调用自己的findClass()方法来完成加载,这样既不影响用户按照自己的意愿去加载类,又可以保证新写出来的类加载器是符合双亲委派机制的。
第二次破坏双亲委派机制:线程上下文类加载器
双亲委派模型的第二次 “被破坏” 是由这个模型自身的缺陷导致的,双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题(越基础的类由越上层的加载器进行加载),基础类型之所以被称为 “基础”,是因为他么按总是作为被用户代码继承、调用的API存在,但程序设计往往没有绝对不变的完美规则,如果有基础类型又要调用回用户的代码,那该怎么办呢?
这并非是不可能出现的事情,一个典型的例子便是JNDI服务,JNDI现在已经是Java的标准服务,它的代码由启动类加载器来完成加载(在JDK 1.3时加入到rt.jar
),肯定属于Java中很基础的类型,但JNDI存在的目的就是对资源进行查找和集中管理,它需要调用由其他厂商实现并部署在应用程序的ClassPath下的 JNDI服务提供者接口(Service Provider Interface, SPI)的代码。现在问题来了,启动类加载器是绝不可能认识、加载这些代码的,那么该怎么办?(SPI:在Java平台中,通常把核心类 rt.jar
中提供外部服务、可由应用层自行实现的接口称为SPI)
为了解决这个困境,Java的设计图案退只好引入了一个不太优雅的设计:线程上下文类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread
类的setContextClassLoader()方法进行设置,如果创建线程时还未设置,它将会从父线程中继承一个,如果在应用程序的全局范围都没有设置,那这个类加载器默认就是应用程序类加载器。
有了线程上下文类加载器,程序就可以做一些 “舞弊” 行为。JNDI服务使用这个线程上下文类加载器去加载所需的SPI服务代码,这是一种父加载器去请求子加载器完成类加载的过程,这种行为实际上打通了双亲委派模型的层次结构来逆向使用类加载器,已经违背了双亲委派模型的一般性原则。但是,Java中涉及SPI的加载基本都采用这种方式来完成,例如 JNDI、JDBC、JCE、JAXB、JBI等。不过,当SPI的服务提供者多于一个的时候,代码就只能根据具体提供者的类型来硬编码判断,为了消除这种极不优雅的实现方式,在JDK 6时,JDK提供了java.util.ServiceLoader
类,以META-INF/Services
中的配置信息,辅以 责任链模式(职责链模式),这才算是一种相对合理的解决方案。
默认上下文加载器就是应用类加载器,这样以上下文加载器为中介,使得启动类加载器中的代码也可以访问应用类加载器中的类。
双亲委派模型的第三次 “被破坏” 是由于用户对程序动态性的追求而导致的。如:代码热替换(Hot Swap)、**模块热部署(Hot Deployment)**等。
IBM公司主导的 JSR-291(即OSGi R4.2)实现模块化热部署的关键是它自定义的类加载器机制的实现,每一个程序模块(OSGi中称为Bundle)都有一个自己的类加载器,当需要更换一个Bundle时,就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGi环境下,类加载器不再双亲委派模型推荐的树状结构,而是进一步发展为更为复杂的网状结构。
当收到类加载请求时,OSGi将按照下面的顺序进行类搜索:
java.*
开头的类,委派给父加载器加载。说明:仅有开头两点仍然符合双亲委派模型的原则,其余的类查找都是在平级的类加载器中进行的。
小结:
这里,我们用 “被破坏” 这个词来形容上述不符合双亲委派模型原则的行为,但 这里 “被破坏” 并不一定是带有贬义的。只要有明确的目的和充分的理由,突破旧有原则无疑是一种创新。
热替换是指在程序运行过程中,不停止服务,只通过替换程序文件来修改程序的行为。热替换的关键需求在于服务不能中断,修改必须立即表现正在运行的系统之中。基本上大部分脚本语言都是天生支持热替换的。(如:PHP, 替换源文件改动立即生效, 无需重启Web服务器)
但对Java来说,热替换并非天生就支持,如果一个类已经加载到系统中,通过修改类文件,并无法让系统再来加载并重定义这个类。因此,在Java中实现这一功能的一个可行的方法就是灵活运用ClassLoader。
注意:由不同ClassLoader加载的同名类属于不同类型,不能相互转换和兼容。即两个不同的ClassLoader加载同一个类,在虚拟机内部,会认为这2个类是完全不同的。
根据这个特点,可以用来模拟热替换的实现,基本思路如下:
代码举例:
热替换测试类:
public class Demo1 {
public void hot() {
System.out.println("OldDemo");
//System.out.println("OldDemo ---> NewDemo");
}
}
自定义类加载器:
/**
* 热部署用-自定义类加载器
*/
public class MyClassLoader extends ClassLoader {
private String rootDir;
public MyClassLoader(String rootDir) {
this.rootDir = rootDir;
}
@Override
protected Class<?> findClass(String className) throws ClassNotFoundException {
Class clazz = this.findLoadedClass(className);
FileChannel fileChannel = null;
WritableByteChannel outChannel = null;
if (null == clazz) {
try {
String classFile = getClassFile(className);
FileInputStream fis = new FileInputStream(classFile);
fileChannel = fis.getChannel();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
outChannel = Channels.newChannel(baos);
ByteBuffer buffer = ByteBuffer.allocateDirect(1024);
while (true) {
int i = fileChannel.read(buffer);
if(i == 0 || i == -1) {
break;
}
buffer.flip();
outChannel.write(buffer);
buffer.clear();
}
byte[] bytes = baos.toByteArray();
clazz = defineClass(className, bytes, 0, bytes.length);
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
if (fileChannel != null) {
fileChannel.close();
}
} catch (IOException e) {
e.printStackTrace();
}
try {
if (outChannel != null) {
outChannel.close();
}
} catch (IOException e) {
e.printStackTrace();
}
}
}
return clazz;
}
/**
* 类文件的完全路径
*/
public String getClassFile(String className) {
return rootDir + "\\" + className.replace('.', '\\') + ".class";
}
}
测试类:
public class LoopRun {
public static void main(String[] args) {
while (true) {
try {
// 1. 创建自定义类加载器实例
MyClassLoader loader = new MyClassLoader("D:\\Workplace-Myabtis\\jvm-demo-02\\src\\main\\java");
// 2. 加载指定的类
Class clazz = loader.findClass("com.ljw.demo09.Demo1");
// 3. 创建运行时类的实例
Object demo = clazz.newInstance();
// 4. 获取运行时类中指定的方法
Method m = clazz.getMethod("hot");
// 5. 调用指定的方法
m.invoke(demo);
Thread.sleep(5000);
} catch (Exception e) {
System.out.println("not find");
try {
Thread.sleep(5000);
} catch (InterruptedException ex) {
ex.printStackTrace();
}
}
}
}
}
分别在更改代码前后使用两次javac,实现代码热替换:
沙箱安全机制
Java安全模型的核心就是Java沙箱 (sandbox)。沙箱即一个限制程序运行的环境。
沙箱机制就是将Java代码 限定在虚拟机(JVM)特定的运行范围中,并且严格限制代码对本地系统资源的访问。通过这样的措施来保证对代码的有限隔离,防止对本地系统造成破坏。
沙箱主要限制系统资源访问,那系统资源包括什么?CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。
所有的Java程序都可以指定沙箱,可以定制安全策略。
在Java中将执行程序分为本地代码和远程代码两种,本地代码默认视为可信任的,而远程代码则被看作是不受信的。对于授信的本地代码,可以访问一切本地资源。而对于非授信的远程代码在早期的Java实现中,安全依赖于沙箱(Sandbox)机制。
JDK1.0中如此严格的安全机制也给程序的功能扩展带来了障碍,比如当用户希望远程代码访问本地系统的文件时,就无法实现。
因此在后续的Java1.1版本中,针对安全机制做了改进,增加了 安全策略。允许用户指定本地代码对本地资源的访问权限。
在JDK1.2版本中,再次改进了安全机制,增加了 代码签名。不论本地代码或是远程代码,都会按照用户的安全策略设定,由类加载器加载到虚拟机中权限不同的运行空间,来实现差异化的代码执行权限控制。
当前最新的安全机制,则引入了 **域(Domain)**的概念。
虚拟机会把所有代码加载到不同的系统域和应用域。系统域部分专门负责与关键资源进行交互,而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机中不同的受保护域(Protected Domain),对应不一样的权限(Permission)。存在于不同于中的类文件就具有了当前域的全部权限,下面是最新的安全模型(JDK 1.6)
隔离加载类
在某些框架内进行中间件与应用的模块隔离,把类加载到不同的环境。
修改类加载的方式
类的加载模型并非强制,除Bootstrap外,其他的加载并非一定要引入,或者根据实际情况在某个时间点按需进行动态加载。
扩展加载源
比如从数据库、网络、电视机机顶盒进行加载
防止源码泄漏
Java代码容易被编译和篡改,可以进行编译加密,那么类加载也需要自定义,还原加密的字节码。
在一般情况下,使用不同的类加载器去加载不同的功能模块,会提高应用程序的安全性。
但是,如果涉及Java类型转换,则加载器反而容易产生不美好的事情。在做Java类型转换时,只有两个类型都是由同一个加载器所加载,才能进行类型转换,否则转换时会发生异常。
用户通过定制自己的类加载器,这样可以重新定义类的加载规则,以便实现一些自定义的处理逻辑。
java.lang.ClassLoader
,所有用户自定义的类加载器都应该继承ClassLoader类。这两种方法本质上差不多,毕竟loadClass()也会调用findClass(),但是从逻辑上讲我们最好不要直接修改loadClass()的内部逻辑。建议的做法是只在findClass()里重写自定义类的加载方法,根据参数指定类的名字,返回对应的Class对象的引用。
java.lang.ClassLoader.loadClass(String)
接口 (自定义类加载器并重写java.lang.ClassLoader.loadClass(String)
接口的除外),连JDK的核心类库也不能例外。自定义类加载器:
/**
* 自定义:ClassLoader类加载器
*/
public class MyClassLoader extends ClassLoader {
private String byteCodePath;
public MyClassLoader(String byteCodePath) {
this.byteCodePath = byteCodePath;
}
public MyClassLoader(ClassLoader parent, String byteCodePath) {
super(parent);
this.byteCodePath = byteCodePath;
}
@Override
protected Class<?> findClass(String className) throws ClassNotFoundException {
BufferedInputStream bis = null;
ByteArrayOutputStream baos = null;
try {
// 获取字节码文件的完整路径
String fileName = byteCodePath + className + ".class";
// 获取一个输入流
bis = new BufferedInputStream(new FileInputStream(fileName));
// 获取一个输出流
baos = new ByteArrayOutputStream();
// 具体读入并写出的过程
int len;
byte[] data = new byte[1024];
while ((len = bis.read(data)) != -1) {
baos.write(data, 0, len);
}
// 获取内存中完整的字节数组的数据
byte[] byteCodes = baos.toByteArray();
// 调用defineClass(),将字节数组的数据转换为Class的实例
Class<?> clazz = defineClass(null, byteCodes, 0, byteCodes.length);
return clazz;
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
if (baos != null)
baos.close();
} catch (IOException e) {
e.printStackTrace();
}
try {
if (bis != null)
bis.close();
} catch (IOException e) {
e.printStackTrace();
}
}
return null;
}
}
测试类:
public class MyClassLoaderTest {
public static void main(String[] args) {
// 拷贝字节码class文件至D盘
MyClassLoader classLoader = new MyClassLoader("D:/");
try {
Class<?> clazz = classLoader.loadClass("Demo1");
System.out.println("加载此类的类加载器为:" + clazz.getClassLoader().getClass().getName());
System.out.println("加载当前Demo1的类加载器的父加载器为:" + clazz.getClassLoader().getParent().getClass().getName());
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}
测试结果:
为了保证兼容性,JDK 9没有从根本上改变三层类加载器架构和双亲委派模型,但为了模块化系统的顺利运行,仍然发生了一些值得被注意的变动。
扩展机制被移除,扩展类加载器由于向后兼容性的原因被保留,不过被重命名为平台类加载器(platform class loader)。可以通过ClassLoader的新方法getPlatformClassLoader()来获取。
rt.jar
和 tools.jar
被拆分成数十个 JMOD 文件),其中的Java类库就已经天然地满足了可扩展的需求,那自然无需再保留 \lib\ext
目录,此前使用这个目录或java.ext.dirs
系统变量来扩展JDK功能的机制已经没有继续存在的价值了。平台类加载器和应用程序类加载器都不再继承自 java.net.URLClassLoader
。
jdk.internal.loader.BuiltinClassLoader
。sun.misc.Launcher
类,并在jdk.internal.loader.ClassLoaders
中创建新的内部类用以表示三种加载器(但是仍无法打印引导类加载器, 为null值)如果有程序直接依赖了这种继承关系,或者依赖了 URLClassLoader 类的特定方法,那代码很可能会在 JDK 9 及更高版本的 JDK 中崩溃。
在 Java 9中,类加载器有了名称。该名称在构造方法中指定,可以通过getName()
方法来获取。平台类加载器的名称时platform,应用类加载器的名称是app。类加载器的名称在调试与类加载器相关问题时会非常有用。
启动类加载器现在是在JVM内部和Java类库共同协作实现的类加载器(以前是C++实现),但为了与之前的代码兼容,在获取启动类加载器的场景中仍然会返回null,而不会得到BootClassLoader实例。
类加载器的委派关系也发生了变动。
双亲委派模式变更示意图
在 Java模块化 系统明确规定了三个类加载器负责各自加载的模块,如有需要可以查看官方文档,这里不进行详细叙述。