CN112631685A - 一种类加载方法及装置 - Google Patents

Abstract

本申请实施例公开了一种类加载方法及装置，方法包括：获取应用模块的类加载请求，类加载请求携带有应用模块的属性配置信息和类加载配置信息；根据类加载配置信息从多个类加载器中确定目标类加载器，多个类加载器包括非自定义类加载器和多个自定义类加载器，每一个自定义类加载器至少有2个自定义加载器作为父类加载器；控制目标类加载器根据属性配置信息对类加载请求进行处理；将类加载请求的处理结果返回应用模块。由此可见，本申请实施例的类加载方法，突破了双亲委派的加载机制的限制，能够根据应用模块的需求对类加载请求进行处理，能够满足多模块对于类加载请求的动态化需求。

Description

一种类加载方法及装置

技术领域

本申请涉及计算机领域，尤其涉及一种类加载方法及装置。

背景技术

随着一个应用系统的功能不断丰富，需要将具有多种功能的应用系统进行模块化的拆分，即每个模块对应应用系统中的一个功能，每个模块都是一个独立的业务功能。例如，若银行应用系统中可以提供存钱和取钱两种功能，则可以将系统拆分为两个模块，一个模块只负责存钱的功能，另一个模块只负责取钱的功能，两者虽然是一个应用系统，但是不互相干扰。在拆分为模块之后，每个模块都需要向类加载器发送类加载请求，类加载器将类文件加载为二进制的数据读入内存中，并将其放在运行时数据区域的方法区内，然后在数据区域中创建一个对象，用来封装类在方法区内的数据结构。现有的类加载机制是双亲委派的加载机制，如图1所示，有三种非自定义类加载器，分别是启动类加载器(BootstrapClassLoader)、扩展类加载器(Extension ClassLoader)和应用程序类加载器(Application ClassLoader)，当一个类加载器收到一个类加载请求时，它首先不会自己去尝试加载这个类，而是把请求委托给父类加载器去完成，依次向上，因此所有的类加载请求最终都会被传递到顶层的启动类加载器，只有在父类加载器无法加载时子类加载器才尝试从自己的类路径中加载。

虽然双亲委派的加载机制能够保证类加载的唯一性，但是对于多模块的类加载请求，存在一个模块的类优先由自定义类加载器进行加载的需求，或一个模块的类只由自定义类加载器进行加载的需求等，而现有的双亲委派的加载机制无法满足这些需求。

综上，现有的双亲委派的加载机制，不能满足多模块对于类加载请求的动态化需求。

发明内容

为了解决现有技术双亲委派的加载机制不能满足多模块对于类加载请求的动态化需求的问题，本申请提供了一种类加载方法及装置，能够满足多模块对于类加载请求的动态化需求。

本申请实施例提供了一种类加载方法，所述方法包括：

获取应用模块的类加载请求，所述类加载请求携带有所述应用模块的属性配置信息和类加载配置信息；

根据所述类加载配置信息从多个类加载器中确定目标类加载器，所述多个类加载器包括非自定义类加载器和多个自定义类加载器，每一个自定义类加载器至少有2个自定义加载器作为父类加载器；

控制所述目标类加载器根据所述属性配置信息对所述类加载请求进行处理；

将所述类加载请求的处理结果返回所述应用模块。

可选的，所述类加载配置信息包括所述应用模块的标识；

所述根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

将所述多个类加载器中与所述应用模块的标识对应的类加载器确定为目标类加载器。

可选的，所述多个自定义类加载器包括所述目标类加载器的至少两个父类自定义加载器；

所述控制所述目标类加载器根据所述属性配置信息对所述类加载请求进行处理包括：

控制所述至少两个父类自定义加载器对所述类加载请求进行处理，得到第一处理结果；

控制所述目标类加载器根据所述属性配置信息和所述第一处理结果对所述类加载请求进行处理，得到第二处理结果；

将所述类加载请求的处理结果返回所述应用模块包括：

将所述类加载请求的第二处理结果返回所述应用模块。

可选的，所述类加载配置信息包括：反向类加载指示信息和所述应用模块的标识；

所述根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

从所述多个类加载器中确定与所述应用模块的标识对应的第一类加载器；

根据反向类加载指示信息判断所述第一类加载器是否能够处理所述类加载请求；

若是，则将所述第一类加载器确定为所述目标类加载器；

