C++如何设置文件为非阻塞读写模式 _ fcntl与O_NONBLOCK标志【实战】

先说几个关键点。设置非阻塞模式这件事，在Linux下真正靠谱的方式只有一个——用fcntl。open时传O_NONBLOCK只对新打开的文件有效，对于已经打开的文件描述符，必须通过fcntl来修改。当然，如果文件本身是通过open打开的，且当时就传入了该标志，那是另一回事，但这不是本文讨论的重点。

容易犯的错误是，以为调个open(fd, O_RDWR | O_NONBLOCK)就能把已经打开的fd改成非阻塞——不行。open的语义就是“打开一个新文件”，它的参数对旧描述符没有影响，这一点必须拎清楚。

实际操作中，标准的流程是：先用fcntl(fd, F_GETFL)把当前的标志位读出来，然后拿O_NONBLOCK去按位或一下，最后用F_SETFL写回去。为什么要这么麻烦？因为要避免覆盖掉之前可能已经设好的其他标志，比如O_APPEND或者O_SYNC。直接赋值是粗暴的，容易出问题。

设置完之后，还得检查一下返回值。如果fcntl返回-1，那说明调用失败，errno会告诉你原因：EBADF表示传入的描述符非法，EINVAL说明该文件类型本身就不支持非阻塞。后者并不常见，但一旦碰上，往往意味着代码逻辑需要重新审视。

对普通文件设O_NONBLOCK：基本没用

这是容易被忽视的一点。Linux内核对于常规文件（ext4、xfs上的普通文件）其实会忽略O_NONBLOCK标志。也就是说，就算你费劲把标志设上去了，当你调用read或write的时候，只要数据还在页缓存里，调用就会立刻返回；如果缓存里没有，触发回刷或加载时，该阻塞还是会阻塞。因为“等待IO完成”这个行为对于普通文件来说，本质上就是同步的，O_NONBLOCK根本插不上手。

那么，什么场景才是非阻塞真正的用武之地？

• 网络套接字（socket，包括accept返回的描述符）
• 管道（pipe和fifo）
• 伪终端设备（/dev/pts/*）
• 某些字符设备文件（比如/dev/ttyS0）

这些类型的特点是，IO操作在“无数据”或“缓冲区满”时，需要等待，而用户态程序往往不希望在这个等待上无限挂起。举个典型的例子：检测socket是否有数据可读，但又不想被阻塞。

int flags = fcntl(sockfd, F_GETFL);
fcntl(sockfd, F_SETFL, flags | O_NONBLOCK);
ssize_t n = read(sockfd, buf, sizeof(buf));
if (n == -1 && errno == EAGAIN) {
    // 没有数据可读，但描述符状态正常，继续处理别的
}

这里EAGAIN就是非阻塞模式下，告诉你“现在干不了，回头再来”的信号。

fcntl与ioctl(FIONBIO)：同途殊归

除了fcntl，还有另一个接口也能做类似的事——ioctl(fd, FIONBIO, &on)。两者最终效果都可以把fd设为非阻塞，但行为上有一个重要区别。

fcntl是位操作：你读出一组标志，修改其中某一位，再写回去。而ioctl是开关式的：on为非零值就是开启，为0就是关闭，直接覆盖。这意味着，如果你先用ioctl打开了非阻塞，之后再用fcntl的F_GETFL去读，有可能读不到O_NONBLOCK标志——因为ioctl的操作方式并不更新F_GETFL可见的那个标志位。这就容易造成状态混乱。

所以，推荐的做法是统一使用fcntl。如果代码需要跨平台，或者维护的是遗留系统（比如旧版Solaris上fcntl可能不支持非阻塞设置），那么才需要考虑ioctl。但即便如此，也要清楚混用两种方式的风险。

C++封装：几个容易忽略的细节

用RAII把非阻塞设置封装成一个类，看起来很优雅，实际踩坑的不在少数。最常漏掉的有两点。

第一，构造函数里没保存原始标志。析构的时候想要恢复，但原始值已经丢了。结果要么是粗暴地清零，把O_APPEND之类的标志也一并关掉；要么是根本恢复不了，破坏了调用方的状态。

第二，没有处理fcntl调用失败的边界情况。比如有人传入了标准输入STDIN_FILENO，在某些环境下（比如终端被关闭），设为非阻塞可能会失败。如果代码不做检查，后续的IO行为就会变得不可预期。

还有一个更隐蔽的问题：如果同一个fd被多个RAII对象管理，每个对象的构造函数都去设置一次O_NONBLOCK，虽然没什么害处，但属于冗余操作。更要命的是，如果析构顺序乱掉，某个对象在析构时把非阻塞关了，但另一个对象还在依赖非阻塞行为——这就会导致间歇性的死锁或者异常。

一个简单的修复思路是：用std::optional缓存第一次读到的原始标志，仅在首次设置时读取；析构之前，先检查当前标志是否真的包含O_NONBLOCK，如果确实存在再清除。这样至少能避免无谓的覆盖和状态污染。

说到底，非阻塞IO改变的就只有一件事：等待IO就绪这个环节的行为。它不会让IO本身变快，也不会让设备的吞吐能力提升。对于普通文件，这层控制权压根不在用户态代码手里——这是设计之初就定好的事。