V2AS问路
jar\war\SpringBoot加载包内外资源的方式，告别FileNotFoundException吧
阅读原文时间：2023年07月12日阅读：1

工作中常常会用到文件加载，然后又经常忘记，印象不深，没有系统性研究过，从最初的war包项目到现在的springboot项目，从加载外部文件到加载自身jar包内文件，也发生了许多变化，这里开一贴，作为自己的备忘录，也希望能给广大 java

coder 带来帮助。

一、目标

通过此文，能熟知普通war包项目目录内、jar包自身内文件的加载方式。

二、文件定位

为什么先说war包项目，war包项目部署到Web容器里后 ，会被解压，所以文件读取方式，和在ide里面读取是类似的。

读取文件，首先要定位文件，定位到文件之后才能读取。

定位文件，java常用的有两种，分别是

  • URL Class.getResource(String name)
  • URL ClassLoader.getResource(String name)

这里的参数 name ，就是咱们认为的路径，官方对这个参数名的描述是：

name of the desired resource

渴望得到的资源的名字

URL 则是资源的定位，可以得到资源所在路径。

URL 可以是不同的资源，通过其字段 protocol 来区分是哪种类型资源，取值有：

  • ftp
  • nntp
  • http
  • file
  • jar

感兴趣的同学可以自行了解 URL 的定义

2.1.1 Class.getResource(String name)

通过class实例获得资源的定位，传入参数有如下查找方式：

  • 以 / 开头，则从 classPath 即运行的 class 文件所在的项目的 ***/classes/ 目录下找起
  • 非以 / 开头的，则从当前class所在路径下找起

验证：

先上项目结构图

验证代码

public class ClassResource {
    public static void main(String[] args) {
        ClassResource classResource = new ClassResource();
        classResource.resWithInstance("");
        classResource.resWithInstance("/");
        classResource.resWithInstance("ClassResource.class");
        classResource.resWithInstance("/ClassResource.class");
        classResource.resWithInstance("/1.txt");
    }

    public void resWithInstance(String path) {
        URL resource = this.getClass().getResource(path);
        print(resource, path);
    }

    private static void print(URL resource, String path) {
        try {
            System.out.println("ClassResource 根据目录[" + String.format("%-20s", path) + "] 获取路径为 " + resource);
        } catch (Exception e) {
            System.out.println("ClassResource 根据目录[" + path + "] 获取路径出错，错误原因：" + e.getMessage());
        }
    }

}

我们传入了5个参数，分别是

  • 空字符串
  • /
  • 当前类文件名
  • / + 当前类文件名
  • / + 项目 resources 目录下的 1.txt 文件

运行结果如下：

结果分析：

  1. 空字符串

    定位为当前类路径

  2. /

    定位为 classPath 路径

  3. 当前类文件名

    定位为当前类文件所在路径，成功定位到文件

  4. / + 当前类文件名

    定位不到文件

  5. / + 项目 resources 目录下的 1.txt 文件

    定位为 resoures/1.txt，因为编译后 resources 目录里的文件都移动到了 classPath 路径下，所以也成功定位

4 的错误原因很明显，因为 classPath 路径下没有名叫 ClassResource.class 的文件，所以定位不到

总结：

使用 class 查找文件，以 / 开头的文件名，是从 classPath 目录下找，否则从当前类文件目录下找

2.1.2 ClassLoader.getResource(String name)

通过 classLoader 实例获得资源的定位，传入参数仅有如下查找方式：

  • 从 classPath 路径下找起

验证：

验证代码

public class ClassLoaderResource {

    public static void main(String[] args) {
        ClassLoaderResource classLoaderResource = new ClassLoaderResource();
        classLoaderResource.resWithInstance("");
        classLoaderResource.resWithInstance("/");
        classLoaderResource.resWithInstance("ClassLoaderResource.class");
        classLoaderResource.resWithInstance("/ClassLoaderResource.class");
        classLoaderResource.resWithInstance("1.txt");
        classLoaderResource.resWithInstance("/1.txt");
    }

    public void resWithInstance(String path) {
        URL resource = this.getClass().getClassLoader().getResource(path);
        print(resource, path);
    }

