CN108279940A - 一种web容器中的模块加载方法和装置 - Google Patents

Abstract

本发明公开了一种web容器中的模块加载方法和装置，以解决现有的Web容器启动过程中类查找速度较慢的问题。该方法为，在第一web应用的web容器启动过程中，获取预先配置的所述第一web应用的各模块的黑名单和/或白名单；若获取到各模块的白名单，当通过通用类加载器查找类时，在白名单中包括的各模块中执行类查找和加载；若获取到各模块的黑名单、且未获取到白名单，当通过通用类加载器查找类时，遍历对应的通用类加载路径下的各个模块是否包括在所述黑名单中，若对应的通用类加载路径下的任一模块包括在所述黑名单中，则不针对所述任一模块执行类查找，这样能够黑白名单的模块配置类加载范围，减少类搜索耗时，提升启动速度。

Description

一种web容器中的模块加载方法和装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种web容器中的模块加载方法和装置。

背景技术

当今互联网上充斥着无数的web网站，每一个Web网站就是一个Web应用，而每个应用都会部署在一个web容器上。Web容器实际上就是一个Java运行时(Runtime)环境，提供了应用的类加载(classloader)、Java Servlet API的初始化及发布，并提供基于超文本传输协议(Hyper Text Transfer Protocol，HTTP)/安全套接字层超文本传输协议(Hyper TextTransfer Protocol over Secure Socket Layer，HTTPS)的一系列访问接口。

Web容器是一个基础的类(class)运行环境，每一段Java程序都会以.class形式发布，并归档在一系列jar、war、sar类型的软件包中。

Web容器在启动时需要使用各自的类加载器，从自定义的类查找目录下查找需要的class文件及资源文件，经过class装载、链接、初始化后，Java虚拟机(Java VirtualMachine，JVM)中将会缓存一份描述所有加载class的元信息结构，通过该结构可以获取class的结构信息，如：构造函数、属性、方法，进而JVM可以获取class实例并进行方法调用。Web容器的启动过程就是一系列类加载及类初始化的过程，在每个类初始化动作固定时如果最快的查找到类很大程度决定了容器的启动速度。

JVM的类加载采用父类委托机制，如图1所示，当JVM需要加载一个class时，会按图1中的多层类加载关系，先从父classloader中加载，如果加载不到该class，会使用对应的子classloader继续到对应目录下进行class查找及加载。

经过多年的互联网发展，很多Web应用的功能越来越全面，进而带来的系统复杂度也越来越高，每个系统都有几十甚至上百个子模块构建完成，部署在同一个Web容器内，系统涉及的模块不断增长，一个应用上线前需要集成数百个模块，应用WEB/lib目录下存在成百上千个jar包，包含了上万、几十万个class。当JVM进行类查找时，每个class都需要从这几百、几千个jar中遍历查找，速度很慢。假设系统启动使用了1000个class，一共有500个jar包，那会进行1000*500次的jar包遍历，而每个jar包内部还是几十、几百次的class查找。

发明内容

本发明实施例提供一种web容器中的模块加载方法和装置，以解决现有的web容器启动过程中类查找速度较慢的问题。

第一方面，本发明实施例提供一种web容器中的模块加载方法，包括：

在第一web应用的web容器启动过程中，获取预先配置的所述第一web应用的各模块的黑名单和/或白名单；

若获取到所述第一web应用的各模块的白名单，当通过通用类加载器查找类时，在所述白名单中包括的各模块中执行类查找和加载；

若获取到所述第一web应用的各模块的黑名单、且未获取到所述第一web应用的各模块的白名单，当通过通用类加载器查找类时，遍历对应的通用类加载路径下的各个模块是否包括在所述黑名单中，若对应的通用类加载路径下的任一模块包括在所述黑名单中，则不针对所述任一模块执行类查找。

