如果后端使用相同的文件，j2ee下载文件有问题吗？

Question

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

打开文件“ download.csv”（不使用File.createTempFile（字符串前缀，字符串后缀，文件目录）；但始终只是“ download.csv”），将Sql记录集中的数据行写入其中，然后使用FileUtils将该文件的内容复制到Servlet的OutputStream。

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

这是否可能导致文件包含2个用户的内容的潜在情况，这些用户具有不同的日期范围/其他过滤器并同时提交，因此JVM可同时处理请求？

目前，我们处于开发阶段，数据很少。

我知道我们可以编写自动化测试来对此进行测试，但是我想了解理论。

我建议使用Http Response的OutputStream（将它作为普通的OutputSteam传递到服务层，然后直接写入或包裹在Buffered Writer中，然后写入）。

唯一的缺点是数据写入的速度比文件副本的写入速度慢。 好像记录集中有更多数据一样，将需要一些时间来遍历它。 但是请求的总时间应该少于？ （因为写入文件输出流的时间是相同的+从文件复制到servlet输出流的时间）。

有人对此进行过测试，并且有测试用例或解决方案可以共享吗？

Answer 1

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

并发

当您编写此“相同名称”的东西时，如果您在多线程系统上工作（当今几乎所有系统都类似），可能会导致竞争 。 我已经看到一些这样的编码，这会造成很多麻烦。 结果文件不仅可以包含两个搜索的行 ，而且还可以包含合并的字符。

例子：

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

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

第一种情况：

123456789
abcdefghi

第二种情况：

1234abcd56789
efghi

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

并发

如果深入了解磁盘IO，这是一件棘手的事情。 速度可以在一个范围内变化。 在JVM中，您也可以具有blocking和non-blocking IO。 阻塞的对象可能要等到数据真正存在于磁盘上为止，而阻塞的对象会做一些“魔术”操作以稍后刷新文件。 这里有不错的读物。

TL.DR .：根据经验，最好将内容存储在内存中（如果可以容纳），而不要打扰磁盘。 如果您也为此目的使用线程内存，则也可以避免并发问题。 因此，在您的情况下，最好重写给定部分以仅利用内存并写入输出。