在Ruby 3引入的非阻塞光纤调度模型中，Fiber.scheduler承担了事件循环的调度职责。当业务代码里混入了未经过调度器封装的阻塞系统调用，整个线程的事件处理就会被拖死。要识别这些违规点，可以借助IO.select在调度器层面做前置探测。
为什么阻塞调用会破坏Fiber调度
Fiber.scheduler的设计目标是让所有IO等待都变成可让出（yield）的操作。例如常见的Socket读写的非阻塞版本，会通过scheduler的read方法注册等待，并在就绪后被唤醒。但如果一个Fiber直接调用了底层C扩展或未经包装的阻塞方法，比如普通的IO#read在没有调度器钩子介入时，线程会陷入内核睡眠，其他Fiber无法运行。
这种问题在代码评审时很难发现，因为方法名看起来和普通IO操作无异。只有在高并发压测下，事件循环吞吐量突然断崖式下跌，才会暴露出某处隐藏的阻塞点。因此我们需要在调度器内部建立一套检测机制，在阻塞发生前拦截并报警。
IO.select的探测原理
IO.select是Ruby对操作系统select/poll的封装，它可以传入一组IO对象，询问它们是否可读、可写或出现异常，并指定等待超时。若超时设为0，则立即返回当前就绪的描述符。利用这个特性，在调度器即将执行某个IO相关钩子时，先用IO.select检查对应fd是否真的没就绪，如果没就绪却走了阻塞分支，就说明该调用未经过非阻塞改造。
需要注意的是，IO.select本身也是系统调用，频繁在热路径上调用会带来微小开销。但在检测阶段，我们可以只对标记为可疑的方法开启探测，生产环境再通过开关关闭，做到性能与可观测性的平衡。
自定义scheduler中的检测钩子
下面示例展示了如何重写Fiber.scheduler的read方法，在真正读取前用IO.select判断fd状态。若select报告不可读却仍调用了阻塞read，则抛出警告。
class DetectingScheduler
def initialize
@blocking_calls = []
end
def read(io, buffer, length)
fd = io.fileno
# 使用IO.select探活，超时0表示不等待
readable, = IO.select([io], nil, nil, 0)
if readable.nil?
# 描述符未就绪，但下方若直接阻塞读就是问题
@blocking_calls << caller_locations(1, 3)
warn "潜在阻塞读调用，fd=#{fd}"
end
# 这里仍走原逻辑，仅作检测演示
io.read_nonblock(length, buffer)
rescue IO::WaitReadable
# 交给调度器等待后重试
Fiber.yield
retry
end
end
上面的代码通过IO.select的零超时探活，在read_nonblock之前记录下了所有“未就绪却试图读”的栈帧。实际项目中可以把这些栈帧上报到日志系统，精准定位写错的地方。注意代码里字符串用了中文弯引号描述报警内容，避免破坏外部HTML结构。
这种方式的优势在于误报率低：只有确实在非就绪状态下触发了阻塞路径才会被捕获，而不像简单包裹超时那样，把正常异步等待也误判为阻塞。同时它直接运行在调度关键路径，不需要额外代理层。
与超时拦截方案的对比
另一种常见思路是为可疑调用设置thread级超时，超时即认为阻塞。但网络抖动或慢速客户端会让正常非阻塞操作偶尔超过阈值，产生大量误报。而IO.select是基于内核fd状态的真实反馈，只要事件循环本身没bug，探测结果就准确。
| 检测方式 | 原理 | 误报风险 | 性能影响 |
|---|---|---|---|
| 超时拦截 | 设定最大执行时间 | 高 | 低 |
| IO.select探活 | 查询fd真实就绪状态 | 低 | 中（系统调用开销） |
从表中可以看出，IO.select方案以轻微的系统调用成本为代价，显著降低了误报。对于需要长期运行的服务的稳定性排查，这种 trade-off 是值得的。
落地建议
建议在测试环境全局替换默认scheduler为带检测的版本，跑一遍核心链路，收集@blocking_calls里的栈信息。定位到具体方法后，将其改为使用调度器提供的非阻塞API，或显式使用read_nonblock配合Fiber.yield。修复完毕后，再切回标准调度器上线。
此外，团队可以封装一个lint规则，扫描直接调用IO#read、TCPSocket#recv等原生阻塞方法的代码，与运行期IO.select检测形成双重保障。这样从人和工具两端减少阻塞调用漏网之鱼。
IO_selectFiber_scheduler阻塞调用检测修改时间：2026-08-11 03:42:28