不能直接用 threading.Thread 对文件对象做并发读取,因为文件对象非线程安全,多线程共享同一文件句柄时 seek() 会互相覆盖,导致读取错位;正确做法是每个线程独占一个文件句柄并按字节分片,再通过前后扫描换行符对齐行边界。

为什么不能直接用 threading.Thread 对文件对象做并发读取?
文件对象在 Python 中不是线程安全的,多个线程同时调用同一个 file.read() 或移动 file.seek() 会互相干扰,导致读到错位、重复或缺失的数据。更关键的是,底层 OS 文件描述符共享时,seek() 是全局生效的——A 线程刚定位到偏移量 1MB,B 线程一调 seek(2MB),A 接着 read(1024) 就从 2MB 开始读了。
真正可行的思路是:**每个线程独占一个文件句柄,并提前算好各自负责的字节范围**。这要求文件必须是可随机访问的(比如普通磁盘上的文本/二进制文件),且内容无跨块边界依赖(如按行处理时需注意行断裂)。
- 先用
os.stat(file_path).st_size获取总大小 - 按线程数等分字节区间,例如 4 线程 → 每段约
total_size // 4字节 - 每个线程打开独立
open(file_path, 'rb'),seek()到起始偏移,read()指定长度 - 若需按行处理,必须在分片边界向前搜索换行符,避免把一行切两半
如何安全地按行分片,避免切割断行?
直接按字节均分会导致某一行被拆到两个线程里,后续解析出错。正确做法是在每个分片起始点向后找第一个完整行的开头,在结束点向前找最后一个完整行的结尾。
核心逻辑是:对第 i 个分片(0-indexed),计算理论起始 start = i * chunk_size,但实际读取起点要回退到该位置前最近的 \n(或文件开头);同理,理论终点 end = start + chunk_size,但实际读取终点要前进到该位置后最近的 \n(或文件末尾)。
- 用
fp.seek(max(0, start - 1))开始向后扫描找\n,确定真正起始行首 - 用
fp.seek(min(end, file_size - 1))向前扫描找\n,确定真正结束行尾 - 注意首尾分片的边界处理:第一片从 0 开始,最后一片到
file_size结束 - 若文件以
\r\n换行(Windows),需统一按\n处理,或额外判断\r\n
用 concurrent.futures.ThreadPoolExecutor 实现分片读取的最小可行代码
比起裸写 threading.Thread,ThreadPoolExecutor 更易管理生命周期和异常传播。关键在于把「打开→定位→读取→解码→处理」封装成纯函数,避免共享状态。
from concurrent.futures import ThreadPoolExecutor import os <p>def process_chunk(file_path, start, end): with open(file_path, 'rb') as f: f.seek(start) data = f.read(end - start)</p><h1>若需按行处理,这里对 data.splitlines() 做业务逻辑</h1><pre class="brush:php;toolbar:false;">return len(data) # 示例:返回字节数
def parallel_read(file_path, num_workers=4): size = os.stat(file_path).st_size chunk_size = size // num_workers futures = []
with ThreadPoolExecutor(max_workers=num_workers) as executor:
for i in range(num_workers):
s = i * chunk_size
e = s + chunk_size if i <p></p>注意:process_chunk 必须是无状态函数,所有参数显式传入;with open 确保每个线程独占句柄;executor.submit 返回 Future,方便错误捕获。
什么时候该换用 multiprocessing 而不是多线程?
纯 CPU 密集型处理(如每行做正则匹配、JSON 解析、数值计算)受 GIL 限制,多线程无法提速,此时必须用 multiprocessing.Pool 或 concurrent.futures.ProcessPoolExecutor。
- 进程间不共享内存,每个进程需重新打开文件,但可绕过 GIL
- 启动开销大,适合单次处理耗时 > 100ms 的场景
- 跨进程传递大字符串可能触发序列化瓶颈,考虑用
mmap共享内存(需额外同步) - 若文件超大(>10GB)且机器内存有限,避免一次性
read()整块,改用流式迭代处理分片内数据
分片逻辑本身不变,只是执行器换成 ProcessPoolExecutor,函数签名和文件路径传参方式一致——但要注意 Windows 下子进程无法继承父进程已打开的文件句柄,必须传路径而非文件对象。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!











