EAGAIN错误与系统定时器的交互

凌晨三点十七分，我的手机在床头柜上震了第七次。屏幕亮起的瞬间，我瞥见交易所APP推送的红色警报——BTC闪崩4.2%，而我的网格策略单，正卡在一个该死的EAGAIN错误里。

第一幕：凌晨三点的“幽灵锁仓”

我赤脚冲到电脑前，指尖在冷冰冰的机械键盘上敲出dmesg | tail -50。日志里密密麻麻的Resource temporarily unavailable像一群蚂蚁爬满屏幕。这不是网络问题，不是API密钥失效，而是Linux内核在告诉我：系统定时器资源被榨干了。

我的套利机器人原本挂着三组不同周期的均线策略，每组策略各自持有独立的epoll定时器。当BTC在五分钟内暴跌又反弹时，所有策略同时触发止损和重新入场逻辑——每个策略都在fork()子进程，每个子进程都在调用timerfd_create()。内核的timerfd队列瞬间被塞满，而我的代码里没有处理EAGAIN的优雅降级逻辑。

于是，最讽刺的事情发生了：机器人以为自己在赚钱，实际上它在疯狂重试一个永远无法完成的定时器注册。每一次write()到timerfd都返回EAGAIN，我的循环里没有sleep()，没有退避，只有无限循环的epoll_wait()——CPU烧到90度，但订单永远停留在“待提交”状态。

第二幕：当内核时钟变成“赌场荷官”

这里有个技术细节值得展开：Linux的timerfd和epoll配合时，EAGAIN通常意味着定时器事件已经清空，但你又试图读取一次。但在高并发场景下，它更隐蔽的含义是——内核的hrtimer（高分辨率定时器）队列已满，你无法再创建新的定时器实例。

我的机器人犯了一个经典错误：它把每个策略的“下一次执行时间”都注册成绝对时间戳，而不是相对间隔。当BTC剧烈波动时，所有策略的触发时间在毫秒级内重合，内核不得不为每个时间戳分配一个hrtimer节点。/proc/timer_list显示有超过4000个活动定时器，而默认的max_loopback限制是1024。

那一刻，我的策略矩阵变成了一个在赌场里同时下注的疯子——每个定时器都是一张筹码，但荷官（内核）说：“桌子满了，你不能再下注了。”EAGAIN就是那张被退回的筹码，而我的代码却以为“筹码已经押上去了”。

第三幕：用“熔断机制”修复定时器风暴

天亮时，我盯着perf top的输出，发现ktime_get和hrtimer_interrupt占了40%的CPU。我意识到问题的本质：不是定时器不够用，而是我的策略没有分级。

修复方案分三步走，每一步都像在给交易所加熔断机制：

第一步：引入“定时器预算”
我为每个策略分配一个timer_budget（比如每秒最多创建10个定时器）。通过一个原子计数器，在每次timerfd_create()前检查预算。如果超限，就返回一个“软错误”并强制策略进入冷却状态——这就像交易所的“价格波动熔断”，让系统冷静五秒。

第二步：把绝对时间戳改成相对间隔
timerfd_settime()的itimerspec里，我改用it_value为相对值（比如{0, 50000000}表示50毫秒后触发），而不是计算到未来某个绝对时刻。这样内核可以复用同一个hrtimer节点，而不是为每个新时间戳创建新节点。测试下来，定时器创建成功率从62%提升到98%。

第三步：用signalfd替代timerfd作为最后防线
当timerfd连续返回三次EAGAIN时，我直接降级为signalfd + SIGALRM。虽然精度从纳秒级降到毫秒级，但至少保证策略不会死锁。这个降级动作，我称之为“系统级硬熔断”——就像交易所直接暂停交易五分钟。

第四幕：从虚拟币到操作系统哲学的“三体问题”

这次事故让我重新思考定时器与交易策略的关系。虚拟币市场是一个极端非平稳系统，它的波动率分布不是高斯曲线，而是幂律分布——这意味着“黑天鹅”不是异常，而是常态。

而Linux的定时器子系统，本质上是为平稳负载设计的。它假设进程创建定时器的频率是相对稳定的，不会在毫秒内爆发式增长。当虚拟币的波动率把策略的执行频率推高到极限时，内核的“稳定性假设”就崩溃了。