采用上述方案，由于通用类加载器中包含了大部分的web应用jar包，通过将web应用模块化，基于模块的黑白名单配置类加载范围，可以减少类搜索的耗时，提升启动速度。

一种可能的设计中，所述方法还包括：

在第一web应用的web容器启动过程中，在初始化类加载路径之后，执行类冲突检测得到检测结果，并给出日志提示。

上述设计中，在初始化类加载路径之后，当发现类冲突时，可以通过日志进行记录并提示，可以提前发现类冲突，给出改进方向。

一种可能的设计中，所述类冲突检测包括jar包的多版本检测和类的依赖检测。

一种可能的设计中，在初始化类加载路径之后，执行类冲突检测得到检测结果，并给出日志提示，包括：

执行类冲突检测得到检测结果，并给出日志提示，包括：

遍历所述通用类加载路径下的所有jar包，识别名称相同的jar包和名称相同且版本不同的jar包，得到检测结果，并给日志提示；

对通用类加载路径下的所有类文件进行字码解析，获取类依赖关系，并从所述通用类加载路径下查找所述依赖关系否存在，得到检测结果，并给出日志提示。

上述设计中，通过jar包的冲突检测及类的依赖测，可以在web容器启动时提前发现class冲突及class缺失情况，避免问题遗漏到运行态。

一种可能的设计中，所述方法还包括：

若对应的通用类加载路径下的任一模块不包括在所述黑名单中，则针对所述任一模块执行类查找和加载。

上述设计中，采用黑名单控制类加载范围，类加载时从黑名单范围外的模块中进行类及资源的查找，可以有效减少无效的类查找，提升web应用的启动速度。

第二方面，本发明实施例一种web容器中的模块加载装置，包括：

获取单元，用于在第一web应用的web容器启动过程中，获取预先配置的所述第一web应用的各模块的黑名单和/或白名单；

处理单元，用于在获取到所述第一web应用的各模块的白名单，当通过通用类加载器查找类时，在所述白名单中包括的各模块中执行类查找和加载；

所述处理单元，还用于在获取到所述第一web应用的各模块的黑名单、且未获取到所述第一web应用的各模块的白名单，当通过通用类加载器查找类时，遍历对应的通用类加载路径下的各个模块是否包括在所述黑名单中，若对应的通用类加载路径下的任一模块包括在所述黑名单中，则不针对所述任一模块执行类查找。

一种可能的设计中，所述装置还包括：

检测单元，用于在第一web应用的web容器启动过程中，在初始化类加载路径之后，执行类冲突检测得到检测结果，并给出日志提示。

一种可能的设计中，所述类冲突检测包括jar包的多版本检测和类的依赖检测。

一种可能的设计中，所述检测单元在执行类冲突检测得到检测结果，并给出日志提示时，具体用于：

所述检测单元在执行类冲突检测得到检测结果，并给出日志提示时，具体用于：

遍历所述通用类加载路径下的所有jar包，识别名称相同的jar包和名称相同且版本不同的jar包，得到检测结果，并给日志提示；

对通用类加载路径下的所有类文件进行字码解析，获取类依赖关系，并从所述通用类加载路径下查找所述依赖关系否存在，得到检测结果，并给出日志提示。

一种可能的设计中，所述处理单元还用于：

若对应的通用类加载路径下的任一模块不包括在所述黑名单中，则针对所述任一模块执行类查找和加载。

第三方面，本发明实施例提供一种设备，该设备包括处理器、存储器，其中，所述存储器中存有计算机可读程序，所述处理器通过运行所述存储器中的程序，实现第一方面涉及的web容器中的模块加载方法。

第四方面，本发明实施例提供一种计算机存储介质，用于储存为上述第一方面所用的计算机软件指令，其包含用于执行上述由控制实现的方法所设计的程序。

应理解，本发明实施例的第二至四方面与本发明实施例的第一方面的技术方案一致，各方面及对应的可实施的设计方式所取得的有益效果相似，不再赘述。