若否，则将所述第一类加载器的父类加载器作为所述目标类加载器。

可选的，所述类加载配置信息包括：隐藏类加载指示信息；

所述根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

从所述多个类加载器中确定与所述应用模块的标识对应的第一类加载器；

根据隐藏类加载指示信息判断所述第一类加载器是否能够处理所述类加载请求；

若是，则将所述第一类加载器确定为所述目标类加载器；

若否，则向所述应用模块返回处理失败的处理结果。

本申请实施例还提供了一种类加载装置，所述装置包括：

获取单元，用于获取应用模块的类加载请求，所述类加载请求携带有所述应用模块的属性配置信息和类加载配置信息；

确定单元，用于根据所述类加载配置信息从多个类加载器中确定目标类加载器，所述多个类加载器包括非自定义类加载器和多个自定义类加载器，每一个自定义类加载器至少有2个自定义加载器作为父类加载器；

控制单元，用于控制所述目标类加载器根据所述属性配置信息对所述类加载请求进行处理；

返回单元，用于将所述类加载请求的处理结果返回所述应用模块。

可选的，所述类加载配置信息包括所述应用模块的标识；

所述确定单元根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

所述确定单元将所述多个类加载器中与所述应用模块的标识对应的类加载器确定为目标类加载器。

可选的，所述多个自定义类加载器包括所述目标类加载器的至少两个父类自定义加载器；

所述控制单元控制所述目标类加载器根据所述属性配置信息对所述类加载请求进行处理包括：

所述控制单元控制所述至少两个父类自定义加载器对所述类加载请求进行处理，得到第一处理结果；

所述控制单元控制所述目标类加载器根据所述属性配置信息和所述第一处理结果对所述类加载请求进行处理，得到第二处理结果；

所述返回单元将所述类加载请求的处理结果返回所述应用模块包括：

所述返回单元将所述类加载请求的第二处理结果返回所述应用模块。

可选的，所述类加载配置信息包括：反向类加载指示信息和所述应用模块的标识；

所述确定单元根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

所述确定单元从所述多个类加载器中确定与所述应用模块的标识对应的第一类加载器；

所述确定单元根据反向类加载指示信息判断所述第一类加载器是否能够处理所述类加载请求；

若是，则所述确定单元将所述第一类加载器确定为所述目标类加载器；

若否，则所述确定单元将所述第一类加载器的父类加载器作为所述目标类加载器。

可选的，所述类加载配置信息包括：隐藏类加载指示信息；

所述确定单元根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

所述确定单元从所述多个类加载器中确定与所述应用模块的标识对应的第一类加载器；

所述确定单元根据隐藏类加载指示信息判断所述第一类加载器是否能够处理所述类加载请求；

若是，则所述确定单元将所述第一类加载器确定为所述目标类加载器；

若否，则所述确定单元向所述应用模块返回处理失败的处理结果。

本申请实施例提供了一种类加载方法，方法包括：获取应用模块的类加载请求，所述类加载请求携带有所述应用模块的属性配置信息和类加载配置信息；根据所述类加载配置信息从多个类加载器中确定目标类加载器，所述多个类加载器包括非自定义类加载器和多个自定义类加载器，每一个自定义类加载器至少有2个自定义加载器作为父类加载器；控制所述目标类加载器根据所述属性配置信息对所述类加载请求进行处理；将所述类加载请求的处理结果返回所述应用模块。由此可见，本申请实施例通过利用类加载请求中携带的类加载配置信息从多个类加载器中确定目标类加载器，目标类加载器根据属性配置信息对应用模块的类加载请求进行处理，并将处理结果返回应用模块，基于此，本申请实施例的类加载方法，突破了双亲委派的加载机制的限制，能够根据应用模块的需求对类加载请求进行处理，能够满足多模块对于类加载请求的动态化需求。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1为本申请提供的一种双亲委派的加载机制的示意图；

图2为本申请提供的一种类加载方法实施例的流程图；

图3为本申请提供的一种可插拔装置的示意图；

图4为本申请提供的一种多亲委派的加载机制的示意图；

图5为本申请提供的一种类加载方法的实施场景图；

图6为本申请提供的一种模块间隔离的示意图；

图7为本申请提供的一种模块的卸载顺序示意图；

图8为本申请提供的一种模块间通讯的示意图；

图9为本申请提供的一种类加载装置的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