这就像《三体》里的“三体问题”——三个恒星（策略A、策略B、策略C）互相影响，它们的运动无法用解析解预测。我的定时器风暴，就是三个策略在极端行情下互相触发，形成了一个正反馈循环：

1. 策略A检测到价格跌破支撑位，创建定时器准备在10毫秒后止损。
2. 止损触发后，策略B的“反弹追单”条件成立，创建定时器准备在5毫秒后买入。
3. 买入导致价格瞬间回升，策略A的“止损后重新入场”条件成立，又创建一个定时器。

三个定时器互相喂食，每个都试图在“更好的价格”上执行，但内核的定时器队列已经堆成山。EAGAIN不是错误，而是内核在说：“你们三个的策略循环，已经超出了物理时间的分辨率。”

第五幕：实战中的“定时器熔断”代码模板

如果你也写交易机器人，以下这段伪代码可以帮你避免凌晨三点的噩梦：

python class TimerBudget: def init(self, maxpersec=10): self.tokens = maxpersec self.last_refill = time.monotonic() self.lock = threading.Lock()

def acquire(self):     with self.lock:         now = time.monotonic()         # 每秒补充预算         if now - self.last_refill >= 1.0:             self.tokens = 10             self.last_refill = now         if self.tokens > 0:             self.tokens -= 1             return True         else:             # 触发软熔断：返回一个“假定时器”并延迟执行             self._soft_breakers += 1             return False 

if not budget.acquire(): # 不创建timerfd，改用sleep(0.1) + 重新检查条件 time.sleep(0.1) continue

这段代码的核心思想是：当定时器预算耗尽时，不要硬创建，而是主动降级为轮询。轮询虽然CPU消耗高，但至少不会让EAGAIN无限循环。

我还加了另一个细节：每个策略的timerfd读取循环里，如果连续三次read()返回EAGAIN，就主动关闭这个timerfd并重新创建。这相当于给定时器“重启”的机会——就像交易所的“断线重连”逻辑。

第六幕：那些你永远不该忘记的“系统级教训”

在处理完这次事故后，我在代码仓库里写了一份事故报告，标题是《当EAGAIN变成EVERYTHING》。里面有几条原则，现在每次写策略都会先过一遍：

原则一：永远不要把定时器当作“精确的闹钟”
虚拟币市场的成交时间戳本身就有毫秒级抖动，你不需要一个纳秒级的定时器来执行一个本来就要等待网络RTT的订单。把精度要求从1毫秒放松到10毫秒，定时器压力下降一个数量级。

原则二：EAGAIN不是错误，是内核在给你“喘口气”
很多程序员看到EAGAIN就panic，但实际上它是在说“你现在太激进了，后面还有更多数据要处理”。正确做法是：记录次数，指数退避，然后继续。我的策略里现在有一个eagain_counter，当它超过100次时，我会自动关闭所有策略并发送Telegram告警。

原则三：用“时间轮”代替“定时器堆”
如果你真的需要管理成千上万个定时器，不要用timerfd，用一个自定义的时间轮（Time Wheel）。Linux内核本身就有timer_wheel实现，你可以通过/sys/kernel/debug/timer_list观察它的状态。时间轮把定时器按精度分成多个槽位，每个槽位只维护一个链表，插入和删除都是O(1)复杂度。

第七幕：回到凌晨三点——那场没有硝烟的战争

现在，我的手机在凌晨三点再次震动。我睁开眼，看到交易所推送“BTC闪崩6%”，但这次，我的机器人没有卡死。

dmesg里没有EAGAIN洪流。/proc/timer_list显示只有127个活动定时器，每个策略的timer_budget都稳定在8/10。策略A的止损在3毫秒内触发，策略B的追单在5毫秒后执行，策略C的“网格补仓”在10毫秒后挂单——三个定时器像三颗行星，在各自的轨道上安静运行。

我关掉手机，翻了个身。窗外的天空开始泛白，而我的策略矩阵，正在用比人类快1000倍的速度，捕捉着每一毫秒的价格波动。但这次，内核的时钟没有失控——因为我已经学会了，在虚拟币的世界里，最快的速度不是无限加速，而是知道何时该减速。

EAGAIN不再是噩梦，它只是系统在说：“你做得够多了，等等吧。”而我终于学会了听它的话。