不能直接用 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（或文件末尾）。
立即学习“Python免费学习笔记（深入）”；
SkillSub Pro - Python 题解与代码注释双功能技能功能概述SkillSub Pro - Python 题解与代码注释双功能技能是一项面向实际任务的技能，主要用于SkillSub Pro 是一个 Python 题解生成与代码注释的 双功能合体技能 ，专为学生、算法学习者和开发者设计；✅ 一个技能，两种用途 ：；核心要点📝 题解模式 ：输入题目/题号，自动生成完整 Python 题解（含详细注释、解题思路、复杂度分析）；💬 注释模式 ：输入 Python 代码，自动添加详细中。它将相关步骤、
- 用
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 < num_workers - 1 else size
# 这里应插入「调整 s/e 对齐行边界」的逻辑（见上一节）
futures.append(executor.submit(process_chunk, file_path, s, e))
results = [f.result() for f in futures]
return results
注意：process_chunk 必须是无状态函数，所有参数显式传入；with open 确保每个线程独占句柄；executor.submit 返回 Future，方便错误捕获。
什么时候该换用 multiprocessing 而不是多线程？
纯 CPU 密集型处理（如每行做正则匹配、JSON 解析、数值计算）受 GIL 限制，多线程无法提速，此时必须用 multiprocessing.Pool 或 concurrent.futures.ProcessPoolExecutor。
- 进程间不共享内存，每个进程需重新打开文件，但可绕过 GIL
- 启动开销大，适合单次处理耗时 > 100ms 的场景
- 跨进程传递大字符串可能触发序列化瓶颈，考虑用
mmap共享内存（需额外同步） - 若文件超大（>10GB）且机器内存有限，避免一次性
read()整块，改用流式迭代处理分片内数据
分片逻辑本身不变，只是执行器换成 ProcessPoolExecutor，函数签名和文件路径传参方式一致——但要注意 Windows 下子进程无法继承父进程已打开的文件句柄，必须传路径而非文件对象。