如背景技术所述，双亲委派的加载机制中，启动类加载器(BootstrapClassLoader)：负责加载JAVA_HOME\lib目录中的，或通过-Xbootclasspath参数指定路径中的，且被虚拟机认可(按文件名识别，如rt.jar)的类。扩展类加载器(ExtensionClassLoader)：负责加载JAVA_HOME\lib\ext目录中的，或通过java.ext.dirs系统变量指定路径中的类库。应用程序类加载器(Application ClassLoader)：负责加载用户路径(classpath)上的类库。采用双亲委派的加载机制的一个好处是：java类随着它的类加载器一起具备了一种带有优先级的层次关系。比如加载位于rt.jar包中的类java.lang.Object，不管是哪个类加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了最终得到的都是同样一个Object对象。但是双亲委派的加载机制无法解决如下问题：(1)存在一个模块的类优先由自定义类加载器进行加载的需求；(2)一个模块的类只由自定义类加载器进行加载的需求；(3)一个模块依赖多个模块，双亲委派的加载机制由于只有一条向上查询加载路径，无法遍历多个父类加载器询问是否能够加载；(4)不同模块对不同版本的依赖包可能不兼容，如果仅有一个类加载器就会冲突，类在依赖包中，例如一个模块需要加载A-1.0.jar版本的依赖包，而另一个模块则必须要加载A-2.0.jar版本的依赖包，而两个jar包并不兼容，只有一个类加载器，类加载器无法识别依赖包的版本差别，因此只会加载先发送类加载请求中的一个版本的依赖包，另一个版本的依赖包就被默认为已经加载；(5)由于模块之间的独立性，如果子模块与父模块有相同的类，无法指定子模块对应的类加载器优先加载。

基于此，本申请实施例提供了一种类加载方法，通过利用类加载请求中携带的类加载配置信息从多个类加载器中确定目标类加载器，目标类加载器根据属性配置信息对应用模块的类加载请求进行处理，并将处理结果返回应用模块，基于此，本申请实施例的类加载方法，突破了双亲委派的加载机制的限制，能够根据应用模块的需求对类加载请求进行处理，能够满足多模块对于类加载请求的动态化需求。

参见图2，该图为本申请实施例提供的一种类加载方法的流程图。

本实施例提供的类加载方法包括如下步骤：

步骤S201：获取应用模块的类加载请求，所述类加载请求携带有所述应用模块的属性配置信息和类加载配置信息。

在本申请的实施例中，应用模块向可插拔装置发送类加载请求，预先将应用模块的类加载属性保存在配置文件中，因此类加载请求中就携带有应用模块的属性配置信息和类加载配置信息。具体的，应用模块的属性配置信息代表应用模块的依赖包的加载路径和加载完毕后的存储路径。类加载配置信息代表应用模块的类加载请求的属性配置。例如，类加载配置信息可以包括反向类加载指示信息，反向类加载指的是优先使用当前类加载器，还可以包括隐藏类加载指示信息，隐藏类加载指示信息指的是不从任何父类加载器加载指定类，还可以包括私有类加载指示信息，私有类加载指示信息指的是防止子类加载器加载指定类，还可以包括覆盖类加载指示信息，覆盖类加载指示信息指的是指定使用父类加载器加载。

需要说明的是，可插拔装置为向多个模块提供服务的装置，如图3所示，可插拔装置也采用模块化设计，模块包括装置基础类库、技术组件、公共服务等；基于可插拔装置构建应用模块，应用模块可依赖一个或多个可插拔装置的模块。

步骤S202：根据所述类加载配置信息从多个类加载器中确定目标类加载器，所述多个类加载器包括非自定义类加载器和多个自定义类加载器，每一个自定义类加载器至少有2个自定义加载器作为父类加载器。

在本申请实施例中，图4为可插拔装置中的多亲类加载模块的多亲委派的加载机制的示意图，由图中可以看出，多亲委派的加载机制也包括3个非自定义类加载器：启动类加载器、扩展类加载器和应用程序类加载器，还包括多个自定义类加载器，每一个自定义类加载器至少有2个自定义加载器作为父类加载器。多亲委派的加载机制提供多种向上查询加载路径，能够解决一个模块依赖多个模块，双亲委派的加载机制由于只有一条向上查询加载路径，无法遍历多个父类加载器的问题。

