select速度较慢的原因#

$select$主要存在两个性能问题：

1. 函数返回后，程序需要遍历监视范围内的所有文件描述符，逐一调用$FD\_ISSET$寻找发生事件的对象。
2. 每次调用$select$前，都要重新复制并向操作系统传递完整的监视集合。

第一个问题会让检查成本随着最大文件描述符增大。即使当前只有少数套接字就绪，程序仍要扫描整个范围。第二个问题则意味着用户空间与内核空间之间需要反复传递监视信息，这种成本很难仅靠优化应用代码消除。

$epoll$采用不同的管理方式：程序只在监视范围发生变化时通知操作系统，把文件描述符长期注册在内核维护的$epoll$实例中；等待事件时，内核只返回已经就绪的对象。程序仍需遍历返回的事件数组，但不必扫描所有受监视的描述符。

select仍然有适用场景#

$epoll$是$Linux$特有接口，不具备$select$那样广泛的平台兼容性。若服务器连接数量较少，或者程序需要方便地移植到不同操作系统，$select$仍然可能是更简单、合理的选择。

并不存在适用于所有场景的$I/O$模型。连接规模、平台兼容性和实现复杂度都应纳入选择，而不能只因为$epoll$通常性能更好就无条件使用。

epoll的三个核心函数#

$epoll$服务器主要使用三个函数：

• $epoll\_create$：创建保存监视对象的$epoll$实例。
• $epoll\_ctl$：向实例添加、删除或修改文件描述符。
• $epoll\_wait$：等待事件，并返回已经发生事件的描述符。

$select$通过应用程序中的$fd\_set$保存监视集合，而$epoll$把监视关系交给操作系统维护。事件发生后，$epoll\_wait$会把就绪信息写入$epoll\_event$数组：

1
#include <sys/epoll.h>
2

3
struct epoll_event
4
{
5
    uint32_t events;
6
    epoll_data_t data;
7
};
8

9
typedef union epoll_data
10
{
11
    void     *ptr;
12
    int       fd;
13
    uint32_t  u32;
14
    uint64_t  u64;
15
} epoll_data_t;

$events$表示关注或已经发生的事件类型，$data$用于保存与事件关联的数据。简单服务器通常使用$data.fd$保存套接字文件描述符。

创建epoll实例#

1
#include <sys/epoll.h>
2

3
int epoll_create(int size);
4
//成功时返回epoll文件描述符，失败时返回-1。

调用成功后，操作系统会创建一个$epoll$实例，并返回用于标识它的文件描述符。$size$在早期内核中用于向系统建议实例规模；从$Linux\ 2.6.8$开始，该参数会被忽略，但仍需传入一个大于$0$的值。

1
int epfd = epoll_create(50);

$epoll$实例也是由操作系统管理的资源。程序结束监视后，需要像关闭普通文件描述符一样调用$close(epfd)$。

注册和修改监视对象#

1
#include <sys/epoll.h>
2

3
int epoll_ctl(int epfd, int op, int fd,
4
              struct epoll_event *event);
5
//成功时返回0，失败时返回-1。

$epfd$指定$epoll$实例，$fd$是需要操作的文件描述符，$op$表示操作类型：

将套接字$sockfd$加入$epoll$实例，并关注可读事件：

1
struct epoll_event event;
2

3
event.events = EPOLLIN;
4
event.data.fd = sockfd;
5

6
epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &event);

从实例中删除描述符时，不再需要提供关注事件：

1
epoll_ctl(epfd, EPOLL_CTL_DEL, sockfd, NULL);

常见事件标志如下：

多个标志可以通过按位或运算符$|$组合。使用$EPOLLONESHOT$后，若要让描述符重新接收通知，需要通过$EPOLL\_CTL\_MOD$再次设置事件。

等待事件#

1
#include <sys/epoll.h>
2

3
int epoll_wait(int epfd, struct epoll_event *events,
4
               int maxevents, int timeout);
5
//成功时返回发生事件的描述符数量，失败时返回-1。

$events$用于保存已经发生的事件，$maxevents$表示数组容量。$timeout$以毫秒为单位，传入$-1$表示一直等待，传入$0$则立即返回。

1
struct epoll_event *ep_events;
2
int event_cnt;
3

4
ep_events = malloc(sizeof(struct epoll_event) * EPOLL_SIZE);
5
event_cnt = epoll_wait(epfd, ep_events,
6
                       EPOLL_SIZE, -1);

函数返回后，$ep\_events[0]$到$ep\_events[event\_cnt-1]$只保存本次已经就绪的对象。因此，后续循环的范围由就绪事件数决定，而不是由所有监视对象的数量决定。

基于epoll的回声服务器#

基于$epoll$的回声服务器仍由监听套接字和客户端套接字组成。区别在于，这些描述符会被注册到$epoll$实例中，再由$epoll\_wait$集中等待。

1
epfd = epoll_create(EPOLL_SIZE);
2
ep_events = malloc(sizeof(struct epoll_event) * EPOLL_SIZE);
3

4
event.events = EPOLLIN;
5
event.data.fd = serv_sock;
6
epoll_ctl(epfd, EPOLL_CTL_ADD, serv_sock, &event);
7

