java - 如果后端使用相同的文件，j2ee 下载文件会出现问题吗？

Question

Webapp 在我的项目中提供基于最终用户搜索的下载 CSV 文件功能，正在执行以下操作:

打开一个文件“download.csv”(不使用 File.createTempFile(String prefix,字符串后缀、文件目录)；但始终只是“download.csv”)，将 Sql 记录集中的数据行写入其中，然后使用 FileUtils 将该文件的内容复制到 servlet 的 OutputStream。

记录集基于搜索条件，例如 1 月 1 日到 3 月 30 日。

这是否会导致文件包含 2 个用户的内容，他们创建不同的日期范围/其他过滤器并同时提交，以便 JVM 同时处理请求？

现在我们处于开发阶段，数据很少。

我知道我们可以编写自动化测试来测试这一点，但想了解理论。

我建议使用 Http Response 的 OutputStream(将其作为普通 OutputSteam 传递到服务层并直接写入该文件或包装在 Buffered Writer 中然后写入)。

唯一的缺点是数据写入速度比文件复制慢。就好像记录集中有更多数据一样，迭代它需要时间。但请求的总时间应该更少吧？ (因为写入文件输出流的时间将与从文件复制到 servlet 输出流的时间相同)。

有人对此做过测试并有测试用例或解决方案可以分享吗？

Answer 1

如果您真的想深入了解这两个部分，那么这是一个棘手的问题。

并发

正如您所写，如果您正在多线程系统上工作(现在几乎所有系统都是这样)，那么“同名”的事情可能会导致 race condition 。我见过一些这样的编码，它可能会引起很多麻烦。结果文件不仅可以包含两次搜索的行，还可以包含合并的字符。

示例:

Thread 1 wants to write: 123456789\n
Thread 2 wants to write: abcdefghi\n

输出可能会以上述方式有所不同:

第一种情况:

123456789
abcdefghi

第二种情况:

1234abcd56789
efghi

我肯定会至少使用唯一的(UUID.randomUUID())名称来“热修复”问题。

并发

如果深入的话，磁盘 IO 是一件棘手的事情。速度可能会在很大范围内变化。在 JVM 中，您也可以拥有阻塞 IO 和非阻塞 IO。阻塞的一方可以等到数据真正位于磁盘上，而另一方将执行一些“魔术”以稍后刷新文件。 here. 中有一篇很好的文章

TL.DR.:根据经验，最好将内容保存在内存中(如果可以容纳)，而不用担心磁盘。如果您也将线程内存用于此目的，您也可以避免并发问题。因此，在您的情况下，最好重写给定部分以仅利用内存并写入输出。