这篇文章主要介绍Java和IDEA中文件打包的示例分析，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！
问题：想在IDEA中引用相对路径，但是找不到文件。
当前项目的路径为：D:\source\java\test\
项目结构如下
面对无法使用相对路径找到资源文件的问题，首先想到的解决办法是先瞄一眼IDEA在执行时给Java环境设定的当前路径在哪，也就是说看看我们在使用相对路径时到底是相对于哪里的。
应该咋写呢？下面是Java API中的一些描述。
默认情况下， java.io包中的类始终会根据当前用户目录解析相对路径名。 该目录由系统属性user.dir ，通常是调用Java虚拟机的目录。
根据上面的信息，可以想到两个办法来获得当前路径，第一种办法是向Java中传递空字符串，这是一个比较hack的方法，按照相对路径来解析的话，自然会被解析成当前目录。
File f1 = new File(""); // 空字符串，相当于当前路径
System.out.println(f1.getAbsolutePath());第二种办法，直接获取系统属性中的user.dir。
System.out.println(System.getProperty("user.dir"));两种办法得到的结果一致：
也就是说，当前目录指向项目的根目录，如果你想要获取src中的一个文件的话，需要使用src/文件名，而如果该文件在某个包下的话，则需要使用src/完整包路径/文件名。
现在我在src下创建一个文件text1.txt，写入内容HELLO , WORLD
File f2 = new File("src/text1.txt");
LineNumberReader reader2 = new LineNumberReader(new FileReader(f2));
System.out.println(reader2.readLine());结果
我们的Java代码最终会被打包上传到目标平台，如某个服务器上，打包的代码应该只包含编译后的文件目录，在IDEA中就是那个out目录，其它的文件都不会出现在目标平台上，到那个时候，你不再拥有当前项目编写时的目录结构，你的程序运行时所在的当前路径也不再是现在这个。
简单来说，我们写出了依赖环境的代码，这个代码不保证程序运行在生产环境下的时候还可以正常执行，而且通常是无法正常执行。
唯一的办法，就是我们在IDEA编译时，告诉它有些文件，请你帮我打包到out目录中，然后我再想办法去out目录中找，这下就不会出问题了。
JavaAPI中有这样一个方法，它被明确说明是用来干这个事的就是ClassLoader中的getResource，下面是API中的说明
寻找给定名字的资源文件。一个资源文件可以是一些能够被class代码以一种独立于代码位置的方式进行访问的数据（图像、声音、文字等）
我们先看看使用这个方法是相对于哪个路径，采用的办法和new File("")大同小异。
String path = Main.class.getClassLoader().getResource("").getPath();
System.out.println(path);结果如下
它已经找到了我们打包后的二进制代码所在的位置，这下就可以相对于二进制代码的位置读写文件了，不再依赖当前环境。
注意，ClassLoader.getResourceAsStream和Class.getResourceAsStream有些细微的区别，见JAVA 笔记 ClassLoader.getResourceAsStream() 与 Class.getResourceAsStream()的区别
将文件打包到二进制代码位置
创建文件夹，mark directory as -> Resources Root。
o
在其中创建text2.txt，写入HELLO , RESOURCES。
然后这样去读
LineNumberReader r3 = new LineNumberReader(
new InputStreamReader(Main.class.getClassLoader().getResourceAsStream("text2.txt"))
);
System.out.println(r3.readLine());这里使用了ClassLoader.getResource的一个变体getResourceAsStream，它的作用就是返回的是一个流，而非URL。我们所做的就是获取当前类的ClassLoader，通过它获取资源文件，转换成LineNumberReader。
读取成功，也就是说，在resources文件夹下的文件，IDEA会自动帮我们打包到二进制代码的位置
src中的文件
如果我们去看out文件夹下的文件结构，你就会发现，除了resources/text2.txt，我们之前在src下创建的text1.txt也被打包到这个位置了。也就是说，我们可以通过同样的方式去读取src下的文件。
D:\source\java\test\out>wsl tree .
.
└── production
└── test
├── io
│ └── lilpig
│ └── test
│ └── Main.class
├── text1.txt
└── text2.txt
5 directories, 3 files
LineNumberReader r4 = new LineNumberReader(
new InputStreamReader(Main.class.getClassLoader().getResourceAsStream("text1.txt"))
);
System.out.println(r4.readLine());读取成功
Thread.currentThread.getContextClassLoader
在多线程应用中，有可能你编写的类的类加载器和实际加载resources文件夹的类加载器不是同一个，这会导致你的代码无法获取到资源文件，使用Thread.currentThread.getContextClassLoader能规避这个问题。具体的原理涉及到Java中的类加载机制的委托模型，这部分的内容原理性太强，我已经忘得差不多了，就不露怯了。
我们编写的大部分后端应用，都是多线程应用，我们自己感知不到，那是因为多线程代码被封装在框架中，所以无论如何，使用Thread.currentThread.getContextClassLoader总比使用Main.class.getClassLoader更好。
并且，Thread.currentThread.getContextClassLoader更加具有一致性，你可以轻易的编写一个工具方法来简化代码（无论如何Thread.currentThread返回的总是当前调用者所在的线程）。而如果用之前的方法，每一个类的类名都不同，你在一个类中写的是Main.class.getClassLoader在另一个类中写的又是Other.class.getClassLoader，这不一致的代码会让我们难以编写一个通用的工具类。
在框架中，资源文件夹都是默认被创建好的，有的可能叫static，有的可能叫resources......而且，有可能编译后的目录不是out，而是target，甚至会被打包成war包等。
我们要做的不是管它打包后在哪，而是直接往框架给你指定好的资源文件夹里面放文件就行，剩下的交给框架。
并且在框架中，随处可见Thread.currentThread.getClassLoader().getResource...这样的代码。
以上是“Java和IDEA中文件打包的示例分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注亿速云行业资讯频道！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
