我收集了 1000 个 gz 格式的文件。我想并行处理它们,比如每轮 8 个。当我让每个线程打开一个文件并从磁盘读取时,由于许多进程试图从不同的位置读取而导致显着延迟。
我只是想知道是否有一种有效的方法来处理多个文件读取?或者我应该先将所有文件缓冲到内存中(例如所有 8 个文件,然后将缓冲区交给线程)。如果是这样,缓冲文件的最佳方式是什么?缓冲区数组?或一些替代结构?
谢谢你。
我收集了 1000 个 gz 格式的文件。我想并行处理它们,比如每轮 8 个。当我让每个线程打开一个文件并从磁盘读取时,由于许多进程试图从不同的位置读取而导致显着延迟。
我只是想知道是否有一种有效的方法来处理多个文件读取?或者我应该先将所有文件缓冲到内存中(例如所有 8 个文件,然后将缓冲区交给线程)。如果是这样,缓冲文件的最佳方式是什么?缓冲区数组?或一些替代结构?
谢谢你。
我怀疑你用 1000 个线程淹没了你的进程。线程不是特别轻量级的(例如,默认情况下每个线程会占用 512k 的堆栈空间)。
更有效的模型可能是使用线程池(通过ThreadPoolExecutor)并将其调整为系统上同时线程的最佳数量(例如,您在上面建议了 8 个 - 我建议这在某种程度上取决于您拥有的免费 CPU)。
每个.gz
文件将由一个Callable
提交给执行程序的文件表示,执行程序将同时运行多个作业。
如果您使用 8 个固定大小的池(因为您有 8 个内核),您可能会发现这是相当有效的,因为解压缩文件是 cpu 密集型的。
但是,您可能会发现这并不比使用 4 个线程或仅 2 个线程快,因为真正的瓶颈是从磁盘读取数据。如果是这种情况,您唯一能做的就是获得更快的磁盘。例如镜像磁盘,或使用速度快 20 倍的 SSD。