accept()/accept4()问题：客户端连接数超INT_MAX时会发生什么

首先明确两个基础前提：

• accept()和accept4()返回的是新连接对应的文件描述符（fd），POSIX标准规定这类返回值为带符号整型：非负整数代表有效fd，-1代表调用出错，错误原因存在errno里。
• 主流操作系统（包括Linux、*BSD、macOS等）根本不会出现fd数值超过INT_MAX的场景，不可能靠堆客户端连接触碰到这个上限。

具体原因如下：

• 操作系统分配fd的规则永远是取当前进程可用的最小非负整数，不会无脑递增分配。连接断开后fd会被立即回收复用，正常业务场景下fd数值会长期维持在很低的区间，不会无限上涨。
• 每个进程可持有的fd数量有明确的硬上限：Linux下进程级fd上限由RLIMIT_NOFILE配置控制，就算手动调优，最大值也不能超过系统级参数/proc/sys/fs/nr_open的设定，这个参数默认值是1048576（100万左右），就算魔改内核把这个值拉满，也远小于32位整型的最大值INT_MAX（2147483647，约21亿）。
• 退一万步说，就算通过魔改内核把fd上限拉到接近INT_MAX，等可用fd耗尽时，accept()/accept4()会直接返回-1，把errno设为EMFILE（进程打开文件数超出上限），不会返回溢出的整型值。
• 在真的攒到21亿个连接之前，会先碰到系统内存不足、端口号耗尽、CPU性能瓶颈等一系列更前置的资源限制，服务早就无法正常响应新连接了。

补充：网上流传的"fd溢出返回负数导致程序逻辑崩溃"的场景，本质是程序本身没有正确处理系统调用的返回值，没有先判断返回值是否为-1就直接拿去做业务逻辑判断，和fd数值超过INT_MAX没有关系。

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