附图说明

图1为JVM的类加载机制示意图；

图2、图3为类查找路径示意图；

图4为web容器系统结构图；

图5为本发明实施例中的web容器中的模块加载方法流程图；

图6为模块保存文件示意图；

图7为模块的黑白名单部署示意图；

图8为典型的class文件组成示意图；

图9为本发明实施例中的web容器中的模块加载装置结构图；

图10为本发明实施例中的web容器中的模块加载设备结构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述。

下面，对本发明实施例涉及的基本概念进行解释。需要说明的是，这些解释是为了让本发明实施例更容易被理解，而不应该视为对本发明所要求的保护范围的限定。

Jar包即Java归档(Java Archive)包，是最基本的class压缩包形式，包含javaclass、metadata描述文件以及资源文件(文本、图片等)；war包是web应用归档(webapplication archive)包，除了Jar包外还可以包含xml文件、JSP文件等，主要用于web应用的部署；sar包是业务归档(service archive)包，最常见于JBoss容器，也是jar包的压缩包合集，还包含一个service.xml的描述文件。

此外，每个class都有一个包(package)及类名称(class name)，package类似于class的路径(path)，而class name是这个class的名称，package+class name唯一确认class，当2个class有相同的package+name，但内部逻辑实现不一致时，认为这种现象是Class冲突。

现有的开发模式推崇平台化及模块化，平台构建基础能力，应用构建业务实现，进而人为基于业务场景划分出很多个模块。每个模块都由一个项目组进行开发，当系统部署时再将平台及业务的数十、数百个模块集成到一起。基于现有的类加载机制，class加载时会从应用的WEB/lib下查找，查找是按照jar包的命名字母顺序，此时如果多个模块的开发使用了相同名称但不同实现的class，系统只会加载其中最先查找到的那个class，会给应用带来很大的不确定性，可能在启动时报错，甚至在系统运行期存在潜在漏洞(bug)。

常见的web容器有Tomcat、Weblogic、WebSphere、JBoss、Jetty等，没有这些web容器，web应用程序就无法成功部署在互联网上，也无法提供当前丰富多彩的互联网体验。

当前使用最广泛的web容器是Apache Tomcat。当web容器是Tomcat时，会创建如下几种类加载器：

1、引导类(Bootstrap)加载器

该Classloader会加载JVM启动所需的类，以及标准扩展类。Class的查找路径位于jdk的jre/lib/ext下

2、系统类(System)加载器

该Classloader会去加载tomcat启动的类，比如bootstrap.jar，通常在catalina.bat或者catalina.sh中指定。Class的查找路径为CATALINA_HOME/bin下，如图2中的bootstrap.jar、commons-daemon.jar以及tomcat-juli.jar。

3、通用类(Common)加载器

ClassLoader去加载tomcat使用以及应用通用的一些类，位于CATALINA_HOME/lib下，比如图3中所有jar包。

4、应用类(webapp)加载器

每个应用在部署后，都会创建一个唯一的类加载器。该类加载器会加载位于应用自身目录下WEB-INF/lib下的jar文件中的class和WEB-INF/classes下的class文件。

通过上面多层类加载器进行class查找的方式，当应用需要到某个类时，会按照下面的顺序进行类加载：

1)使用bootstrap引导类加载器在jre/lib目录下查找、加载。

2)使用system系统类加载器在web容器默认类加载目录下查找、加载。

3)使用应用类加载器在应用自身的WEB-INF/classes中查找、加载。

4)使用应用类加载器在应用WEB-INF/lib中查找、加载。

5)使用common类加载器在CATALINA_HOME/lib中加载，tomcat最后才会查找common目录。