在本申请的实施例中，可插拔装置根据类加载请求中携带的类加载配置信息从多个类加载器中确定目标类加载器。

需要说明的是，类加载配置信息可以包括应用模块的标识，将多个类加载器中与应用模块的标识对应的类加载器确定为目标类加载器。具体的，可插拔装置为每一个应用模块配置了一个类加载器，即图4中的每个多亲类加载器都对应一个应用模块。每一个应用模块都有自己对应的类加载器，当一个模块需要加载A-1.0.jar版本的依赖包，而另一个模块必须要加载A-2.0.jar版本的依赖包，两个jar包并不兼容，因为每一个模块都有对应的类加载器，因此只需要每个模块自身对应的类加载器加载依赖包，也就是说，即使两个模块需要加载的依赖包的版本不兼容，但是由于每个模块都有自己对应的类加载器，两个版本的依赖包能够分别都被加载。

需要说明的是，类加载配置信息可以包括反向类加载指示信息和应用模块的标识，从多个类加载器中确定与应用模块的标识对应的第一类加载器，根据反向类加载指示信息判断第一类加载器是否能够处理类加载请求，若是，则将第一类加载器确定为目标类加载器，若否，则将第一类加载器的父类加载器作为目标类加载器。具体的，第一类加载器指的是与应用模块对应的类加载器。反向类加载指示信息为优先使用当前类加载器，即首先根据反向类加载指示信息确定与应用模块对应的类加载器，并判断与应用模块对应的类加载器能不能处理类加载请求，若能处理，则确定与应用模块对应的类加载器为目标类加载器，若不能处理，则将与应用模块对应的类加载器的父类加载器作为目标类加载器。

需要说明的是，类加载配置信息可以包括隐藏类加载指示信息，从多个类加载器中确定与应用模块的标识对应的第一类加载器，根据隐藏类加载指示信息判断第一类加载器是否能够处理类加载请求，若是，则将第一类加载器确定为目标类加载器，若否，则向应用模块返回处理失败的处理结果。具体的，第一类加载器指的是与应用模块对应的类加载器。隐藏类加载指示信息为不从任何父类加载器加载指定类，即首先根据隐藏类加载指示信息确定与应用模块对应的类加载器，并判断与应用模块对应的类加载器能不能处理类加载请求，若能处理，则确定与应用模块对应的类加载器为目标类加载器，若不能处理，则向应用模块返回处理失败的处理结果。

步骤S203：控制所述目标类加载器根据所述属性配置信息对所述类加载请求进行处理。

步骤S204：将所述类加载请求的处理结果返回所述应用模块。

在本申请的实施例中，在确定了目标类加载器之后，目标类加载器根据所述属性配置文件对应用模块发送的类加载请求进行加载处理，并将类加载请求的加载处理结果返回应用模块。

需要说明的是，若一个模块依赖多个模块，则需要多个模块的类都加载完毕，该模块的类才能加载，因此多个自定义类加载器包括目标类加载器的至少两个父类自定义加载器。在接收到应用模块的类加载请求后，确定与应用模块对应的类加载器为目标类加载器，控制目标类加载器的至少两个父类自定义加载器对类加载请求进行处理，即目标类加载器的至少两个父类自定义加载器加载具有依赖关系的类，得到第一处理结果。之后控制目标类加载器根据属性配置信息和第一处理结果对类加载请求进行处理，即根据属性配置信息和具有依赖关系的类的加载结果，对应用模块的类加载请求进行加载，得到第二处理结果，将类加载请求的第二处理结果返回应用模块。

本申请实施例提供了一种类加载方法，方法包括：获取应用模块的类加载请求，所述类加载请求携带有所述应用模块的属性配置信息和类加载配置信息；根据所述类加载配置信息从多个类加载器中确定目标类加载器，所述多个类加载器包括非自定义类加载器和多个自定义类加载器，每一个自定义类加载器至少有2个自定义加载器作为父类加载器；控制所述目标类加载器根据所述属性配置信息对所述类加载请求进行处理；将所述类加载请求的处理结果返回所述应用模块。由此可见，本申请实施例通过利用类加载请求中携带的类加载配置信息从多个类加载器中确定目标类加载器，目标类加载器根据属性配置信息对应用模块的类加载请求进行处理，并将处理结果返回应用模块，基于此，本申请实施例的类加载方法，突破了双亲委派的加载机制的限制，能够根据应用模块的需求对类加载请求进行处理，能够满足多模块对于类加载请求的动态化需求。

