Spring核心解析—Resource与ResourceLoader接口
Resource你不得不知的事情
-
-
- 前言
- Resource内容
-
- 继承结构
- DOC解释
- 提供的功能
- 重要的内置Resource实现
-
- UrlResource
- ClassPathResource
- FileSystemResource
- ServletContextResource
- InputStreamResource
- ByteArrayResource
- ResourceLoader内容
-
- 结构体系
- 源码分析
- ResourcePatternResolver内容
-
- 容器与Resolver关系
-
前言
我们为什么要学习Spring下面的Resource模块？
首先我们要了解什么是资源，我们把资源来自于几个方面：比如spring中xml配置文件，url网络上不同渠道的资源，自建的properties文件等，程序对于这些资源的访问，被称之为资源访问。
我们在学习spring之前，接触过一些资源访问API，比如InputStream等文件的IO，java.net.URL。
首先，它们都不是专门为Web服务设计的，对于Spring服务，这些工具比较底层，直接使用这些方法，首先要编写更多额外的代码，比如文件是否存在的判断，路径转换。
其次，他们对于访问底层资源的能力不够，没有一种URL的实现可以访问需要从类路径的资源或者相对于ServletContext获得的资源，虽然可以为专门的URL前缀注册新的处理程序（类似于现有的用于前缀的处理程序：如http：），但是比较复杂。而且URL缺少需要的一些功能，比如检查被指向的资源是否存在的方法（上面提到过，原理在于，URL表示一个统一的资源定位符，一个指向互联网上“资源”的指针，较于Resource更侧重于web资源，而Resource是实现资源的抽象，可以检查资源是否存在）。
Spring整合了获取资源的工具，统一读取例如本地文件，classpath项目路径下的文件，url互联网上的文件等不同渠道的资源，也封装了打开流，关闭流，报错处理等大量重复模板的代码，专程设计Resource接口类。
Resource内容
继承结构
代码如下：
public interface Resource extends InputStreamSource
InputStreamSource接口：spring核心工具包输入流接口，该接口只有一个抽象方法，每次调用这个方法都会得到一个新的流。
public interface InputStreamSource {
InputStream getInputStream() throws IOException;
}
DOC解释
* Interface for a resource descriptor that abstracts from the actual
* type of underlying resource, such as a file or class path resource.
*从实际类型的底层资源（例如文件或类路径资源）中抽象出来的资源描述符的接口
提供的功能
boolean exists();//返回Resource所指向的底层资源是否存在
default boolean isReadable() { //返回当前Resource代表的底层资源是否可读
return exists();
}
default boolean isOpen() {
//返回Resource资源文件是否已经打开，如果是，则只能被读取一次然后关闭以避免内存泄漏
//常见的Resource实现一般都返回false
return false;
}
//如果当前Resource代表的底层资源能由java.util.URL代表，则返回URL，否则抛出io异常
URL getURL() throws IOException;
//如果当前Resource代表的底层资源能由java.util.URI代表，则返回该URI，否则抛出io异常
URI getURI() throws IOException;
// 如果当前Resource代表的底层资源能由java.io.File代表，则返回FIle，否则抛出io异常
File getFile() throws IOException;
//返回当前Resource代表的底层资源的长度，一般是值代表的文件资源的长度。
long contentLength() throws IOException;
//返回当前Resource代表的底层资源的最后修改时间。
long lastModified() throws IOException;
@Nullable
//返回当前Resource代表的底层文件资源的文件路径，比如File资源“file://E:/hao/wang.txt”将返回“E:/hao/wang.txt”
//如果是URL资源，无论地址是多少，都返回"",因为只会返回文件路径。
String getFilename();
//返回当前Resource代表的底层资源的描述符，通常是资源的全路径（实际的文件名或实际的URL地址）
String getDescription();
重要的内置Resource实现
先看一下Resource接口的子类都有什么：
我们简单看一看Spring内提供的比较重要常用的Resource实现：
- UrlResource
- ClassPathResource
- FileSystemResource
- ServletContextResource
- InputStreamResource
- ByteArrayResource
- 等等。。
UrlResource
代表URL资源，用于简化URL资源访问，对java.net.URL进行了包装。该方法接受一个表示路径的字符串参数，它把不同来源的资源抽象成URL，通过注册不同的handler来处理不同来源的资源的读取逻辑。一般不同类型使用不同的前缀。
isOpen 永远返回false，表示可多次读取资源。
UrlResource应该提供标准的协议前缀，一般支持如下资源访问：
- http：通过标准的http协议访问web资源
- ftp：通过ftp协议访问资源
- file：通过file协议访问本地文件系统资源
缺点：
UrlResource无法解决相对于classPath路径或servletContext的处理方法，因此需要其他的Resource实现类。
ClassPathResource
代表classPath路径的资源，使用ClassLoader加载资源。
其主要优势就是方便访问类加载路径下的资源，尤其是Web应用，因为它可以自动搜索位于WEB-INF/classes下的资源文件。
classPath资源位于类路径中的文件系统中或jar包里，且isOpen永远返回false，表示可多次读取资源。
ClassPathResource加载资源替代了Class类和ClassLoader类的getResource(String name）和getResourceAsStream（String name）两个加载类路径资源方法，提供一致的访问方式。
ClassPathResource提供了三个构造器：
- public ClassPathResource(String path)：使用默认的ClassLoader加载Path类路径资源；
- public ClassPathResource(String path,ClassLoader classLoader)：使用指定的ClassLoader加载“Path”类路径资源；
- public ClassPathResource(String path，Class clazz)：使用指定的类加载"path"类路径资源，将加载相对于当前类的路径的资源。
FileSystemResource
代表了java.io.File资源，对于getInputStream操作将返回底层文件的字节流，isOpen将永远返回false，从而表示可以多次读取底层文件的字节流。
ServletContextResource
访问Web Context下相对路径下的资源，入参的资源位置是相对于Web应用根路径的位置(工程文件夹下，WEB-INF所在的那级文件夹)。用于简化servlet容器的ServletContext接口的getResource操作和getResourceAsStream操作。
使用ServletContextResource无需关心资源是否被解压缩出来，或者直接存放在JAR文件中，都可以通过Servlet容器访问。
接受的参数为ServletContext和字符串类型
InputStreamResource
代表java.io.InputStream字节流，对于getInputStream操作将直接返回该字节流，因此只能读取一次该字节流，即isOpen永远返回true（其他Resource大都为false可以多次读取）。
只有当没有合适Resource实现时，才考虑使用InputStreamResource。一般考虑使用ByteArrayResource。参数需要InputStream类型。
如果需要将资源描述符保存在某个地方或者需要多次读取流，不要使用。
ByteArrayResource
可以多次读取数组资源，即isOpen永远返回false
参数需要byte[]字节数组类型，用途比较广泛，可以把网络或者本地资源转换为byte[]类型，然后用ByteArrayResource转化为资源，而且不必依赖一次性使用的InputStreamResource。
ResourceLoader内容
前面我们了解到了，Spring整合获取资源的工具，就是使用Resource接口。此接口是Spring为了统一读取本地文件，类路径下面文件（ClassPath），网络等不同类型渠道的资源，封装隐藏如打开流，关闭流等大量重复模板代码，专程提供的接口类。
那么，Spring框架为了更方便的获取资源，全力弱化使用者对各个Resource接口实现类的学习与使用成本，设计目的为了快速返回（加载）Resource实例对象，定义了另一个接口，ResourceLoader接口。
结构体系
我们可以看见比较熟悉的内容：
1.ApplicationContext–上下文容器，这里说明高级容器（应用上下文容器）也是实现了ResourceLoader接口的，其本身就是一个ResourceLoader，所以说高级容器都可以根据资源地址类型快速获取对应的Resource实例。
2.资源获取策略的顶级接口–ResourceLoader接口
3.ResourcePatternResolver–扩展ResourceLoader，可以批量加载Resource对象。
源码分析
public interface ResourceLoader {
//支持ClassPath：类型的路径匹配
String CLASSPATH_URL_PREFIX = ResourceUtils.CLASSPATH_URL_PREFIX;
//根据路径信息返回一个对应的Resource资源实例
Resource getResource(String location);
//获取当前使用的ClassLoader，对外暴露，让ResourceLoader可以使用自定义的ClassLoader
@Nullable
ClassLoader getClassLoader();
}
我们可以看到，ResourceLoader接口有默认实现类——DefaultResourceLoader类
DefaultResourceLoader类实现了ResourceLoader接口加载资源的方法，同时也扩展了一些通用的基本操作方法，其中最重要的就是实现了getResource（String location）方法，我们看一下里面重要的实现方法的源码，其他不是重点，有兴趣额外了解吧：
@Override
public Resource getResource(String location) {
Assert.notNull(location, "Location must not be null");
//ProtocolResolver:用户自定义协议资源解决策略，看看用户是否有提前自定义
for (ProtocolResolver protocolResolver : getProtocolResolvers()) {
Resource resource = protocolResolver.resolve(location, this);
if (resource != null) {
return resource;
}
}
//如果用户没有自定义策略，就用以下自定义资源解析策略
//如果是“/”打头，就构造并返回ClassPathResource
if (location.startsWith("/")) {
return getResourceByPath(location);
}
//如果以“ClassPath：”打头也会构造构造并返回ClassPathResource在构造资源时还会获取类加载器
else if (location.startsWith(CLASSPATH_URL_PREFIX)) {
return new ClassPathResource(location.substring(CLASSPATH_URL_PREFIX.length()), getClassLoader());
}
//如果上述方式无法构造，则构造URL地址，并尝试通过URL进行资源定位，若没有就抛出异常
//然后判断是否为FileURL，如果是就返回FileUrlResource，否则就构造UrlResource
//若是加载的过程中抛错，委派getResourceByPath来实现资源定位和加载
else {
try {
// Try to parse the location as a URL...
URL url = new URL(location);
return (ResourceUtils.isFileURL(url) ? new FileUrlResource(url) : new UrlResource(url));
}
catch (MalformedURLException ex) {
// No URL -> resolve as resource path.
return getResourceByPath(location);
}
}
}
我们来看一下这个return的方法
protected Resource getResourceByPath(String path) {
return new ClassPathContextResource(path, getClassLoader());
}
protected static class ClassPathContextResource extends ClassPathResource implements ContextResource {
public ClassPathContextResource(String path, @Nullable ClassLoader classLoader) {
super(path, classLoader);
}
//其他代码省略
}
我们上面已经了解过了ClassPathResource（path，classLoader）使用指定的ClassLoader加载“Path”类路径资源；相信看到这里你已经明白了。
ResourcePatternResolver内容
对于ResourcePatternResolver接口来说，除了继承自Resource方法外，ResourcePatternResolver额外扩充了一个方法，就来批量加载Resource资源对象，源码如下：
public interface ResourcePatternResolver extends ResourceLoader {
//支持classpath*:形式路径匹配，即Ant风格
String CLASSPATH_ALL_URL_PREFIX = "classpath*:";
//批量加载Resource资源类型的实现
Resource[] getResources(String locationPattern) throws IOException;
}
ResourcePatternResolver接口的默认实现类——PathMatchingResourcePatternResolver类
这里全部列出没什么必要，因为PathMatchingResourcePatternResolver实例化了一个ResourceLoader，继承的ResourceLoader中方法都委托给了内部的ResourceLoader对象去处理。
对于PathMatchingResourcePatternResolver只负责实现处理ResourcePatternResolver中的方法，这里主要是实现getResources(String locationPattern)方法。
源码如下：
public class PathMatchingResourcePatternResolver implements ResourcePatternResolver {
private final ResourceLoader resourceLoader;
private PathMatcher pathMatcher = new AntPathMatcher();
public Resource[] getResources(String locationPattern) throws IOException //有点复杂，知道有这个就行，感兴趣自己查一下。
}
我们在上面可以看到，PathMatchingResourcePatternResolver引入了一个新的组件PathMatcher，
这个PathMatcher负责对基于字符串的路径和指定的模式符号进行匹配。
对于这个接口PathMatcher而言，它被翻译为路径匹配模板解析器，先用模板解析器对路径进行解析，分解成多个资源配置文件，将资源信息提供给资源加载器，后者根据不同策略将配置文件形成不同类型的资源。
容器与Resolver关系
我们从Application源码中可以看到，接口继承了ResourcePatternResolver接口，也就是说，ApplicationContext本身也是一个模板解释器和资源加载器，是模板解释器的具体实现，是支持Ant风格路径匹配和批量加载资源的一个资源加载器。
我们来好好分析一波里面的继承关系：
ApplicationContext的抽象实现类AbstractApplicationContext在实现了ConfigurableApplicationContext的基础上，同时继承了ResourceLoader的实现类DefaultResourceLoader，如下图：
我们看上图可以发现，实现ConfigurableApplicationContext也意味着实现了ResourcePatternResolver，但是为什么要继承一个DefaultResourceLoader？显然spring设计人员不想将资源解释的逻辑直接暴露在容器中，这里将解析逻辑与容器的实现进行了解耦。
在AbstractApplicationContext的构造函数源码中可以看到，在这里将ResourcePatternResolver接口的实例——PathMatchingResourcePatternResolver实例进行了初始化，并且传入的resourceLoader实例，就是容器本身（容器继承了DefaultResourceLoader），也就是容器进行了献祭，来实现资源解释器。
我们看一下源码里面内容：
public abstract class AbstractApplicationContext extends DefaultResourceLoader
implements ConfigurableApplicationContext {
/** ResourcePatternResolver used by this context. */
private ResourcePatternResolver resourcePatternResolver;
/**
* Create a new AbstractApplicationContext with no parent.
*/
public AbstractApplicationContext() {
this.resourcePatternResolver = getResourcePatternResolver();
}
protected ResourcePatternResolver getResourcePatternResolver() {
return new PathMatchingResourcePatternResolver(this);//这里传入了容器本身
}
//省略其他代码
}
最后一张图总结一下：
对于AbstractApplicationContext我们需要注意几点：
1.AbstractApplicationContext因为继承了DefaultResourceLoader，所以AbstractApplicationContext本身就是resourceLoader。
2.AbstractApplicationContext实现了ResourcePatternResolver接口：实现逻辑使用PathMatchingResourcePatternResolver进行委派，PathMatchingResourcePatternResolver实例化时需要传入resourceLoader实例，就将容器本身传进去了
3.所以容器本身即是resourceLoader实例，也是resourcePatternResolver实例。
后面有精力联动一下Resource里面涉及到的装饰模式还有在项目中的用法。