8
while (1)
9
{
10
    event_cnt = epoll_wait(epfd, ep_events,
11
                           EPOLL_SIZE, -1);
12

13
    if (event_cnt == -1)
14
        break;
15

16
    for (i = 0; i < event_cnt; i++)
17
    {
18
        int fd = ep_events[i].data.fd;
19

20
        if (fd == serv_sock)
21
        {
22
            clnt_sock = accept(serv_sock,
23
                               (struct sockaddr *)&clnt_adr,
24
                               &adr_sz);
25

26
            event.events = EPOLLIN;
27
            event.data.fd = clnt_sock;
28
            epoll_ctl(epfd, EPOLL_CTL_ADD,
29
                      clnt_sock, &event);
30
        }
31
        else
32
        {
33
            str_len = read(fd, buf, BUF_SIZE);
34

35
            if (str_len == 0)
36
            {
37
                epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
38
                close(fd);
39
            }
40
            else
41
                write(fd, buf, str_len);
42
        }
43
    }
44
}

监听套接字发生可读事件，表示有新的连接请求；已连接套接字发生可读事件，则表示有数据到达或对方已经断开。客户端关闭连接时，应先从$epoll$实例删除描述符，再调用$close$释放套接字。

条件触发#

条件触发模式下，只要输入缓冲中仍有数据，$epoll\_wait$就会继续报告该套接字的可读事件。

假设输入缓冲收到$50$字节，而程序每次只读取$20$字节：第一次读取后仍剩$30$字节，所以再次调用$epoll\_wait$时，该描述符仍会被返回。直到输入缓冲被读空，事件通知才会停止。

$epoll$默认使用条件触发，$select$也具有相同的通知特点。它的优点是程序即使一次没有读完数据，之后仍会得到提醒，处理逻辑相对直观。

1
event.events = EPOLLIN;  //默认条件触发
2
event.data.fd = clnt_sock;
3
epoll_ctl(epfd, EPOLL_CTL_ADD, clnt_sock, &event);

边缘触发#

边缘触发只在文件描述符的状态发生变化时通知一次。例如，输入缓冲从“无数据”变为“有数据”时产生事件；程序若只读取一部分，缓冲中虽然仍有旧数据，但状态没有再次发生变化，因此不会仅因这些剩余数据而重复通知。

1
event.events = EPOLLIN | EPOLLET;
2
event.data.fd = clnt_sock;
3
epoll_ctl(epfd, EPOLL_CTL_ADD, clnt_sock, &event);

这意味着边缘触发不能沿用“每次事件只读一次”的处理方式。若一次没有读完，残留数据可能长时间得不到处理。正确做法是在事件到来后循环读取，直到确认输入缓冲已经为空。

将套接字设为非阻塞模式#

边缘触发需要持续读取到“当前没有更多数据”为止。如果套接字仍处于阻塞模式，最后一次$read$可能在数据读完后继续等待，从而让整个事件循环停住。因此，边缘触发通常要配合非阻塞套接字。

可以通过$fcntl$读取原有属性，再添加$O\_NONBLOCK$：

1
#include <fcntl.h>
2

3
void setnonblockingmode(int fd)
4
{
5
    int flag = fcntl(fd, F_GETFL, 0);
6
    fcntl(fd, F_SETFL, flag | O_NONBLOCK);
7
}

新连接建立后，先把客户端套接字设为非阻塞，再以边缘触发方式注册：

1
clnt_sock = accept(serv_sock,
2
                   (struct sockaddr *)&clnt_adr, &adr_sz);
3

4
setnonblockingmode(clnt_sock);
5

6
event.events = EPOLLIN | EPOLLET;
7
event.data.fd = clnt_sock;
8
epoll_ctl(epfd, EPOLL_CTL_ADD, clnt_sock, &event);

利用errno判断是否读取完毕#

非阻塞$read$在当前没有数据可读时返回$-1$，并把$errno$设为$EAGAIN$。边缘触发服务器可以利用这一点判断输入缓冲已经被读空：

1
#include <errno.h>
2

3
while (1)
4
{
5
    str_len = read(fd, buf, BUF_SIZE);
6

7
    if (str_len > 0)
8
    {
9
        write(fd, buf, str_len);
10
    }
11
    else if (str_len == 0)
12
    {
13
        epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL);
14
        close(fd);
15
        break;
16
    }
17
    else
18
    {
19
        if (errno == EAGAIN)
20
            break;
21

22
        /* 处理其他读取错误 */
23
        break;
24
    }
25
}

三种返回情况不能混为一谈：返回正数表示读到数据，返回$0$表示对方关闭连接，返回$-1$且$errno$为$EAGAIN$才表示本轮数据已经读完、以后仍可继续等待新事件。

WARNING

边缘触发的重点不是简单添加$EPOLLET$。若没有同时使用非阻塞$I/O$并把当前数据读到$EAGAIN$，程序很容易遗漏缓冲中的剩余内容，或者因阻塞调用停住整个服务器。

边缘触发的应用意义#

边缘触发减少了同一就绪状态的重复通知，也让程序更容易把“接收数据”和“处理数据”拆开。事件到来时，可以先把内核输入缓冲中的数据完整读入应用层缓冲，再根据业务需要排序、组合或稍后处理。

图中客户端$A$、$B$、$C$可能以任意顺序发送数据，服务器可以先接收并保存它们，再按$A$、$B$、$C$的顺序组合后转发。网络数据到达的时间与业务处理的时间不必完全一致。

若在条件触发模式下长期不读取内核缓冲中的数据，$epoll\_wait$会反复返回同一可读事件；边缘触发则更适合先把数据从内核缓冲转移出来，再由程序自行决定处理时机。不过，这也把“必须读完当前数据”和管理应用层缓冲的责任交给了程序。

边缘触发更有机会减少无效唤醒并构建高性能事件循环，但不能简单理解为“边缘触发一定比条件触发快”。条件触发更容易编写和验证，边缘触发则提供更细的事件控制。最终仍应根据程序结构、正确性要求和实际负载选择。