多文件描述符与频繁seek：哪种文件访问方案性能更优？

针对你要维护10个独立位置的同一文件读取流的场景，两种方案的性能和资源权衡分平台来看：

资源占用前提 #

首先明确：10个文件描述符（或Windows句柄）的资源占用完全可以忽略。Linux默认进程fd限制是1024，Windows的进程句柄限制更是远高于这个数，所以不用纠结资源过载的问题。

Linux平台 #

多文件描述符方案 #

每个fd对应内核中独立的文件表项，包含自己的位置指针，但页缓存是全局共享的（同一个文件的所有fd共用内核的页缓存）。

• 核心优势：不需要频繁调用seek()（系统调用），切换读取流时直接读就行。尤其是当你需要在不同流的位置之间频繁跳转时，省去了每次切换的系统调用开销，还能保留内核的预读策略——内核会根据当前fd的读取顺序预读后续数据，不会因为频繁seek打乱预读逻辑，预读命中率更高，磁盘IO效率更好。

单文件seek方案 #

所有流共享同一个fd，每次切换流都要先调用seek()跳到目标位置，再读取。

• 劣势：每次seek都是一次系统调用，会带来上下文切换开销；如果频繁跳转不同位置，内核的预读机制会失效（预读的块和当前读取位置不匹配），导致更多的磁盘IO等待，性能下降明显。

Windows平台 #

多文件句柄方案 #

Windows的文件句柄同样支持独立的文件指针，系统缓存也是基于文件全局共享的。

• 优势：和Linux类似，省去了频繁调用SetFilePointer()（对应seek）的系统调用开销，同时能维持预读机制的效率。10个句柄的资源消耗完全在系统承受范围内。

单文件seek方案 #

每次切换流都要调用SetFilePointer()调整位置，同样存在系统调用开销；频繁的位置跳转同样会破坏Windows的预读策略，导致缓存命中率降低，IO性能下降。

Python层面的表现 #

Python的open()底层直接调用系统API，所以行为和系统层面完全一致：

• 多文件描述符：每次open()生成新的fd，Python的文件对象（如io.BufferedReader）维护独立的位置指针，读取时无需额外seek，直接操作即可。
• 单文件seek：需要自己维护每个流的位置值，每次读取前手动调用file.seek(pos)，这一步会触发系统调用，带来相应的开销。

最终结论 #

• 如果你的解析器需要频繁在不同流之间切换读取，或者每个流的读取位置跨度较大，多文件描述符方案性能更优——微小的资源占用换来的是更低的系统调用开销和更高的缓存命中率，IO密集场景下优势明显。
• 如果读取操作是长时间专注单个流、极少切换，两种方案差异不大，单文件seek的资源占用略低，但优势可以忽略。
• 从通用解析器的场景来看，多文件描述符是更稳妥的选择，性能表现更稳定。

内容的提问来源于stack exchange，提问作者Seva Alekseyev