Spring IOC 源码解析(五) ResourceLoader

最新推荐文章于 2025-09-08 19:30:00 发布

原创最新推荐文章于 2025-09-08 19:30:00 发布 · 514 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#Spring #IOC #ResourceLoader #BeanFactory #资源加载

Spring 同时被 2 个专栏收录

11 篇文章

订阅专栏

Spring 源码深入详细解刨

9 篇文章

订阅专栏

本文深入探讨了Spring框架中资源加载的机制，包括ResourceLoader接口、ResourceUtils工具类、ResourcePatternResolver接口及其实现PathMatchingResourcePatternResolver等核心组件。解析了如何通过不同的策略和实现从类路径、文件系统及Web应用根目录加载资源。

一.前言

用于加载资源的策略接口（例如，类路径或文件系统资源）。需要 ApplicationContext 来提供此功能，以及扩展的ResourcePatternResolver 支持。

DefaultResourceLoader 是一个独立的实现，可以在 ApplicationContext 外部使用，也可以被 ResourceEditor 使用。

使用特定上下文的资源加载策略，在ApplicationContext中运行时，可以从字符串中(路径)填充 Resource 和Resource 数组类型的 Bean 属性。

简单概括就是 Spring 加载外部资源的统一父接口,可以从不同渠道获得.

因为 ResourceLoader 的实现类太多(可以自己在 idea 中查看类结构),所以我会挑一些重要的,常用的来简单描述.其他的用到时我们可以在讨论.
在这里插入图片描述

二.ResourceLoader 结构分解

2.1 ResourceLoader 接口

该接口有一个唯一字段 String 类型,值为 classpath: ,他是从 ResourceUtils 抽象工具类里面应用的字段值 CLASSPATH_URL_PREFIX.

主要功能:

通过 String 类型的 location 获取 Resource.(子类就是实现通过各种 location 解析出资源的)
暴露此 ResourceLoader 使用的 classLoader

2.2 ResourceUtils

ResourceUtils 是一个抽象类,也没有具体的实现, 也可以说他自己就是的实现. 因为他的所有字段和方法都是 static 静态的.所以可以直接通过类来调用.

用于将资源位置解析为文件系统中的文件的实用方法。主要供框架内部使用。

ResourceLoader 的 getResource() 方法可以解析 Resource 对象的任何位置，从而允许通过其 getFile() 方法获取文件系统中的 java.io.File。

主要功能:
1.定义了一系列的协议静态字段
2.从指定 url 或 url 或 resourceLocation(String) 获取指定 File
3.将 URL 或 resourceLocation (String) 转为为实际的文件 URI
4.判断给定的 resourceLocation (String) 是否是 url
5.判断给定的 URL 是否指向文件系统中的资源

2.3 ResourcePatternResolver

用于将位置模式（例如，Ant 样式路径模式）解析为 Resource 对象的策略接口。

这是 ResourceLoader 接口的扩展。传入的R esourceLoader（例如，在上下文中运行时通过ResourceLoaderAware 传入的 ApplicationContext）可以检查它是否也实现了这个扩展接口。

子类 PathMatchingResourcePatternResolver 是一个独立的实现，可以在 ApplicationContext 外部使用，也可以由 ResourceArrayPropertyEditor 用于填充 Resource 数据 bean 属性。