由于web应用的功能越来越全面，进而带来的系统复杂度也越来越高，每个系统都有几十甚至上百个子模块构建完成，部署在同一个web容器内，以一个客户关系管理(customer relation management，CRM)系统为例，随着业务场景的不断发展，从最基础的开户、报价、订单到客户数据分析、营销推广、客户评价等，系统涉及模块不断增长。一个应用上线前需要集成数百个模块，应用WEB/lib目录下存在成百上千个jar包，包含了上万、几十万个class。当JVM进行类查找时，每个class都需要从这几百、几千个jar包中遍历查找，速度很慢。

鉴于此，本发明实施例提供一种web容器中的模块加载方法和装置，以解决现有的Web容器启动过程中类查找速度较慢的问题。

其中，方法和装置是基于同一发明构思的，由于方法及装置解决问题的原理相似，因此装置与方法的实施可以相互参见，重复之处不再赘述。

图4所示，本发明实施例中的web容器系统结构图。从图4中可以看出每个web容器中均有一个http接入单元、一套classloader、容器的公共lib库以及一些应用包，容器的公共lib库及应用包中均在classpath下，供启动时的class查找。

针对图4所示的web容器，参阅图5所示，本发明实施例提供一种web容器中的模块加载方法，具体流程如下所示：

步骤51：在第一web应用的web容器启动过程中，获取预先配置的所述第一web应用的各模块的黑名单和/或白名单。

需要说明的是，针对第一web应用的各模块可以同时配置黑白名单或只配置黑名单或只配置白名单，这里不作限制。

此外，本发明实施例中第一web应用的jar包，基于系统的模块化开发，但是不进行模块集成，而是将各模块以单独文件夹存放，每个文件夹是一个独立的jar包合集或是一个war包格式，将每个模块的包按模块名保存在CATALINA_HOME/lib目录下，如图6中的，bdf、bodaf、bppf、das等均为模块名，每个模块中包含各自模块下的jar包及资源文件。

复杂系统由多模块集成后部署，一般会将各模块的所有jar包合并到应用的WEB/lib目录中。

在web应用进行模块化配置后，可以从启动配置中清晰的看到该web应用依赖的所有模块。由于该web应用基于模块拆分，每个模块可以单独升级，不需要每次都集成，提高了web应用的可维护性。

步骤52：若获取到所述第一web应用的各模块的白名单，当通过通用类加载器查找类时，在所述白名单中包括的各模块中执行类查找和加载。

由于在第一web应用的版本发布之前，配置了模块的黑白名单，使class基于模块进行加载，class查找时，只从classpath下白名单配置的对应模块内进行jar检索，跳过其他模块，缩小查找范围，提高类查找效率。

步骤53：若获取到所述第一web应用的各模块的黑名单、且未获取到所述第一web应用的各模块的白名单，当通过通用类加载器查找类时，遍历对应的通用类加载路径下的各个模块是否包括在所述黑名单中，若对应的通用类加载路径下的任一模块包括在所述黑名单中，则不针对所述任一模块执行类查找。

进一步的，若对应的通用类加载路径下的任一模块不包括在所述黑名单中，则针对所述任一模块执行类查找和加载。

在第一web应用的部署配置文件中采用黑白名单模式选择依赖的模块，如图7所示，Excludes表示黑名单，即列表中的模块不在类加载路径下，Includes表示白名单，即只会在列表中的模块中进行jar包遍历。

现有技术中在进行类加载时，会从classpath下遍历所有文件夹，查找所有class及jar包。本发明实施例中通过配置模块的黑白名单列表，如果当前配置了白名单通过Common_Classloader中查找时，如果对应的类加载路径即CATALINA_HOME/lib下的文件夹名在黑名单中时，跳过该模块，继续遍历其他模块；如果当前配置了白名单列表，只在白名单列表中的模块中进行class搜索和加载。

这样，将现有应用WEB/lib目录下jar包基于模块的黑白名单分解成多个子加载路径，可以有选择性的定制class查找路径，而不需要在当前完整classpath下进行遍历，从而减少了class查找范围，降低了查找耗时，提升启动速度。

