同时应该访问文件系统的线程有多少？

Question

我们在应用程序中有一个模块，它将数据存储在多个文件和多级目录中，并从多个线程(读和写)访问它们。目录结构基于拆分的散列值，如下所示：

b1/94/6a/92/a.txt
b1/94/6a/ee/a.txt
a1/0e/db/bb/b.txt
...

如果调用方删除文件，则模块将立即删除空目录。

模块的并发级别应该是多少？是否值得同时从多个线程中创建和删除文件夹？文件系统能够有效地处理这些问题吗？

是否值得使用多线程模块？(编写一个单线程的线程要容易得多。)

(该应用程序是用Java编写的，主要运行在Windows、NTFS和非SSD上，但如果存在差异，我也对其他操作和文件系统感兴趣。)

Answer 1

当然，任何操作系统都会处理多个请求，但即便如此，当您要求一个基于物理媒体的文件系统同时执行不止一件事情时，您的性能就会越来越差。根据我的经验，在性能方面，最好只有一个线程排队等待您的请求，然后按顺序将它们交给操作系统。

一种选择是，该线程分离解除链接操作，并保存这些操作，直到它检测到很少发生数据操作时出现空闲时间为止，然后删除这些目录，以尽可能快地保持数据请求，并避免妨碍您的内部管理。

这显然是一个简单的解决方案，但我认为在其他需求强制进行优化或重组之前，简单是好的。

Answer 2

您应该分析一下您的应用程序，以确定。取决于你如何使用你的文件，它可能是坏的或非常好的。如果您只对少数几个文件进行读写，这些文件将被缓存，它们的块将被缓冲。它可能会在一段时间内不接触磁盘。

如果您创建了大量的文件和目录，并以创建它们的速度删除它们，那么您肯定会破坏缓存和缓冲区。不管有多少线程在做。

如果您有更多的进程(而不是线程)，您将获得更多的文件系统时间。

拥有一个线程来收集文件，读/写来自其他线程的请求只是重复了操作系统的工作，通常OS可以调度和重新排序这些请求，而不是您想要花费的时间。

Answer 3

嗯，我不知道您在这里试图做什么，但是您确定使用数据库而不是直接访问文件系统不会更好地满足您的需求。数据库将为您处理多个并发请求，并帮助防范竞争条件。