Linux timerfd 怎样避免定时器读事件丢失

在 Linux 事件循环里，timerfd 最容易被误读成“每次变成可读，就代表一个定时器周期”。真正的语义是：内核把自上次成功读取以来发生的到期次数累计起来，read 一次返回一个 uint64_t 计数。事件循环如果只做固定的 count++，忙了一段时间后就会把多个周期压成一个。

先区分“可读”与“到期次数”

调用 timerfd_create 得到的文件描述符可以交给 poll 或 epoll。周期定时器连续到期时，内核不会为每一次到期都排一条独立的字节流，而是维护一个到期计数。只要计数大于零，文件描述符就保持可读；一次成功的 read 会把当前累计值取走。

这意味着事件循环可能看到“只来了一次 POLLIN”，但随后读出 5。这不是五个通知丢成一个，而是五次到期被一个计数完整表达。适合做周期补偿的程序应据此推进逻辑；只想做“有事就唤醒”的程序，也至少要读掉计数，避免文件描述符一直保持可读。

read 必须接收完整的 uint64_t 计数

创建定时器时可以直接使用非阻塞和自动关闭标志，再设置首次到期时间与周期。下面的示例只展示计时器和一次读取的边界，不把示例输出伪装成真实运行结果。

#include 
#include 
#include 
#include 

int make_timerfd(void) {
    // 非阻塞让事件循环可以在没有新计数时立即返回。
    int fd = timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK | TFD_CLOEXEC);
    if (fd == -1) {
        return -1; // 创建失败时把 errno 留给调用方处理。
    }

    struct itimerspec spec = {0};
    spec.it_value.tv_sec = 1;       // 首次到期等待 1 秒。
    spec.it_interval.tv_sec = 1;    // 之后每 1 秒重复一次。
    if (timerfd_settime(fd, 0, &spec, NULL) == -1) {
        close(fd);                  // 设置失败时释放已创建的描述符。
        return -1;
    }
    return fd;
}

int consume_timerfd(int fd, uint64_t *expired) {
    // 内核返回的是累计到期次数，缓冲区必须容纳完整 uint64_t。
    ssize_t n = read(fd, expired, sizeof(*expired));
    if (n == (ssize_t)sizeof(*expired)) {
        return 1; // expired 可能大于 1，不能固定当成一次。
    }
    if (n == -1 && (errno == EAGAIN || errno == EWOULDBLOCK)) {
        return 0; // 当前没有新计数，回到 poll/epoll 等待。
    }
    if (n == -1 && errno == EINTR) {
        return 0; // 被信号打断时由外层循环重新等待并读取。
    }
    return -1; // 其他错误或异常长度需要记录并进入故障处理。
}

read 成功时的数值才是本轮应处理的周期数。若返回 EINTR，可以由外层事件循环重试；若返回 EAGAIN，则说明当前计数已经被读空。缓冲区小于 8 字节时，内核会返回 EINVAL，这通常是类型或长度写错，而不是定时器没有触发。

事件循环不要用固定加一掩盖积压

假设定时器周期为 100 毫秒，而处理线程被其他工作占用 550 毫秒。下一次唤醒时，读出的计数可能是 5 或 6，具体取决于到期时刻。正确的处理方式是记录这次计数，并明确业务策略：逐个补偿、合并为一次刷新，还是只关心“至少发生过”。

uint64_t expired = 0;
int status = consume_timerfd(timer_fd, &expired);
if (status == 1) {
    // 用累计数驱动补偿或统计，不把一次可读事件硬编码成 1。
    total_expired += expired;
    run_periodic_work(expired);
} else if (status == -1) {
    // 记录 errno 或异常长度，避免把真实读错误当成普通空闲。
    report_timer_read_failure(timer_fd);
}

如果业务不需要逐周期补偿，也可以把 expired 转成一次“需要刷新”的信号，但要保留累计数用于指标，否则线程偶发阻塞时无法知道积压程度。反过来，逐个补偿也不能无限追赶：应设置单轮上限，并把剩余积压交给下一轮，避免定时任务反过来拖垮事件循环。

上线前检查关闭、重置和监控边界

首先确认只由一个明确的消费方读取同一个 timerfd；多个线程或多个事件循环同时读，会让“谁消费了哪一批计数”变得难以解释。其次，在重置定时器前记录旧计数是否已经处理，避免把重置动作和业务丢失混在一起。最后，关闭文件描述符，尤其是创建失败或注册事件循环失败的分支。

建议至少记录三类指标：每次读出的累计次数、单轮处理次数上限和处理耗时。若累计次数频繁大于 1，说明处理线程经常落后于定时器周期；若出现读错误或计数长期不变，则分别检查描述符生命周期、事件注册和错误处理路径。这样能区分“内核正确合并了到期事件”和“程序根本没有消费事件”。

常见问题

一次 poll 返回可读，为什么 read 出来的不是 1？

因为 timerfd 返回的是自上次成功读取以来的累计到期次数。事件循环只保证有计数，不保证每个周期对应一个独立通知。

EAGAIN 是否说明定时器丢事件？

在非阻塞模式下，EAGAIN 表示这次读取时没有可用的新计数。应回到 poll/epoll 等待；真正需要关注的是成功读取的累计值和处理延迟。