可选的，在第一web应用的web容器启动过程中，在初始化类加载路径之后，执行类冲突检测得到检测结果，并给出日志提示。

其中，所述类冲突检测包括jar包的多版本检测和类的依赖检测。

具体的，在第一web应用的web容器启动过程中，在初始化类加载路径之后，执行类冲突检测得到检测结果，并给出日志提示，具体可以但不限于通过以下两种方式执行类冲突检测得到检测结果，并给出日志提示：

方式一，遍历所述通用类加载路径下的所有jar包，识别名称相同的jar包和名称相同版本不同的jar包，得到检测结果，并给日志提示。

方式一为Jar包级的冲突检测，只会检查classpath下是否有重名jar包或多版本同名的jar包。

Jar包的命名一般采用以下约束：名称-版本.jar，版本中无“-”符号。通过分割最后一个“-”，可以获取到jar包名及jar包版本号

1)重名jar，表示jar包名称及版本相同，这种情况下一般jar包完全一致，一般是在多模块集成时不同模块使用了相同依赖从而导致的，由于jar包完全一致，不会存在class不一致的情况，只是多次归档在应用包中导致应用占用硬盘空间变大，对功能无影响，通过日志记录进行提示。

2)多版本同名jar，表示jar包名称相同但版本不同。此时jar包一般不完全一致，可能是不同模块使用了不同版本的jar包。Jar包检索时按字母顺序，一般都会先检索到低版本jar，一旦class被该classloader加载后就不会再去加载其他同名的class。如果有模块使用了高版本的新特性，此时必然导致功能失效。所以，当发现有同名jar包存在多版本时，也会通过日志记录进行提示。

方式二，对通用类路径下的所有类文件进行字码解析，获取类依赖关系，并从通用类加载路径下查找所述依赖关系否存在，得到检测结果，并给出日志提示。

方式二是class级的冲突检测。Class级主要用来校验class依赖情况。

class文件是Java程序二进制的精确定义，每一个class文件都是对一个Java类或者接口的描述，有着统一的格式定义，如图8所示。

其中常量池(Constant_Pool)中包含了依赖的外部类、方法及变量。

一个典型的class文件分为：魔数字(MagicNumber)，版本(Version)，常量池(Constant_pool)，访问标志(Access_flag)，当前类(This_class)，父类(Super_class)，接口(Interfaces)，变量(Fields)，方法(Methods)和属性(Attributes)这十个部分，用一个数据结构可以表示如下：

其中u1，u2，u4，u8分别代表1字节，2字节，4字节和8字节的无符号类型整数。

constant_pool_count表示常量池中元素的个数

constant_pool[constant_pool_count-1]是常量池，每个常量中包含常量类型、方法类型描述符索引、字段描述符索引，举例如下：

09 00 17 00 18

09——tag值为9，类型为CONSTANT_Fieldref_info；

00 17——#23声明当前方法类型描述符索引为23；

00 18——#24字段描述符的名称和类型索引值为24；

通过获取方法类型描述符索引(上面例子中为23)，可以知道该class依赖的所有class的索引值，根据该索引值再从常量池中查找对应常量，从而获取到具体的类信息，如下：

常量23：

07 00 1E

07——tag值为7，类型为CONSTANT_Class_info；

00 1E——#30类型为“类或接口符号引用”，所以全限定名常量索引为30；

常量30：

01 00 10 6A 61 76 61 2F 6C 61 6E 67 2F 53 79 73 74 65 6D

01——tag值为1，类型为CONSTANT_Utf8_info；

00 10——这个UTF-8编码的常量字符串长度为16；

6A 61 76 61 2F 6C 61 6E 67 2F 53 79 73 74 65 6D——16字节的字符串，对应：java/lang/System

根据常量依赖索引及索引对应常量值，可以获得该class依赖的类。