参见图5，该图为本申请实施例提供的一种类加载方法的实施场景图。

Java虚拟机(Java Virtual Machine，JVM)向应用系统提供类加载的服务是分为五个部分：加载、验证、准备、解析、初始化。类加载器的作用就是负责把模块的类及其依赖加载到Java虚拟机中运行。

如图5所示，应用模块向可插拔装置发送类加载请求，可插拔装置首先通过ClasscachedClass＝findLoadedClass(name)来判断一个类是否已经被加载过，若被加载过，则直接进入解析流程；若没有被加载过，则根据if(name.startsWith("java.")||name.equals("boolean")…)判断是否该类是以java开头的类或者是基本类型，若是以java开头的类或者是基本类型则调用非自定义类加载器进行加载，若不是以java开头的类或者是基本类型，则继续判断是否设置了反向类加载，当前类加载器是否已销毁，并且是否需要覆盖父类中已加载的类，所有条件都满足用当前类加载器加载，若上述条件都不满足，继续判断是否设置了隐藏类加载，若没有设置隐藏类，则从所有父类加载器中查找并加载，若仍没有加载到指定的类，再次判断当前类加载器是否已销毁，若没有销毁则利用当前类加载器进行加载，最后根据解析(resolve)值，判断是否需要解析，若当前类加载器已经销毁，则抛出异常，无法加载。

应用本申请实施例中的多亲委派的加载机制，可以执行如上述所描述的在可插拔装置中多个加载器内进行加载判断的流程，能够尽最大可能去进行类加载。

在将应用系统中的功能区分为不同的模块之后，不同模块之间的加载和卸载不会互相影响，即不同模块之间实现了功能上的隔离，如图6所示。模块之间的隔离有三个层次：类隔离、实例隔离和资源隔离。类隔离指的是为每个模块创建一个类加载器来实现类隔离，即一个模块对应一个单独的类加载器。实例隔离指的是为每个模块创建一个新的控制反转容器(Inversion of Control，IOC)来加载模块里面的BEAN。资源隔离指的是对每个模块创建独立线程池，可利用JVM租户预先指定的中央处理器(Central Processing Unit，CPU)和内存。

本申请实施例2主要介绍模块加载过程中类加载的隔离，接下来介绍模块在卸载过程中的隔离。卸载模块需要满足三个条件：模块里的实例对象没有被引用、模块里的类没有被引用和类加载器没有被引用。所以模块卸载需要做到三个卸载：卸载实例、卸载类和卸载类加载器。如图7所示，为一个模块的卸载顺序示意图。关闭资源指的是关闭超文件传输协定(Hyper Text Transfer Protocol，HTTP)、socket等通信连接及对应线程池。关闭子模块指的是依次卸载子模块。关闭IOC容器指的是调用Spring容器applicationContext.close()方法关闭IOC容器，释放Bean资源，卸载实例对象。移除类加载器指的是去掉模块间的引用，并清理已加载Class对象。卸载JVM租户指的是卸载该模块使用的JVM租户，释放系统资源。

应用系统区分为不同的模块之后，模块之间的通讯可以采用多种方式，如图8示出了模块间通讯的示意图。如果模块在同一个JVM进程中，可以采用本地调用、内存Java消息服务(Java Message Service，JMS)队列等通讯方式；对于跨JVM进程的模块之间，可采用传输控制协议(Transmission Control Protocol，TCP)、超文件传输协定(Hyper TextTransfer Protocol，HTTP)、远程过程调用协议(Remote Procedure Call Protocol，RPC)、消息队列(Message Queue，MQ)等通讯方式。具体的，本地调用指的是如果模块A依赖模块B，即两者之间的类加载器是父子关系，则可以使用本地调用方式进行通讯。JMS队列指的是同一个JVM进程的两个模块，可使用Active MQ构建内存队列通讯。TCP/HTTP指的是模块之间可以定义接口，采用TCP、HTTP以报文方式进行通讯。RPC指的是对于跨JVM进程的两个模块，可以使用发布服务和引用服务RPC通讯。MQ队列指的是模块之间若需要消息持久化，可使用消息中间件MQ传递消息。