    private static void print(URL resource, String path) {
        try {
            System.out.println("ClassLoaderResource 根据目录[" + String.format("%-26s", path) + "] 获取路径为" + resource);
        } catch (Exception e) {
            System.out.println("ClassLoaderResource 根据目录[" + path + "]获取路径出错，错误原因：" + e.getMessage());
        }
    }
}

我们传入了6个参数，分别是

  • 空字符串
  • /
  • 当前类文件名
  • / + 当前类文件名
  • 1.txt
  • /1.txt

运行结果如下：

结果分析：

  1. 空字符串

    定位为 classPath 路径

  2. /

    定位不到

  3. 当前类文件名

    定位不到

  4. / + 当前类文件名

    定位不到

  5. resources目录下的 1.txt 文件名

    定位为 resoures/1.txt，因为编译后 resources 目录里的文件都移动到了 classPath 路径下，成功定位

  6. / + resources目录下的 1.txt 文件名

    定位不到

3 的错误原因很明显，因为 classPath 路径下没有名叫 ClassResource.class 的文件，所以定位不到

2、4、6 的错误原因是因为以 / 开头，这里先记着:

以 / 开头的都会定位不到，但是参数中可以带有 / 来表示下一级路径

如：查找 Main.class 的参数此处应写为 com/yx/jtest/Main.class

总结：

使用 classLoader 查找文件，总是从 classPath 目录下找起，且不能以 / 开头

2.1.3 Class.getResource 与 ClassLoader.getResource 的异同原因

对于相同的开头字符 / 、空字符串 为什么两种方式的执行结果不一样呢

来分析下 class.getResource 源码

public class Class {
    public java.net.URL getResource(String name) {
        name = resolveName(name); // ①
        ClassLoader cl = getClassLoader0();
        if (cl == null) {
            // A system class.
            return ClassLoader.getSystemResource(name);
        }
        return cl.getResource(name);
    }
}

可以看到在进行 ① 转换资源名称后，内部还是调用了 classLoader.getResource 方法。

那么异同的奥秘就都在这个第一行里的 resolveName(name) 方法里了

来看 resolveName(name)

public class Class {
    /**
     * Add a package name prefix if the name is not absolute Remove leading "/"
     * if name is absolute
     */
    private String resolveName(String name) {
        if (name == null) {
            return name;
        }
        if (!name.startsWith("/")) {
            Class<?> c = this;
            while (c.isArray()) {
                c = c.getComponentType();
            }

            // 这里的baseName类似 com.foo.Bar 之类的形式
            String baseName = c.getName();
            int index = baseName.lastIndexOf('.');
            if (index != -1) {

                // 拼name，把包名称拼上，如 "com/foo/" + "/" + "Bar1"
                // 就是获取当前类目录下的路径名
                name = baseName.substring(0, index).replace('.', '/')
                        + "/" + name;
            }
        } else {
            name = name.substring(1);
        }
        return name;
    }
}

可以看到：

  1. 如果不以 / 开头，就返回 当前类所在目录 + 资源名
  2. 否则返回 / 后面的字符串
  3. 总结就是该方法把相对路径转换为了基于 classPath 的绝对路径

在经过资源名称处理后，就跟 classLoader.getResource 的规则一样了。

这里处理 / 符号也间接说明了 classLoader.getResource 不再接受 / 开头的资源名称，因为它把 / 当成了路径分隔符，下面是官方的参数说明

The name of a resource is a '/'-separated path name that identifies the resource.

资源的名称是一个“/”分隔的路径名，用于标识资源。

所以两者的异同点在于：

class.getResource 先进行了 / 符号开头的路径的预处理，使之转换为了基于 classPath 的绝对路径，再调用 classLoader.getResource 的方法

而 classLoader.getResource 只接受基于 classPath 的绝对路径，并不再接受以 /开头的路径，此时 "" 空字符串则代表 classPath 路径，而非 class.getResource 的 /

当项目为jar项目时，加载的方式变了，主要有

  1. classPath 路径由 file 目录变成了 jar文件，这影响到资源的定位方式，而且不再支持获取当前 classPath 路径
  2. URLClassPath 加载资源时候由 FileLoader 变成了 JarLoader，这影响到资源对特殊符号的处理方式
  3. 定位内部文件的URL协议由 file 变成了 jar，这影响到资源文件的读取方式

