为何单线程读取半文件远快于pthread单线程读取？多线程分块读文件是否有意义？

嗨，这个问题的核心原因其实挺有意思的，咱们一步步拆解：

一、为什么线程版本慢这么多？ #

你观察到的巨大性能差距，根本原因不是多线程本身，而是编译选项导致的stdio线程安全开销。

咱们仔细看两个版本的编译场景：

• 单线程版本你应该是直接用普通命令编译（比如gcc file.c -o single），这时候fgetc是一个宏——它会直接访问FILE结构体的内存缓冲区，几乎没有额外开销，加上stdio默认的全缓冲机制，实际磁盘IO次数极少，所以3.5GB的读取只需要几毫秒（大部分时间是在内存缓冲区里拿数据）。
• 线程版本你肯定加了-pthread编译（比如gcc thread.c -o thread -pthread），这时候为了保证线程安全，glibc会把fgetc替换成线程安全的函数版本——每调用一次fgetc，都要对FILE对象加锁、解锁，哪怕只有一个线程在操作这个文件。

你要知道3.5GB是将近37亿字节，每一次fgetc都要执行一次锁操作，这个累加的开销直接把时间从毫秒级拉到了几十秒——这就是慢的根源！

你可以做个测试验证：把单线程代码也用-pthread编译运行，它的耗时会和线程版本差不多；反过来，如果线程版本不用-pthread（当然会链接失败，但能看到stdio行为的差异），速度差距就会消失。

二、多线程分块读文件到底有没有意义？ #

这得分存储设备类型来看：

1. 机械硬盘（HDD）：几乎没意义 #

机械硬盘的瓶颈是磁头寻道时间，多线程读取会导致磁头在不同文件区间来回跳动，反而会降低整体读取速度。这种场景下，单线程顺序读取是最优选择。

2. SSD/NVMe硬盘：有一定意义，但要注意正确的姿势 #

这类固态存储设备支持并行IO，多线程分块读取可以利用硬件的并行特性，提升读取速度，但你得避开几个坑：

• 不要共享FILE*对象：哪怕是分块读，共用同一个FILE*会因为stdio的锁机制导致线程竞争，反而拖慢速度。每个线程应该打开自己的文件描述符，或者用pread系统调用（可以指定读取偏移，不需要共享文件指针）。
• 用大块读取代替逐个字节：fgetc这种单字节读取的方式，不管单线程还是多线程都是效率极低的，换成fread或者read系统调用，一次读几KB甚至几MB的块，能大幅减少系统调用和锁的开销。
• 合理分块：分块大小不能太小（否则IO请求太多），也不能太大（无法充分利用并行性），一般建议分块大小设为磁盘的扇区倍数（比如4KB、16KB）或者更大的固定值（比如64MB）。

举个简单的正确思路：每个线程负责文件的一个独立区间，比如线程1读0到size/2，线程2读size/2到size，每个线程自己打开文件（或者用lseek定位到对应偏移），然后用fread批量读取数据。

最后补个小提醒 #

你代码里用fgetc虽然简化了逻辑，但它本身就不是高效的读取方式——哪怕是单线程，换成fread一次性读大块数据，速度还能再提升不少（不过你单线程版本已经靠stdio缓冲快到毫秒级了，可能感知不明显）。

备注：内容来源于stack exchange，提问作者Cardinal