很多刚开始学网络编程的朋友都会遇到一个经典场景自己用 C 写了个基于 select 的 TCP 服务端本地测试几十个连接时一切正常等压测工具把并发拉上去之后新客户端怎么都连不上日志里也没有明显的报错。再看系统文件描述符上限ulimit -n明明已经调到 65535可问题依旧。最后翻遍代码才发现瓶颈居然出在最基础的 select 上。这个现象属于非常典型的“select 连接数限制”问题也是面试里高频出现的网络八股。这篇文章我会从源码、数据结构、系统调用流程和真实排障经历几个角度把“为什么 select 只能处理有限数量的连接”这件事彻底讲透顺便给出从 select 到 poll 再到 epoll 的演进思路以及我在实际项目中踩过的坑。1. 先搞清楚 select 到底在干什么1.1 一个最小可运行的 select 服务端很多朋友对 select 的理解只停留在“能同时监听多个 socket”这个层面但真正写代码时才发现问题很多。先看一段最简化的 select TCP 服务端#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include sys/select.h int main() { int listen_fd socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(8888); bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)); listen(listen_fd, 128); fd_set read_fds; int max_fd listen_fd; int client_fds[1024]; int client_count 0; while (1) { FD_ZERO(read_fds); FD_SET(listen_fd, read_fds); for (int i 0; i client_count; i) { FD_SET(client_fds[i], read_fds); if (client_fds[i] max_fd) { max_fd client_fds[i]; } } int ret select(max_fd 1, read_fds, NULL, NULL, NULL); if (ret 0) { perror(select); continue; } if (FD_ISSET(listen_fd, read_fds)) { int client_fd accept(listen_fd, NULL, NULL); client_fds[client_count] client_fd; } for (int i 0; i client_count; i) { if (FD_ISSET(client_fds[i], read_fds)) { // 处理客户端请求 } } } }这段代码的逻辑很直观先把所有关心的 fd 放进read_fds调用 select 等待。select 返回后用FD_ISSET逐个检查哪个 fd 就绪了。监听 socket 可读代表有新连接客户端 socket 可读代表有数据或对端关闭。select 的核心价值是让一个线程同时等待多个 fd而不用为每个连接创建一个线程。这在连接数几百的时候非常舒服也是一代网络库的基石。1.2 四个 fd_set 和 nfds 参数没有你想的那么简单select 的函数原型长这样int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);第一个参数nfds不是 fd 的总数而是“所有 fd 中最大编号 1”。这个参数传给内核内核只检查[0, nfds-1]范围内的 fd。很多人第一次用 select 时都在这里翻车明明 FD_SET 把 fd 加进去了但nfds传成FD_SETSIZE或传小了就会漏事件。后面三个参数是三个 fd 集合readfds关心可读writefds关心可写exceptfds关心异常。在大多数服务端程序里主要用的是 readfds因为读写通常都是通过事件驱动来处理的。有一个非常容易踩的坑select 返回时会把readfds、writefds、exceptfds修改成“当前就绪的 fd 集合”所以每次循环必须重新设置这些集合。很多初学者写成一次初始化死循环里直接调 select结果后面新增的连接永远等不到事件排查半天才发现是集合被改掉了。1.3 说“连接数”前先理解 fd 和连接的关系在 Linux 下一个 TCP 连接对应一个已连接的 socket 对象而这个 socket 对象在用户态的表现就是一个非负整数也就是文件描述符 fd。socket()返回监听 fdaccept()每次接受一个连接就返回一个新的 fd。所以 select 能同时处理的连接数本质上等于它能同时监视的 fd 数量。而它监视 fd 的方式是把 fd 放进一个叫fd_set的结构体里。问题就出在这个结构体身上。理解了这层关系再看“select 为什么只能处理有限数量的连接”问题就会聚焦到一个点上fd_set到底能装下多少个 fd2. 罪魁祸首FD_SETSIZE 与 fd_set 背后的数据结构2.1 打开头文件看看 fd_set 到底长什么样如果你在 Linux 上查看linux/posix_types.h会看到这样的定义#define __FD_SETSIZE 1024而fd_set在sys/select.h中的定义实际上是一个位图数组typedef struct { unsigned long fds_bits[__FD_SETSIZE / (8 * sizeof(unsigned long))]; } fd_set;以常见的 64 位系统为例sizeof(unsigned long)是 8 字节也就是 64 位。__FD_SETSIZE是 10241024 除以 64 等于 16。所以fd_set内部就是 16 个unsigned long总共 1024 个 bit。每个 bit 对应一个 fd 编号第 0 个 bit 对应 fd 0第 1 个 bit 对应 fd 1以此类推。FD_SET(fd, set)做的事情就是把第 fd 个 bit 置为 1FD_ISSET(fd, set)做的事情就是判断第 fd 个 bit 是否为 1。用一个生活化的类比fd_set就像一张固定大小的选票上面只有一个一个的勾选位最多只能勾 1024 个候选 fd。你非要勾第 1024 个对不起这张票上没有这个位置。如果强行写就是数组越界。2.2 1024 这个数字是哪来的很多人以为 1024 是 Linux 内核的“最大连接数”其实不是。内核层面的文件描述符上限由进程的RLIMIT_NOFILE决定默认是 1024但可以调大到几十万。select 的实际限制是它自己使用的fd_set位图被固定成了 1024 位。换句话说系统明明支持你在一个进程里打开几万个 fd但 select 这个接口本身只认前 1024 个编号。fd 编号一旦超过 1023就超出了位图能表达的范围这和你把ulimit -n调多大没有关系。这个“接口跟不上系统能力”的情况在很多底层 API 里都有。就好比你家里宽带能跑到千兆但路由器 WAN 口只支持百兆瓶颈就卡在了接口设计上。2.3 强行调大 FD_SETSIZE 能解决问题吗在不少技术社区里有人提出可以重新定义FD_SETSIZE再包含头文件把这个宏改成 65535让fd_set变大。这样做确实能让 select 支持更大的 fd 编号但只是“看起来解决了”。改写宏之后fd_set结构体的大小从 16 个 unsigned long 变成 1024 个 unsigned long也就是从 128 字节变成 8KB。每次调用 select需要把一个 8KB 的位图从用户态拷到内核态返回时再拷回来。更麻烦的是内核扫描 fd 就绪状态时是线性扫描整个位图的位图越大扫描越慢。连接数一多CPU 消耗会肉眼可见地涨上去。还有一个隐藏风险如果项目里多个源文件对FD_SETSIZE的定义不一致有的地方用 1024有的地方用 65535结构体大小对不上编译出来就是内存写坏和诡异崩溃。所以我的建议是调试时可以临时改一改验证问题生产环境最好不要用这个方案。3. 除了数量上限select 还有哪些隐藏的性能瓶颈3.1 每次调用都在做“全量复印件”和“全量扫描”连接数限制只是 select 最直观的问题。真正让它在高并发场景下被淘汰的是它每次调用时那套笨重的处理流程。select 的调用过程可以拆成三步用户态把整个fd_set拷贝进内核。内核遍历所有被监视的 fd检查每个 fd 是否就绪没有就绪就阻塞等待超时后返回。返回时内核把修改后的fd_set再拷贝回用户态。也就是说不管你有没有事件不管你关心多少个 fd每次 select 都会把整个位图从用户态拷到内核态再拷回来。哪怕你只监视一个 fd内核也会打开整个位图的扫描流程。这个“全量拷贝 全量扫描”的开销是 O(n) 的n 是FD_SETSIZE而不是当前实际连接的 fd 数量。你为了兼容未来可能存在的连接把FD_SETSIZE调到 65535扫描成本也跟着变成 65535 位的扫描。这在事件比较稀疏的场景下纯属浪费。3.2 水平触发和二次遍历select 的“通知”能力很弱select 是水平触发level-triggered的。当一个 fd 可读时select 会返回告诉用户这个 fd 有事件。如果你没有处理完或者只处理了一部分数据下一次再调用 select只要这个 fd 还有数据可读它还会立刻返回。好的一面是你不需要担心丢事件坏的一面是如果你处理得太慢select 可能会在一段时间内反复唤醒进程把 CPU 占用拉满。另外select 返回后并没有直接告诉你“哪些 fd 就绪了”它只给你一个被修改过的位图。你必须再写一个循环遍历从 0 到max_fd的所有 fd逐个调用FD_ISSET判断。也就是说select 的完整开销是“内核扫描一遍所有位 用户态扫描一遍所有 fd”。连接数少的时候无所谓连接数一旦超过四位数这两次线性扫描的消耗就会非常明显。3.3 还有更隐蔽的坑fd_set 作为 in/out 参数fd_set的语义是“传进去时告诉内核你关心哪些 fd传出来时告诉内核哪些 fd 就绪了”所以它是一个典型的 in/out 参数。这意味着你每次调用 select 之前必须把所有关心的 fd 重新加进集合。如果程序里连接数多逻辑复杂反复重建 fd_set 本身就是一笔不小的开销。更麻烦的是如果代码里某个连接被关闭后你还忘把它从集合里移除select 返回时这个 fd 可能已经被复用导致读到其他连接的数据。在一些多线程程序里如果多个线程共享一个 fd_set重建过程还会引入并发问题。当然select 本身不是线程安全的这种用法本身就是高危操作。总之select 最大的问题不是“不能用”而是“用起来要非常小心”处处都是隐藏的边界条件。4. 从 select 到 poll 再到 epoll数量限制如何被一步步打破4.1 面试标准回答三句话讲清 select 的局限如果你现在去面试被问到“为什么 select 只能处理有限数量的连接”可以这样回答“select 使用固定大小的位图fd_set来管理文件描述符这个位图的大小由FD_SETSIZE宏决定在 Linux 下默认是 1024因此它最多只能同时监听 1024 个 fd。其次select 每次调用都要把整个 fd_set 从用户态拷贝到内核态内核需要线性扫描全部 fd返回后用户态还要再次遍历 fd_set 判断就绪状态整体复杂度是 O(n)。所以在高并发场景下即使调大 FD_SETSIZE性能依然很差。这也是后来出现 poll 和 epoll 的主要原因。”这段话逻辑清晰又能体现你对系统调用的理解比单纯背结论好得多。4.2 poll 是怎么解除“1024 上限”的poll 和 select 最大的区别是把“固定大小的位图”换成了“动态数组”。int poll(struct pollfd *fds, nfds_t nfds, int timeout);struct pollfd里保存 fd、关心的事件和返回的事件struct pollfd { int fd; short events; short revents; };因为是数组所以理论上你可以传入任意长度的 pollfd 列表不再受 1024 个 bit 的限制。连接数主要受进程的RLIMIT_NOFILE限制不再受 API 本身的固定位图限制。但 poll 仍然有两个问题一是每次调用还是要全量拷贝整个 pollfd 数组到内核二是内核还是要线性扫描一遍所有 fd返回后用户也要遍历数组。和 select 相比它只是解决了“数量上限”的硬约束并没有从复杂度上解决问题。4.3 epoll 的“回调 就绪链表”为什么能扛高并发epoll 是 Linux 下专门为高并发设计的 I/O 多路复用方案它由三个系统调用组成int epoll_create1(int flags); int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);epoll_ctl负责把 fd 注册到 epoll 实例中内核会把这个 fd 放到一棵红黑树里同时为该 fd 挂上一个回调函数。当 fd 就绪时内核回调函数把 fd 对应的节点放进一个“就绪链表”。epoll_wait要做的事很简单只需要检查就绪链表是否为空如果有就绪事件就把这些节点拷贝到用户态。注意epoll 不是每次调用都扫描全量 fd而是通过回调机制只拿到真正有事件的那一小部分。红黑树负责快速增删改查就绪链表负责收集事件两者一配合复杂度从 O(n) 降到了 O(就绪事件数)。这也是为什么 epoll 能支撑百万连接的同时还能保持较高的处理效率。此外epoll 还支持边缘触发edge-triggered配合非阻塞 socket 使用可以减少重复通知带来的空转。4.4 三种方案的直观对比我用一个表格把 select、poll、epoll 的核心差异整理出来方便你对照记忆对比项selectpollepoll事件存储结构固定大小位图 fd_set动态数组 pollfd红黑树 就绪链表连接数上限FD_SETSIZE默认 1024无硬编码上限无硬编码上限每次调用是否全量拷贝是拷贝整个 fd_set是拷贝整个 pollfd 数组否epoll_wait 只拷贝就绪事件内核检查方式线性扫描所有 fd线性扫描所有 fd回调机制只处理就绪 fd返回后用户态工作遍历 fd_set 逐个 FD_ISSET遍历 pollfd 数组检查 revents遍历就绪事件数组即可触发方式水平触发水平触发水平触发 边缘触发适用场景连接数少、简单场景连接数较多但对性能要求不高高并发、大连接数、事件密集4.5 什么场景下该继续用 select虽然 epoll 在 Linux 下性能更好但 select 并没有完全退出历史舞台。我平时的工作中这几个场景还是会见到 select嵌入式环境或老系统没有 epoll只有 select。Windows 的 Winsock 核心多路复用模型主要依赖 select。教学和学习场景select 代码最简单适合理解 I/O 多路复用的本质。连接数只有几十上百的轻量工具select 的性能完全够用没必要引入 epoll 的复杂度。关键是你要清楚每种方案的适用边界而不是一味追求“最新最先进”。5. 一次真实的排障实录连接数卡在 1024 的背后5.1 故障现场百来个连接没问题一千多就崩我之前维护过一个小型监控采集 agent用 C 写的整体逻辑很轻就是同时管理若干个 TCP 连接定时上报数据。正常情况下连接数不会超过 200但客户要求做一次压测目标并发 2000 个连接。压测刚开始还挺顺利连接数到 1000 左右时新连接的建立开始明显变慢。到 1100 左右新连接直接连不上了老连接的数据也开始断断续续。更诡异的是进程既没有退出也没有打印任何明显错误只是 CPU 占用到了一个比较高的水平。我的第一反应是系统文件描述符不够了因为这类问题通常都会报EMFILE或ENFILE。但查看/var/log/messages和 dmesg没有任何相关错误。再排查ulimit -n显示 65535排除了进程 fd 数量限制。5.2 排查思路先排除系统 fd 限制再看 fd 编号走投无路之下我打印了进程当前打开的所有 fd 数量用lsof -p pid | wc -l一看才 1030 多个。这是什么概念ulimit -n是 65535实际 fd 才用了一千多个远远没到系统上限。我又在代码里加了日志打印每次accept返回的 fd 编号。看到日志的那一刻问题基本就清楚了新连接的 fd 编号已经到了 1024、1025、1026。而代码里用的还是 selectfd_set的位图只有 1024 位。也就是说监听 socket 占用了 3accept出来的连接 fd 编号依次递增一旦连接数超过 1020 个左右新 fd 的编号就会超过 1023。select 的FD_SET根本没有这个位置有的环境会报 “Bad file descriptor”有的环境会直接内存越界写表现成各种奇怪的崩溃。这里也提醒一句很多人遇到连接数上千就下意识去查ulimit -n但 select 的限制和ulimit -n是两码事。就算你把进程 fd 上限调到 10 万只要还是用 select1000 出头的连接数就会撞上FD_SETSIZE这堵墙。5.3 最终解决换 poll并压测验证确认根因后解决方案其实很明确。第一步我先尝试在编译时重新定义FD_SETSIZE为 4096短期压测确实能看到连接数突破 1024但压到 3000 左右又到了新上限而且明显感觉 select 的 CPU 占用高了不少。这个方案只能用来验证问题不能用来长期扛业务。所以我最终把 select 替换成了 poll。核心改动是这样的struct pollfd *pfds calloc(max_conns, sizeof(struct pollfd)); // 监听 fd pfds[0].fd listen_fd; pfds[0].events POLLIN; // 新连接 pfds[i].fd client_fd; pfds[i].events POLLIN; int ret poll(pfds, nfds, -1); if (ret 0) { for (int i 0; i nfds; i) { if (pfds[i].revents POLLIN) { // 处理可读事件 } } }改成 poll 之后2000 个连接压测稳定跑完CPU 占用也回到正常水平。后面如果连接规模再涨一个量级我大概率会直接换 epoll但当前这个体量用 poll 已经足够。6. 关于 select 连接数的常见问题速查问题回答select 最多支持多少个连接Linux 下默认最多同时监视 1024 个 fd实际还要减去标准输入输出和监听 socket所以客户端连接数会略少于 1024。Windows Winsock 下默认 64。把 FD_SETSIZE 改大能彻底解决吗只能临时缓解。位图变大后每次 select 的拷贝和扫描开销也会变大而且不同源文件宏不一致会引发结构体大小冲突。为什么连接数还没到 1024 就崩了因为 fd 编号是从 0 开始递增的监听 fd 和标准输入输出已经占用了前面的编号真正留给连接的 fd 编号可能只有 1020 左右。epoll 为什么没有 1024 限制因为 epoll 不使用固定位图而是通过红黑树和回调机制动态管理文件描述符数量只受系统资源上限限制。select 返回后为什么还要遍历一次因为 select 只返回一个“就绪 fd 位图”没有直接给出就绪列表需要用户用 FD_ISSET 逐个判断。nfds 参数传错会怎样如果 nfds 比最大 fd 编号 1 小内核就不会检查那些高位 fd事件会被漏掉。这是 select 新手最常见的坑之一。高并发场景下 poll 比 select 好吗poll 解除了 1024 限制但依然是线性扫描连接数很大时性能不够。Linux 高并发通常还是用 epoll。聊到这里我再分享一个自己常用的排查思路如果线上服务连接数卡在了一个比较整齐的数字附近比如几百、一千先别急着调ulimit先在代码里打日志看看当前分配的 fd 编号是多少。只要 fd 编号接近 1023、2047 这类边界优先怀疑的就是某个 API 的容量限制。select 只是其中最典型的一个类似的还有fd_set的大小、信号量数量、定时器表项数量等等。多记录几次这种边界现象你对底层接口的理解会比背十篇八股文都更扎实。 
长河君 · 2026/8/29 23:34:43 · 阅读 1.2k select为什么只能处理1024个连接？从源码到排障彻底讲透
很多刚开始学网络编程的朋友都会遇到一个经典场景自己用 C 写了个基于 select 的 TCP 服务端本地测试几十个连接时一切正常等压测工具把并发拉上去之后新客户端怎么都连不上日志里也没有明显的报错。再看系统文件描述符上限ulimit -n明明已经调到 65535可问题依旧。最后翻遍代码才发现瓶颈居然出在最基础的 select 上。这个现象属于非常典型的“select 连接数限制”问题也是面试里高频出现的网络八股。这篇文章我会从源码、数据结构、系统调用流程和真实排障经历几个角度把“为什么 select 只能处理有限数量的连接”这件事彻底讲透顺便给出从 select 到 poll 再到 epoll 的演进思路以及我在实际项目中踩过的坑。1. 先搞清楚 select 到底在干什么1.1 一个最小可运行的 select 服务端很多朋友对 select 的理解只停留在“能同时监听多个 socket”这个层面但真正写代码时才发现问题很多。先看一段最简化的 select TCP 服务端#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/socket.h #include netinet/in.h #include sys/select.h int main() { int listen_fd socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(8888); bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)); listen(listen_fd, 128); fd_set read_fds; int max_fd listen_fd; int client_fds[1024]; int client_count 0; while (1) { FD_ZERO(read_fds); FD_SET(listen_fd, read_fds); for (int i 0; i client_count; i) { FD_SET(client_fds[i], read_fds); if (client_fds[i] max_fd) { max_fd client_fds[i]; } } int ret select(max_fd 1, read_fds, NULL, NULL, NULL); if (ret 0) { perror(select); continue; } if (FD_ISSET(listen_fd, read_fds)) { int client_fd accept(listen_fd, NULL, NULL); client_fds[client_count] client_fd; } for (int i 0; i client_count; i) { if (FD_ISSET(client_fds[i], read_fds)) { // 处理客户端请求 } } } }这段代码的逻辑很直观先把所有关心的 fd 放进read_fds调用 select 等待。select 返回后用FD_ISSET逐个检查哪个 fd 就绪了。监听 socket 可读代表有新连接客户端 socket 可读代表有数据或对端关闭。select 的核心价值是让一个线程同时等待多个 fd而不用为每个连接创建一个线程。这在连接数几百的时候非常舒服也是一代网络库的基石。1.2 四个 fd_set 和 nfds 参数没有你想的那么简单select 的函数原型长这样int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);第一个参数nfds不是 fd 的总数而是“所有 fd 中最大编号 1”。这个参数传给内核内核只检查[0, nfds-1]范围内的 fd。很多人第一次用 select 时都在这里翻车明明 FD_SET 把 fd 加进去了但nfds传成FD_SETSIZE或传小了就会漏事件。后面三个参数是三个 fd 集合readfds关心可读writefds关心可写exceptfds关心异常。在大多数服务端程序里主要用的是 readfds因为读写通常都是通过事件驱动来处理的。有一个非常容易踩的坑select 返回时会把readfds、writefds、exceptfds修改成“当前就绪的 fd 集合”所以每次循环必须重新设置这些集合。很多初学者写成一次初始化死循环里直接调 select结果后面新增的连接永远等不到事件排查半天才发现是集合被改掉了。1.3 说“连接数”前先理解 fd 和连接的关系在 Linux 下一个 TCP 连接对应一个已连接的 socket 对象而这个 socket 对象在用户态的表现就是一个非负整数也就是文件描述符 fd。socket()返回监听 fdaccept()每次接受一个连接就返回一个新的 fd。所以 select 能同时处理的连接数本质上等于它能同时监视的 fd 数量。而它监视 fd 的方式是把 fd 放进一个叫fd_set的结构体里。问题就出在这个结构体身上。理解了这层关系再看“select 为什么只能处理有限数量的连接”问题就会聚焦到一个点上fd_set到底能装下多少个 fd2. 罪魁祸首FD_SETSIZE 与 fd_set 背后的数据结构2.1 打开头文件看看 fd_set 到底长什么样如果你在 Linux 上查看linux/posix_types.h会看到这样的定义#define __FD_SETSIZE 1024而fd_set在sys/select.h中的定义实际上是一个位图数组typedef struct { unsigned long fds_bits[__FD_SETSIZE / (8 * sizeof(unsigned long))]; } fd_set;以常见的 64 位系统为例sizeof(unsigned long)是 8 字节也就是 64 位。__FD_SETSIZE是 10241024 除以 64 等于 16。所以fd_set内部就是 16 个unsigned long总共 1024 个 bit。每个 bit 对应一个 fd 编号第 0 个 bit 对应 fd 0第 1 个 bit 对应 fd 1以此类推。FD_SET(fd, set)做的事情就是把第 fd 个 bit 置为 1FD_ISSET(fd, set)做的事情就是判断第 fd 个 bit 是否为 1。用一个生活化的类比fd_set就像一张固定大小的选票上面只有一个一个的勾选位最多只能勾 1024 个候选 fd。你非要勾第 1024 个对不起这张票上没有这个位置。如果强行写就是数组越界。2.2 1024 这个数字是哪来的很多人以为 1024 是 Linux 内核的“最大连接数”其实不是。内核层面的文件描述符上限由进程的RLIMIT_NOFILE决定默认是 1024但可以调大到几十万。select 的实际限制是它自己使用的fd_set位图被固定成了 1024 位。换句话说系统明明支持你在一个进程里打开几万个 fd但 select 这个接口本身只认前 1024 个编号。fd 编号一旦超过 1023就超出了位图能表达的范围这和你把ulimit -n调多大没有关系。这个“接口跟不上系统能力”的情况在很多底层 API 里都有。就好比你家里宽带能跑到千兆但路由器 WAN 口只支持百兆瓶颈就卡在了接口设计上。2.3 强行调大 FD_SETSIZE 能解决问题吗在不少技术社区里有人提出可以重新定义FD_SETSIZE再包含头文件把这个宏改成 65535让fd_set变大。这样做确实能让 select 支持更大的 fd 编号但只是“看起来解决了”。改写宏之后fd_set结构体的大小从 16 个 unsigned long 变成 1024 个 unsigned long也就是从 128 字节变成 8KB。每次调用 select需要把一个 8KB 的位图从用户态拷到内核态返回时再拷回来。更麻烦的是内核扫描 fd 就绪状态时是线性扫描整个位图的位图越大扫描越慢。连接数一多CPU 消耗会肉眼可见地涨上去。还有一个隐藏风险如果项目里多个源文件对FD_SETSIZE的定义不一致有的地方用 1024有的地方用 65535结构体大小对不上编译出来就是内存写坏和诡异崩溃。所以我的建议是调试时可以临时改一改验证问题生产环境最好不要用这个方案。3. 除了数量上限select 还有哪些隐藏的性能瓶颈3.1 每次调用都在做“全量复印件”和“全量扫描”连接数限制只是 select 最直观的问题。真正让它在高并发场景下被淘汰的是它每次调用时那套笨重的处理流程。select 的调用过程可以拆成三步用户态把整个fd_set拷贝进内核。内核遍历所有被监视的 fd检查每个 fd 是否就绪没有就绪就阻塞等待超时后返回。返回时内核把修改后的fd_set再拷贝回用户态。也就是说不管你有没有事件不管你关心多少个 fd每次 select 都会把整个位图从用户态拷到内核态再拷回来。哪怕你只监视一个 fd内核也会打开整个位图的扫描流程。这个“全量拷贝 全量扫描”的开销是 O(n) 的n 是FD_SETSIZE而不是当前实际连接的 fd 数量。你为了兼容未来可能存在的连接把FD_SETSIZE调到 65535扫描成本也跟着变成 65535 位的扫描。这在事件比较稀疏的场景下纯属浪费。3.2 水平触发和二次遍历select 的“通知”能力很弱select 是水平触发level-triggered的。当一个 fd 可读时select 会返回告诉用户这个 fd 有事件。如果你没有处理完或者只处理了一部分数据下一次再调用 select只要这个 fd 还有数据可读它还会立刻返回。好的一面是你不需要担心丢事件坏的一面是如果你处理得太慢select 可能会在一段时间内反复唤醒进程把 CPU 占用拉满。另外select 返回后并没有直接告诉你“哪些 fd 就绪了”它只给你一个被修改过的位图。你必须再写一个循环遍历从 0 到max_fd的所有 fd逐个调用FD_ISSET判断。也就是说select 的完整开销是“内核扫描一遍所有位 用户态扫描一遍所有 fd”。连接数少的时候无所谓连接数一旦超过四位数这两次线性扫描的消耗就会非常明显。3.3 还有更隐蔽的坑fd_set 作为 in/out 参数fd_set的语义是“传进去时告诉内核你关心哪些 fd传出来时告诉内核哪些 fd 就绪了”所以它是一个典型的 in/out 参数。这意味着你每次调用 select 之前必须把所有关心的 fd 重新加进集合。如果程序里连接数多逻辑复杂反复重建 fd_set 本身就是一笔不小的开销。更麻烦的是如果代码里某个连接被关闭后你还忘把它从集合里移除select 返回时这个 fd 可能已经被复用导致读到其他连接的数据。在一些多线程程序里如果多个线程共享一个 fd_set重建过程还会引入并发问题。当然select 本身不是线程安全的这种用法本身就是高危操作。总之select 最大的问题不是“不能用”而是“用起来要非常小心”处处都是隐藏的边界条件。4. 从 select 到 poll 再到 epoll数量限制如何被一步步打破4.1 面试标准回答三句话讲清 select 的局限如果你现在去面试被问到“为什么 select 只能处理有限数量的连接”可以这样回答“select 使用固定大小的位图fd_set来管理文件描述符这个位图的大小由FD_SETSIZE宏决定在 Linux 下默认是 1024因此它最多只能同时监听 1024 个 fd。其次select 每次调用都要把整个 fd_set 从用户态拷贝到内核态内核需要线性扫描全部 fd返回后用户态还要再次遍历 fd_set 判断就绪状态整体复杂度是 O(n)。所以在高并发场景下即使调大 FD_SETSIZE性能依然很差。这也是后来出现 poll 和 epoll 的主要原因。”这段话逻辑清晰又能体现你对系统调用的理解比单纯背结论好得多。4.2 poll 是怎么解除“1024 上限”的poll 和 select 最大的区别是把“固定大小的位图”换成了“动态数组”。int poll(struct pollfd *fds, nfds_t nfds, int timeout);struct pollfd里保存 fd、关心的事件和返回的事件struct pollfd { int fd; short events; short revents; };因为是数组所以理论上你可以传入任意长度的 pollfd 列表不再受 1024 个 bit 的限制。连接数主要受进程的RLIMIT_NOFILE限制不再受 API 本身的固定位图限制。但 poll 仍然有两个问题一是每次调用还是要全量拷贝整个 pollfd 数组到内核二是内核还是要线性扫描一遍所有 fd返回后用户也要遍历数组。和 select 相比它只是解决了“数量上限”的硬约束并没有从复杂度上解决问题。4.3 epoll 的“回调 就绪链表”为什么能扛高并发epoll 是 Linux 下专门为高并发设计的 I/O 多路复用方案它由三个系统调用组成int epoll_create1(int flags); int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);epoll_ctl负责把 fd 注册到 epoll 实例中内核会把这个 fd 放到一棵红黑树里同时为该 fd 挂上一个回调函数。当 fd 就绪时内核回调函数把 fd 对应的节点放进一个“就绪链表”。epoll_wait要做的事很简单只需要检查就绪链表是否为空如果有就绪事件就把这些节点拷贝到用户态。注意epoll 不是每次调用都扫描全量 fd而是通过回调机制只拿到真正有事件的那一小部分。红黑树负责快速增删改查就绪链表负责收集事件两者一配合复杂度从 O(n) 降到了 O(就绪事件数)。这也是为什么 epoll 能支撑百万连接的同时还能保持较高的处理效率。此外epoll 还支持边缘触发edge-triggered配合非阻塞 socket 使用可以减少重复通知带来的空转。4.4 三种方案的直观对比我用一个表格把 select、poll、epoll 的核心差异整理出来方便你对照记忆对比项selectpollepoll事件存储结构固定大小位图 fd_set动态数组 pollfd红黑树 就绪链表连接数上限FD_SETSIZE默认 1024无硬编码上限无硬编码上限每次调用是否全量拷贝是拷贝整个 fd_set是拷贝整个 pollfd 数组否epoll_wait 只拷贝就绪事件内核检查方式线性扫描所有 fd线性扫描所有 fd回调机制只处理就绪 fd返回后用户态工作遍历 fd_set 逐个 FD_ISSET遍历 pollfd 数组检查 revents遍历就绪事件数组即可触发方式水平触发水平触发水平触发 边缘触发适用场景连接数少、简单场景连接数较多但对性能要求不高高并发、大连接数、事件密集4.5 什么场景下该继续用 select虽然 epoll 在 Linux 下性能更好但 select 并没有完全退出历史舞台。我平时的工作中这几个场景还是会见到 select嵌入式环境或老系统没有 epoll只有 select。Windows 的 Winsock 核心多路复用模型主要依赖 select。教学和学习场景select 代码最简单适合理解 I/O 多路复用的本质。连接数只有几十上百的轻量工具select 的性能完全够用没必要引入 epoll 的复杂度。关键是你要清楚每种方案的适用边界而不是一味追求“最新最先进”。5. 一次真实的排障实录连接数卡在 1024 的背后5.1 故障现场百来个连接没问题一千多就崩我之前维护过一个小型监控采集 agent用 C 写的整体逻辑很轻就是同时管理若干个 TCP 连接定时上报数据。正常情况下连接数不会超过 200但客户要求做一次压测目标并发 2000 个连接。压测刚开始还挺顺利连接数到 1000 左右时新连接的建立开始明显变慢。到 1100 左右新连接直接连不上了老连接的数据也开始断断续续。更诡异的是进程既没有退出也没有打印任何明显错误只是 CPU 占用到了一个比较高的水平。我的第一反应是系统文件描述符不够了因为这类问题通常都会报EMFILE或ENFILE。但查看/var/log/messages和 dmesg没有任何相关错误。再排查ulimit -n显示 65535排除了进程 fd 数量限制。5.2 排查思路先排除系统 fd 限制再看 fd 编号走投无路之下我打印了进程当前打开的所有 fd 数量用lsof -p pid | wc -l一看才 1030 多个。这是什么概念ulimit -n是 65535实际 fd 才用了一千多个远远没到系统上限。我又在代码里加了日志打印每次accept返回的 fd 编号。看到日志的那一刻问题基本就清楚了新连接的 fd 编号已经到了 1024、1025、1026。而代码里用的还是 selectfd_set的位图只有 1024 位。也就是说监听 socket 占用了 3accept出来的连接 fd 编号依次递增一旦连接数超过 1020 个左右新 fd 的编号就会超过 1023。select 的FD_SET根本没有这个位置有的环境会报 “Bad file descriptor”有的环境会直接内存越界写表现成各种奇怪的崩溃。这里也提醒一句很多人遇到连接数上千就下意识去查ulimit -n但 select 的限制和ulimit -n是两码事。就算你把进程 fd 上限调到 10 万只要还是用 select1000 出头的连接数就会撞上FD_SETSIZE这堵墙。5.3 最终解决换 poll并压测验证确认根因后解决方案其实很明确。第一步我先尝试在编译时重新定义FD_SETSIZE为 4096短期压测确实能看到连接数突破 1024但压到 3000 左右又到了新上限而且明显感觉 select 的 CPU 占用高了不少。这个方案只能用来验证问题不能用来长期扛业务。所以我最终把 select 替换成了 poll。核心改动是这样的struct pollfd *pfds calloc(max_conns, sizeof(struct pollfd)); // 监听 fd pfds[0].fd listen_fd; pfds[0].events POLLIN; // 新连接 pfds[i].fd client_fd; pfds[i].events POLLIN; int ret poll(pfds, nfds, -1); if (ret 0) { for (int i 0; i nfds; i) { if (pfds[i].revents POLLIN) { // 处理可读事件 } } }改成 poll 之后2000 个连接压测稳定跑完CPU 占用也回到正常水平。后面如果连接规模再涨一个量级我大概率会直接换 epoll但当前这个体量用 poll 已经足够。6. 关于 select 连接数的常见问题速查问题回答select 最多支持多少个连接Linux 下默认最多同时监视 1024 个 fd实际还要减去标准输入输出和监听 socket所以客户端连接数会略少于 1024。Windows Winsock 下默认 64。把 FD_SETSIZE 改大能彻底解决吗只能临时缓解。位图变大后每次 select 的拷贝和扫描开销也会变大而且不同源文件宏不一致会引发结构体大小冲突。为什么连接数还没到 1024 就崩了因为 fd 编号是从 0 开始递增的监听 fd 和标准输入输出已经占用了前面的编号真正留给连接的 fd 编号可能只有 1020 左右。epoll 为什么没有 1024 限制因为 epoll 不使用固定位图而是通过红黑树和回调机制动态管理文件描述符数量只受系统资源上限限制。select 返回后为什么还要遍历一次因为 select 只返回一个“就绪 fd 位图”没有直接给出就绪列表需要用户用 FD_ISSET 逐个判断。nfds 参数传错会怎样如果 nfds 比最大 fd 编号 1 小内核就不会检查那些高位 fd事件会被漏掉。这是 select 新手最常见的坑之一。高并发场景下 poll 比 select 好吗poll 解除了 1024 限制但依然是线性扫描连接数很大时性能不够。Linux 高并发通常还是用 epoll。聊到这里我再分享一个自己常用的排查思路如果线上服务连接数卡在了一个比较整齐的数字附近比如几百、一千先别急着调ulimit先在代码里打日志看看当前分配的 fd 编号是多少。只要 fd 编号接近 1023、2047 这类边界优先怀疑的就是某个 API 的容量限制。select 只是其中最典型的一个类似的还有fd_set的大小、信号量数量、定时器表项数量等等。多记录几次这种边界现象你对底层接口的理解会比背十篇八股文都更扎实。