如图3所示的可插拔装置为每个应用模块单独创建类加载器、IOC容器和线程池，除了满足模块间隔离之外，每个模块均能动态加载和卸载。装置模块除提供装置级基础服务(比如配置加载)之外，还作为应用模块的父类加载器和父IOC容器，供应用模块向上查找并加载装置类库和组件。此外应用模块之间可配置JMS、多种通讯方式(包括HTTP、TCP、MQ等)进行消息传递。可插拔装置实现模块加载、卸载、隔离、通讯之外，还支持装置本身依赖包和应用依赖包热更新，包括装置的核心依赖JAR包(基础类库等)、应用的第三方依赖包等，这些均由可插拔装置的多亲委派加载机制完成。

基于以上实施例提供的一种类加载方法，本申请实施例还提供了一种装置，下面结合附图来详细说明其工作原理。

参见图9，该图为本申请实施例提供的一种类加载装置的结构框图。

本实施例提供的类加载装置900包括：

获取单元910，用于获取应用模块的类加载请求，所述类加载请求携带有所述应用模块的属性配置信息和类加载配置信息；

确定单元920，用于根据所述类加载配置信息从多个类加载器中确定目标类加载器，所述多个类加载器包括非自定义类加载器和多个自定义类加载器，每一个自定义类加载器至少有2个自定义加载器作为父类加载器；

控制单元930，用于控制所述目标类加载器根据所述属性配置信息对所述类加载请求进行处理；

返回单元940，用于将所述类加载请求的处理结果返回所述应用模块。

可选的，所述类加载配置信息包括所述应用模块的标识；

所述确定单元920根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

所述确定单元920将所述多个类加载器中与所述应用模块的标识对应的类加载器确定为目标类加载器。

可选的，所述多个自定义类加载器包括所述目标类加载器的至少两个父类自定义加载器；

所述控制单元930控制所述目标类加载器根据所述属性配置信息对所述类加载请求进行处理包括：

所述控制单元930控制所述至少两个父类自定义加载器对所述类加载请求进行处理，得到第一处理结果；

所述控制单元930控制所述目标类加载器根据所述属性配置信息和所述第一处理结果对所述类加载请求进行处理，得到第二处理结果；

所述返回单元940将所述类加载请求的处理结果返回所述应用模块包括：

所述返回单元940将所述类加载请求的第二处理结果返回所述应用模块。

可选的，所述类加载配置信息包括：反向类加载指示信息和所述应用模块的标识；

所述确定单元920根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

所述确定单元920从所述多个类加载器中确定与所述应用模块的标识对应的第一类加载器；

所述确定单元920根据反向类加载指示信息判断所述第一类加载器是否能够处理所述类加载请求；

若是，则所述确定单元920将所述第一类加载器确定为所述目标类加载器；

若否，则所述确定单元920将所述第一类加载器的父类加载器作为所述目标类加载器。

可选的，所述类加载配置信息包括：隐藏类加载指示信息；

所述确定单元920根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

所述确定单元920从所述多个类加载器中确定与所述应用模块的标识对应的第一类加载器；

所述确定单元920根据隐藏类加载指示信息判断所述第一类加载器是否能够处理所述类加载请求；

若是，则所述确定单元920将所述第一类加载器确定为所述目标类加载器；

若否，则所述确定单元920向所述应用模块返回处理失败的处理结果。

当介绍本申请的各种实施例的元件时，冠词“一”、“一个”、“这个”和“所述”都意图表示有一个或多个元件。词语“包括”、“包含”和“具有”都是包括性的并意味着除了列出的元件之外，还可以有其它元件。

需要说明的是，本领域普通技术人员可以理解实现上述方法实施例中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。其中，所述存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory,ROM)或随机存储记忆体(RandomAccess Memory,RAM)等。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元及模块可以是或者也可以不是物理上分开的。另外，还可以根据实际的需要选择其中的部分或者全部单元和模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种类加载方法，其特征在于，所述方法包括：

获取应用模块的类加载请求，所述类加载请求携带有所述应用模块的属性配置信息和类加载配置信息；

根据所述类加载配置信息从多个类加载器中确定目标类加载器，所述多个类加载器包括非自定义类加载器和多个自定义类加载器，每一个自定义类加载器至少有2个自定义加载器作为父类加载器；

控制所述目标类加载器根据所述属性配置信息对所述类加载请求进行处理；

将所述类加载请求的处理结果返回所述应用模块。