可以与任何类型的位置模式一起使用（例如“/WEB-INF/*-context.xml”）：输入模式必须与策略实现相匹配。此接口仅指定转换方法而不是特定的模式格式。

该接口有一个唯一的属性和一个唯一的方法:
属性:String CLASSPATH_ALL_URL_PREFIX = "classpath*:"

方法:Resource[] getResources(String locationPattern)
类路径中所有匹配资源的伪 URL 前缀：“classpath *：”这与 ResourceLoader 的类路径URL前缀的不同之处在于它检索给定名称的所有匹配资源

2.4 PathMatchingResourcePatternResolver

ResourcePatternResolver 实现，它能够将指定的资源位置路径解析为一个或多个匹配的资源。源路径可以是一个简单的路径，该路径具有到目标资源的一对一映射，或者可以包含特殊的“classpath*：”前缀和/或内部Ant 样式正则表达式（使用Spring的 AntPathMatcher 实用程序进行匹配）。后者都是有效的通配符。

在简单的情况下，如果指定的位置路径不以“classpath *：”前缀开头，并且不包含PathMatcher模式，则此解析器将通过底层ResourceLoader上的getResource（）调用返回单个资源。

通过“classpath *：”前缀，可以检索具有相同名称的多个类路径资源。
例如，“classpath *：META-INF / beans.xml”将在类路径中找到所有“beans.xml”文件，无论是在“classes”目录中还是在JAR文件中。

概括:传入的 location (String) 可以是 Ant 样式的路径或 classpath * 前缀的路径,解析后返回所有匹配到的 Resource .

Ant 样式示例:

 /WEB-INF/*-context.xml
 com/mycompany/**/applicationContext.xml
 file:C:/some/path/*-context.xml
 classpath:com/mycompany/**/applicationContext.xml

主要功能(部分):

搜索URLClassLoader 所有 URL 以获取 jar 文件引用，并以指向 jar 文件内容根目录的形式将它们添加到给定的资源集。(概括:将所有 jar 文件的根目录 URL 存入指定的 Set 集合中)
从系统属性 java.class.path 中获取所有 jar 文件引用,添加到指定 Set 集合中
将 ClassLoader 返回的 URL 转化为 resource
确定给定 location 的根目录
通过 ClassLoader 查找具体给定路径的所有类位置资源。

概括:该类的主要功能是解析 location(String) 或系统参数等等,获取多资源的功能.

2.5 ServletContextResourcePatternResolver

PathMatchingResourcePatternResolver 的 ServletContext 子类，能够通过ServletContext.getResourcePaths（java.lang.String）在Web应用程序根目录下找到匹配的资源。返回超类的文件系统，检查其他资源。

主要功能:

重写 PathMatchingResourcePatternResolver 的 doFindPathMatchingFileResources 方法，它检查ServletContextResource 并使用 ServletContext.getResourcePaths 查找 Web 应用程序根目录下的匹配资源。
递归检索与给定模式匹配的 ServletContextResources ，将它们添加到给定的结果集。

2.6 DefaultResourceLoader

ResourceLoader 接口的默认实现。由 ResourceEditor 使用，并作为 AbstractApplicationContext 的基类。也可以单独使用。

如果位置值是URL，则返回UrlResource;如果是非URL路径或“classpath：”伪URL，则返回ClassPathResource。

主要功能:

使用此资源加载器注册给定的解析程序，允许处理其他协议。
清除此资源加载器中的所有资源缓存。
返回 ClassLoader 以加载类路径资源。
返回当前注册的协议解析器的集合，允许默认和修改。
返回指定资源位置的资源.
指定 ClassLoader 以使用或加载类路径资源，以便在实际资源访问时使用线程上下文类加载器。

2.7 AbstractApplicationContext

ApplicationContext 接口的抽象实现。不要求用于配置的存储类型;只需实现常见的上下文功能使用 Template Method 设计模式，需要具体的子类来实现抽象方法

AbstractApplicationContext 的父类就是 DefaultResourceLoader, AbstractApplicationContext 是所有上下文的基类,也就保证的所有的 ApplicationContext 都是具备了资源加载的功能.

AbstractApplicationContext 作为所有上下文的基类,实现了很多 ApplicationContext 的公用的功能,因为功能太多,我们会在后面讲解源码的遇到的时候在一点一点讲解.

这里我们主要知道他的两个特性:

AbstractApplicationContext 的基类是 DefaultResourceLoader,即 AbstractApplicationContext 具备资源加载能力,
AbstractApplicationContext 是所有 ApplicationContext 实现的基类, 即有 ApplicationContext 都具备资源加载能力.

Spring IOC 源码解析(六) XmlBeanFactory