为何Golang net包netFD的Read方法中存在读锁？

问题背景 #

在Go的net包底层实现中，netFD的Read方法开头会调用readLock()，核心代码片段如下：

func (fd *netFD) Read(p []byte) (n int, err error) {
    if err := fd.readLock(); err != nil {
        return 0, err
    }
    defer fd.readUnlock()
    // 后续读取逻辑
}

有人提出疑问：既然通常每个客户端连接由单独goroutine处理，理论上不会出现多线程并发读取的情况，为什么需要这个锁？还有观点认为去掉锁能提升运行效率。

锁的核心作用 #

• 约束并发读取行为：Go的net API并没有强制要求用户只能在单个goroutine中调用同一个连接的Read方法。如果用户在多个goroutine里同时对同一个netFD调用Read，没有锁的话，底层系统调用read会把数据随机拆分到不同的buffer中，导致上层业务拿到不完整或逻辑混乱的数据，直接破坏数据完整性。
• 实现读写互斥同步：readLock和对应的writeLock配合，保证同一个netFD上的读写操作不会并发执行。虽然操作系统允许socket上的并发读写，但Go标准库需要保证上层API的行为可预测，比如避免写操作中途被读操作打断，或者fd的关闭标记等状态变量在读写过程中出现不一致。
• 同步fd的关闭状态：锁能确保在Read执行过程中，netFD的关闭操作会被正确同步。比如当一个goroutine在调用Read的同时，另一个goroutine调用Close，锁可以避免出现使用已关闭文件描述符的非法操作，保证错误处理的一致性。

关于“无锁提升效率”的回应 #

这种观点仅适用于用户严格保证单个goroutine处理单个连接的场景，但Go标准库需要兼容所有合法的使用场景，不能依赖用户的使用习惯做假设。而且单个连接的互斥锁开销极小，在绝大多数网络IO场景下，锁的性能损耗远低于IO操作本身，不会成为性能瓶颈。相比之下，保证API的安全性和行为一致性更为重要。

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