2.根据权利要求1所述的方法，其特征在于，所述类加载配置信息包括所述应用模块的标识；

所述根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

将所述多个类加载器中与所述应用模块的标识对应的类加载器确定为目标类加载器。

3.根据权利要求2所述的方法，其特征在于，所述多个自定义类加载器包括所述目标类加载器的至少两个父类自定义加载器；

所述控制所述目标类加载器根据所述属性配置信息对所述类加载请求进行处理包括：

控制所述至少两个父类自定义加载器对所述类加载请求进行处理，得到第一处理结果；

控制所述目标类加载器根据所述属性配置信息和所述第一处理结果对所述类加载请求进行处理，得到第二处理结果；

将所述类加载请求的处理结果返回所述应用模块包括：

将所述类加载请求的第二处理结果返回所述应用模块。

4.根据权利要求1所述的方法，其特征在于，所述类加载配置信息包括：反向类加载指示信息和所述应用模块的标识；

所述根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

从所述多个类加载器中确定与所述应用模块的标识对应的第一类加载器；

根据反向类加载指示信息判断所述第一类加载器是否能够处理所述类加载请求；

若是，则将所述第一类加载器确定为所述目标类加载器；

若否，则将所述第一类加载器的父类加载器作为所述目标类加载器。

5.根据权利要求1所述的方法，其特征在于，所述类加载配置信息包括：隐藏类加载指示信息；

所述根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

从所述多个类加载器中确定与所述应用模块的标识对应的第一类加载器；

根据隐藏类加载指示信息判断所述第一类加载器是否能够处理所述类加载请求；

若是，则将所述第一类加载器确定为所述目标类加载器；

若否，则向所述应用模块返回处理失败的处理结果。

6.一种类加载装置，其特征在于，所述装置包括：

获取单元，用于获取应用模块的类加载请求，所述类加载请求携带有所述应用模块的属性配置信息和类加载配置信息；

确定单元，用于根据所述类加载配置信息从多个类加载器中确定目标类加载器，所述多个类加载器包括非自定义类加载器和多个自定义类加载器，每一个自定义类加载器至少有2个自定义加载器作为父类加载器；

控制单元，用于控制所述目标类加载器根据所述属性配置信息对所述类加载请求进行处理；

返回单元，用于将所述类加载请求的处理结果返回所述应用模块。

7.根据权利要求6所述的装置，其特征在于，所述类加载配置信息包括所述应用模块的标识；

所述确定单元根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

所述确定单元将所述多个类加载器中与所述应用模块的标识对应的类加载器确定为目标类加载器。

8.根据权利要求7所述的装置，其特征在于，所述多个自定义类加载器包括所述目标类加载器的至少两个父类自定义加载器；

所述控制单元控制所述目标类加载器根据所述属性配置信息对所述类加载请求进行处理包括：

所述控制单元控制所述至少两个父类自定义加载器对所述类加载请求进行处理，得到第一处理结果；

所述控制单元控制所述目标类加载器根据所述属性配置信息和所述第一处理结果对所述类加载请求进行处理，得到第二处理结果；

所述返回单元将所述类加载请求的处理结果返回所述应用模块包括：

所述返回单元将所述类加载请求的第二处理结果返回所述应用模块。

9.根据权利要求6所述的装置，其特征在于，所述类加载配置信息包括：反向类加载指示信息和所述应用模块的标识；

所述确定单元根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

所述确定单元从所述多个类加载器中确定与所述应用模块的标识对应的第一类加载器；

所述确定单元根据反向类加载指示信息判断所述第一类加载器是否能够处理所述类加载请求；

若是，则所述确定单元将所述第一类加载器确定为所述目标类加载器；

若否，则所述确定单元将所述第一类加载器的父类加载器作为所述目标类加载器。

10.根据权利要求6所述的装置，其特征在于，所述类加载配置信息包括：隐藏类加载指示信息；

所述确定单元根据所述类加载配置信息从多个类加载器中确定目标类加载器包括：

所述确定单元从所述多个类加载器中确定与所述应用模块的标识对应的第一类加载器；

所述确定单元根据隐藏类加载指示信息判断所述第一类加载器是否能够处理所述类加载请求；

若是，则所述确定单元将所述第一类加载器确定为所述目标类加载器；

若否，则所述确定单元向所述应用模块返回处理失败的处理结果。

Images