先来看打包成jar后的运行情况，这次使用另外一个类去写测试，该类直接调用上面的演示方法

代码：

public class Main {
    public static void main(String[] args) {
        ClassResource classResource = new ClassResource();
        classResource.resWithInstance("");
        classResource.resWithInstance("/");
        classResource.resWithInstance("ClassResource.class");
        classResource.resWithInstance("/ClassResource.class");
        classResource.resWithInstance("1.txt");
        classResource.resWithInstance("/1.txt");

        ClassLoaderResource classLoaderResource = new ClassLoaderResource();
        classLoaderResource.resWithInstance("");
        classLoaderResource.resWithInstance("/");
        classLoaderResource.resWithInstance("ClassResource.class");
        classLoaderResource.resWithInstance("/ClassResource.class");
        classLoaderResource.resWithInstance("1.txt");
        classLoaderResource.resWithInstance("/1.txt");
    }
}

运行结果：

分析：

class.getResource()

classLoader.getResource()

其他

三、文件加载

上一章节，我们已经知道了 class 与 classLoader 定位资源的异同，和在打成 jar 包之后的变化。

现在定位文件已经做到了，这里不再区分究竟是 class 定位的文件还是classLoader 定位的文件，本章节就使用 class 去定位文件如何加载我们定位到的文件呢？

因为 WAR 项目会被解压成为具体的文件（Tomcat），所以这里我们用传统的 File 描述一个对象，并读取即可。

public class ClassResource {
    public static void main(String[] args) {
        readFile("/1.txt");
    }