在class级别检测中，会从classpath下将所有class进行字节码解析，获取所有已有class的列表A及依赖的class列表B，依赖列表B中的所有class均要在列表A中存在，否则认为class不足，启动或系统运行时存在问题。

Class级别的冲突检测会遍历classpath下所有class并进行二进制解析，耗时较长，可以在开发态使用。

这样，通过在web容器启动时添加类冲突检测的控制点，在进行class加载前基于classpath查找jar包冲突或类依赖关系冲突，从而提前发现类冲突，避免过长启动时间的浪费。

基于上述方法实施例，参阅图9所示，本发明实施例提供一种web容器中的模块加载装置900，应用在web容器中，如图9所示，该装置900包括获取901和处理单元902，其中：

获取单元901，用于在第一web应用的web容器启动过程中，获取预先配置的所述第一web应用的各模块的黑名单和/或白名单；

处理单元902，用于在获取到所述第一web应用的各模块的白名单，当通过通用类加载器查找类时，在所述白名单中包括的各模块中执行类查找和加载；

所述处理单元902，还用于在获取到所述第一web应用的各模块的黑名单、且未获取到所述第一web应用的各模块的白名单，当通过通用类加载器查找类时，遍历对应的通用类加载路径下的各个模块是否包括在所述黑名单中，若对应的通用类加载路径下的任一模块包括在所述黑名单中，则不针对所述任一模块执行类查找。

可选的，所述装置900还可以包括检测单元903，用于在第一web应用的web容器启动过程中，在初始化类加载路径之后，执行类冲突检测得到检测结果，并给出日志提示。

可选的，所述类冲突检测包括jar包的多版本检测和类的依赖检测。

可选的，所述检测单元903在执行类冲突检测得到检测结果，并给出日志提示时，具体用于：

遍历所述通用类加载路径下的所有jar包，识别名称相同的jar包和名称相同且版本不同的jar包，得到检测结果，并给日志提示；

对通用类加载路径下的所有类文件进行字码解析，获取类依赖关系，并从所述通用类加载路径下查找所述依赖关系否存在，得到检测结果，并给出日志提示。

可选的，所述处理单元902还用于若对应的通用类加载路径下的任一模块不包括在所述黑名单中，则针对所述任一模块执行类查找和加载。

本发明实施例中的装置900的各个单元的功能实现以及交互方式可以进一步参照相关方法实施例的描述，在此不再赘述。

应理解以上装置900中的各个单元的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。此外，也可以以程序代码的形式存储于控制器的存储元件中，由控制器的某一个处理元件调用并执行以上各个单元的功能。此外各个单元可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个单元可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。该处理元件可以是通用处理器，例如中央处理器(英文：central processing unit，简称：CPU)，还可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(英文：application-specific integrated circuit，简称：ASIC)，或，一个或多个微处理器(英文：digital signal processor，简称：DSP)，或，一个或者多个现场可编程门阵列(英文：field-programmable gate array，简称：FPGA)等。

基于同一构思，本发明实施例还提供web容器中的模块加载设备1000，如图10所示，该设备1000包括处理器1001、存储器1002，执行本申请方案的程序代码保存在存储器1002中，用于指令处理器1001执行图5所示的web容器中的模块加载方法

本发明实施例还可以通过对处理器进行设计编程，将图5所示的方法所对应的代码固化到芯片内，从而使芯片在运行时能够执行图5所示的方法，其具体实现过程可以参照上述方法实施例执行方法的相关描述，此处不再赘述。

