多线程读取海量小文件需避免资源争抢、绕过GIL、匹配I/O密集型特性；直接用threading.Thread逐个读反而更慢，因系统调用频繁、调度开销大、文件描述符竞争及Windows句柄锁等问题。
多线程对海量小文件读取有加速效果，但不是“开个线程就快”——关键在避免资源争抢、绕过GIL限制、匹配I/O密集型特性。
为什么直接用 threading.Thread 逐个读文件反而更慢？
常见错误是为每个小文件新建一个 threading.Thread 实例并调用 open().read()。这会触发大量重复的系统调用（open、stat、close），线程调度开销压倒I/O收益；尤其在Linux上，进程内文件描述符表竞争也会拖慢速度。
- 单个线程读1000个小文件耗时 ≈ 1.2s，10个线程并发读同样1000个文件可能耗时 ≈ 1.8s（非线性增长）
- Windows下还容易触发
PermissionError: [WinError 32]—— 多个线程同时打开同一路径的文件句柄被锁 - 所有线程共享GIL，纯计算类预处理（如JSON解析）不会因线程数增加而提速
用 concurrent.futures.ThreadPoolExecutor 控制并发度
比裸写 threading.Thread 更安全，能复用线程、限制最大并发数、统一异常捕获。对小文件I/O，建议 max_workers 设为 min(32, os.cpu_count() * 4) —— 太小压不住I/O等待，太大引发调度抖动。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 必须用
with包裹ThreadPoolExecutor，否则线程池不自动 shutdown，可能卡住主进程 - 不要在
submit的函数里做耗时解析（如json.loads），应只做open().read()，后续解析放主线程批量处理 - 示例片段：
from concurrent.futures import ThreadPoolExecutor import os <p>def read_one_file(path): try: with open(path, 'rb') as f: # 二进制模式省去解码开销 return f.read() except (OSError, FileNotFoundError): return None</p><p>file_list = ['log_0001.bin', 'log_0002.bin', ...] with ThreadPoolExecutor(max_workers=16) as executor: results = list(executor.map(read_one_file, file_list))
真正有效的加速组合：线程池 + 预读提示 + 缓存
单纯靠多线程无法突破磁盘随机寻道瓶颈。需叠加内核级优化和内存复用：
立即学习“Python免费学习笔记（深入）”；
- 在
open()后、read()前加os.posix_fadvise(fd, 0, 0, os.POSIX_FADV_WILLNEED)（Linux/macOS），通知内核预加载整个文件页 —— 对顺序读小文件提升明显 - 对热文件（如配置、模板）加
@lru_cache(maxsize=128)，避免重复磁盘访问 - 若小文件内容高度重复（如日志头、固定元数据），先用
mmap.ACCESS_READ映射单个样本文件，再用mm.find()快速定位偏移，比反复open省90%以上系统调用 - 终极方案：把数万小文件打包成
.tar或zarr格式，再用单次mmap或pyarrow.dataset加载 —— 这才是海量小文件的正解
最常被忽略的一点：线程池的加速效果严重依赖文件是否已在page cache中。冷启动时，1000个小文件首次读取，多线程和单线程实际耗时可能相差不到20%，因为瓶颈在磁盘寻道和加载，不在Python调度。