    public static void readFile(String path) {
        //1.定位资源
        URL resource = ClassResource.class.getResource(path);
        System.out.println("[getResource        ] 读取文件：" + resource);
        if (null == resource) {
            System.out.println("找不到资源文件");
            return;
        }

        //2.映射资源
        File file = new File(resource.getPath());
        InputStream inputStream = null;
        try {
            inputStream = new FileInputStream(file);
            //3.读取资源
            read(inputStream);
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            if (null != inputStream) {
                try {
                    inputStream.close();
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }
    }

    private static void read(InputStream resource) throws IOException {
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        int i;
        while ((i = resource.read()) != -1) {
            baos.write(i);
        }
        System.out.println(new String(baos.toByteArray(), StandardCharsets.UTF_8));
    }
}

执行结果：

可以看到能正常读取，这里不再叙述。

我们首先将上述方法打到 jar 包里面去运行，看一下效果

import com.yx.jtest.loadfile.ClassLoaderResource;
import com.yx.jtest.loadfile.ClassResource;

public class Main {

    public static void main(String[] args) {

        System.out.println("#############打包后ClassResource开始读取文件############");
        ClassResource.readFile("/1.txt");
    }
}

执行结果：

可以看到，读取失败了：FileNotFoundException ，到这里，大家可以思考下，为什么文件读取不到了？

3.2.1 为什么路径是 jar: 开头

注意看红框部分输出的文件 URL，这个 URL 不再是以 file: 开头的了。这里先标记下，我们来跟踪下 classLoader.getResource() 的方法，来找到为什么是 jar: 开头。不感兴趣的同学可以跳过这部分

public class ClassLoader {
    //...

    public URL getResource(String name) {
        URL url;
        if (parent != null) {
            url = parent.getResource(name);
        } else {
            url = getBootstrapResource(name);
        }
        if (url == null) {
            url = findResource(name);
        }
        return url;
    }
}

熟悉的双亲委任模型，这里不多说，介绍下 ClassLoader 这个类和 Java 的类加载器

从Java虚拟机的角度来讲，只存在两种不同的类加载器：

一种是启动类加载器 （Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；

另一种就是所有其他的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并且 全都继承自抽象类java.lang.ClassLoader。

摘自：《深入理解Java虚拟机-JVM高级特性与最佳实践》

其中启动类加载器和其他类加载器的关系，如下图所示：

到这里，我们能知道上述代码的 ClassLoader 实例的 parent 变量都是谁了，这里揭示下：

jar 启动调用的类加载器为 AppClassLoader，其 parent 为 ExtClassLoader，而 ExtClassLoader 的父加载器就是启动类加载器了

其中：

  • 启动类加载器 默认加载 /lib 目录下的能被虚拟机正确识别的类库
  • 扩展加载器 默认加载 /lib/ext 目录下的类库 可以看到，这两个都不是用来加载我们指定的文件的，加载 1.txt 只能是 AppClassLoader 的工作了。

因为父类加载器得到的 url 均为null，所以方法执行到 findResource(name) 这一行

AppClassLoader 本身没有这个方法的实现类，这里追踪到其父类 URLClassLoader 的实现

public class URLClassLoader {
    //...

    public URL findResource(final String name) {
        /*
         * 忽略这个方法，可以看到是交个成员变量 ucp 去找资源了
         */
        URL url = AccessController.doPrivileged(
                new PrivilegedAction<URL>() {
                    public URL run() {
                        //交给 ucp 寻找
                        return ucp.findResource(name, true);
                    }
                }, acc);

        return url != null ? ucp.checkURL(url) : null;
    }
}

这里的 ucp 变量，是个 URLClassPath 实例，继续往下追

public class URLClassPath {
    //...

    public URL findResource(String var1, boolean var2) {
        int[] var4 = this.getLookupCache(var1);

        URLClassPath.Loader var3; //找到对应的Loader
        for (int var5 = 0; (var3 = this.getNextLoader(var4, var5)) != null; ++var5) {
            //让Loader去找资源
            URL var6 = var3.findResource(var1, var2);
            if (var6 != null) {
                //找到资源并返回
                return var6;
            }
        }

        return null;
    }
}

通过注释可以看到最终是通过 URLClassPath 的内部类 Loader 去定位的资源

这里介绍下 Loader 的两个实现类

  • JarLoader
  • FileLoader

到这里就不再往下追踪了，需要知道的是，打成Jar包后，文件的定位靠 JarLoader 来了

 private static class Loader implements Closeable {

    private final URL base;

    Loader(URL var1) {
        this.base = var1;
    }
}

static class JarLoader extends Loader {

    private final URL csu;

    JarLoader(URL var1, URLStreamHandler var2, HashMap<String, URLClassPath.Loader> var3, AccessControlContext var4) throws IOException {
        //这里设置 base url 的协议为 jar:
        super(new URL("jar", "", -1, var1 + "!/", var2));
        //..
    }

    //1
    URL findResource(String var1, boolean var2) {
        //先获取resource, 找到 resource 获得其资源定位符 URL
        Resource var3 = this.getResource(var1, var2);

        //返回 文件 url 给我们写的代码
        //返回 文件 url 给我们写的代码
        //返回 文件 url 给我们写的代码
        return var3 != null ? var3.getURL() : null;
    }

    //2
    Resource getResource(String var1, boolean var2) {
        //省略部分代码
        //其他不看，看这里，checkResource后会返回resource
        return this.checkResource(var1, var2, var3);

    }

    //3
    Resource checkResource(final String var1, boolean var2, final JarEntry var3) {
        final URL var4;

        //..

        //获取初始化时候设置的 base url ，其协议为 jar，并重新封装目标 url，然后赋值给下面的 Resource 实例
        var4 = new URL(this.getBaseURL(), ParseUtil.encodePath(var1, false));

        //..

        //返回资源
        return new Resource() {

            public URL getURL() {
                //上述的封装的目标 url
                return var4;
            }
            // ..
        };
    }
}

所以我们获取到的资源定位就是以 jar: 开头的了

3.2.2 打 jar 包后，jar 包内资源为什么不能读取了

显而易见，对于 File 类来说，单个的 jar 文件，既是一个 File, 那么，再通过一个 File 去描述一个文件内部的 File 是不太合适的。

这有点像压缩文件一样：你不能直接操作压缩包内的文件。

那么，该如何快速方便地读取 jar 包内我们想要操作的文件（证书、固定配置）呢？

3.2.3 打 jar 包后，jar 包内资源该怎么读取

答案是，用流的形式，只要稍微改写就可以了，请看如下demo

public class ClassResource{

    //以流的形式读取文件
    public static void readFileByStream(String path) {
        System.out.println("[getResourceAsStream] 读取文件：" + path);
        InputStream inputStream = null;
        try {
            //获得jar包内的文件的流
            inputStream = ClassResource.class.getResourceAsStream(path);
            read(inputStream);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    //输出文件内容
    private static void read(InputStream resource) throws IOException {
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        int i;
        while ((i = resource.read()) != -1) {
            baos.write(i);
        }
        System.out.println(new String(baos.toByteArray(), StandardCharsets.UTF_8));
    }

}

//jar 启动类
public class Main {

    public static void main(String[] args) {
        System.out.println("#############打包后ClassResource开始读取文件############");
        //注意这里的文件名，因为仍然是使用 Class.getResourceXxxx()，所以文件名解析路径方式仍然不变
        //跟上述章节保持一致
        ClassResource.readFileByStream("/1.txt");
    }
}

输出结果:

可以看到，是能够正常读取 jar 内部文件的内容的

3.2.4 jar 包内资源的其他读取方法

也可以使用 JarFile 的形式去读取 jar 包内的资源，这种适合读取别的 jar 包内的资源，这里就不再介绍，感兴趣的同学可以自行百度。

Spring boot 项目打包后不同于普通的 jar 包目录结构

执行原有jar读取方式代码

@SpringBootApplication
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
        readFileByStream("/1.txt");
    }
 //以流的形式读取文件
    public static void readFileByStream(String path) {
        System.out.println("[getResourceAsStream] 读取文件：" + path);
        InputStream inputStream = null;
        try {
            //获得jar包内的文件的流
            inputStream = ClassResource.class.getResourceAsStream(path);
            read(inputStream);
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    //输出文件内容
    private static void read(InputStream resource) throws IOException {
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        int i;
        while ((i = resource.read()) != -1) {
            baos.write(i);
        }
        System.out.println(new String(baos.toByteArray(), StandardCharsets.UTF_8));
    }
}

输出结果：

可以看到，即使目录结构变了，Springboot jar 包也能正常读取到文件内容，这是因为，Spring boot 把如下两个目录添加到了 classPath 当中

  • BOOT-INF/classes
  • BOOT-INF/lib

Spring boot 额外提供了一种新的 jar 包内部的资源读取方式，即 ClassPathResource

@SpringBootApplication
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
        //使用SpringBoot的方式读取资源文件，这里不再以 ‘/’ 开头，类似ClassLoader加载资源的name写法
        ClassPathResource classPathResource = new ClassPathResource("1.txt");
        try {
            read(classPathResource.getInputStream());
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    private static void read(InputStream resource) throws IOException {
        ByteArrayOutputStream baos = new ByteArrayOutputStream();
        int i;
        while ((i = resource.read()) != -1) {
            baos.write(i);
        }
        System.out.println(new String(baos.toByteArray(), StandardCharsets.UTF_8));
    }
}

执行结果：

四、总结

现今微服务大行其道，读取项目内的资源文件也常常在 SpringBoot jar中出现问题，这里使用 ClassPathResource 和 class.getResourceAsStream()均可。

但是在企业提供高质量服务的目标下，应当把这些额外读取资源的需求，迁移到可配置化的环境当中，这样就能避免因改动配置引起的服务启停和中断。

本人才疏学浅，人微技轻，如有不妥之处，请留下宝贵批评指正。

手机扫一扫

移动阅读更方便

阿里云服务器
腾讯云服务器
七牛云服务器

你可能感兴趣的文章

Struts2之环境配置
Cloudera Manager 5.9 和 CDH 5.9 离线安装指南及个人采坑填坑记
第五章 springboot + mybatis(转载)

4

log4j2同步日志引发的性能问题

5

hadoop集群搭建及编程实践

6

精选版：用Java扩展Nginx（nginx-clojure 入门）

7

初识Storm之HelloWorld程序源码

8

搭建Minio分布式服务

9

CDC一键入湖：当 Apache Hudi DeltaStreamer 遇见 Serverless Spark