可以理解的是，本发明实施例上述设备1000中涉及的处理器可以是一个CPU，DSP，ASIC，或一个或多个用于控制本发明方案程序执行的集成电路。计算机系统中包括的一个或多个存储器，可以是只读存储器(英文：read-only memory，简称ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(英文：random access memory，简称：RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是磁盘存储器。这些存储器通过总线与处理器相连接；上述接收器和发射器可以通过收发器实现其功能，所述收发器可以是能够实现收发功能的实体模块，以便与其他设备通信。上述存储器可以是RAM，保存有执行本发明方案的程序。

这些存储器可以通过总线与处理器相连接，或者也可以通过专门的连接线分别与处理器连接。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明实施例是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明实施例的精神和范围。这样，倘若本发明实施例的这些修改和变型属于权利要求及其等同技术的范围之内，则本发明实施例也意图包含这些改动和变型在内。

Claims (10)

1.一种web容器中的模块加载方法，其特征在于，包括：

在第一web应用的web容器启动过程中，获取预先配置的所述第一web应用的各模块的黑名单和/或白名单；

若获取到所述第一web应用的各模块的白名单，当通过通用类加载器查找类时，在所述白名单中包括的各模块中执行类查找和加载；

若获取到所述第一web应用的各模块的黑名单、且未获取到所述第一web应用的各模块的白名单，当通过通用类加载器查找类时，遍历对应的通用类加载路径下的各个模块是否包括在所述黑名单中，若对应的通用类加载路径下的任一模块包括在所述黑名单中，则不针对所述任一模块执行类查找。

2.如权利要求1所述的方法，其特征在于，所述方法还包括：

在第一web应用的web容器启动过程中，在初始化类加载路径之后，执行类冲突检测得到检测结果，并给出日志提示。

3.如权利要求2所述的方法，其特征在于，所述类冲突检测包括jar包的多版本检测和类的依赖检测。

4.如权利要求3所述的方法，其特征在于，执行类冲突检测得到检测结果，并给出日志提示，包括：

遍历所述通用类加载路径下的所有jar包，识别名称相同的jar包和名称相同且版本不同的jar包，得到检测结果，并给日志提示；

对通用类加载路径下的所有类文件进行字码解析，获取类依赖关系，并从所述通用类加载路径下查找所述依赖关系否存在，得到检测结果，并给出日志提示。

5.如权利要求1-4任一项所述的方法，其特征在于，所述方法还包括：

若对应的通用类加载路径下的任一模块不包括在所述黑名单中，则针对所述任一模块执行类查找和加载。

6.一种web容器中的模块加载装置，其特征在于，包括：

获取单元，用于在第一web应用的web容器启动过程中，获取预先配置的所述第一web应用的各模块的黑名单和/或白名单；

处理单元，用于在获取到所述第一web应用的各模块的白名单，当通过通用类加载器查找类时，在所述白名单中包括的各模块中执行类查找和加载；

所述处理单元，还用于在获取到所述第一web应用的各模块的黑名单、且未获取到所述第一web应用的各模块的白名单，当通过通用类加载器查找类时，遍历对应的通用类加载路径下的各个模块是否包括在所述黑名单中，若对应的通用类加载路径下的任一模块包括在所述黑名单中，则不针对所述任一模块执行类查找。

7.如权利要求6所述的装置，其特征在于，所述装置还包括：

检测单元，用于在第一web应用的web容器启动过程中，在初始化类加载路径之后，执行类冲突检测得到检测结果，并给出日志提示。

8.如权利要求7所述的装置，其特征在于，所述类冲突检测包括jar包的多版本检测和类的依赖检测。

9.如权利要求8所述的装置，其特征在于，所述检测单元在执行类冲突检测得到检测结果，并给出日志提示时，具体用于：

遍历所述通用类加载路径下的所有jar包，识别名称相同的jar包和名称相同且版本不同的jar包，得到检测结果，并给日志提示；

对通用类加载路径下的所有类文件进行字码解析，获取类依赖关系，并从所述通用类加载路径下查找所述依赖关系否存在，得到检测结果，并给出日志提示。

10.如权利要求6-9任一项所述的装置，其特征在于，所述处理单元还用于：

若对应的通用类加载路径下的任一模块不包括在所述黑名单中，则针对所述任一模块执行类查找和加载。