Node.js WriteStream基准测试疑问：缓冲与事件循环解析

1. 等待drain版本耗时更长的理解是否正确？ #

完全正确。

• 等待drain的逻辑会在WriteStream内部缓冲区达到水位线时暂停写入，直到内核缓冲区排空、触发drain事件后才继续。这段等待期间进程处于空闲状态，没有持续写入操作，自然会增加整体耗时。
• 直接持续写入的版本会尽可能把数据写入Node.js的用户态缓冲区，只要缓冲区没满就不会暂停，所有写入操作可以连续推进，因此整体耗时更短。但注意这种方式会占用更多内存，因为缓冲区会堆积更多待写入内核的数据。

2. 修改后内存飙升与监听超限的原因 #

(1) MaxListenersExceededWarning #

你每次进入水位线判断分支时，都给drain事件添加了新的监听函数，但没有移除旧的监听。Node.js默认对每个事件的监听数上限是10，当重复绑定的监听超过这个数量时就会触发警告。

(2) 内存占用飙升 #

确实是大量setTimeout导致的：每次进入分支都会创建一个新的定时器，每个定时器都会在内存中保留引用；同时，未完成的写入操作回调、堆积的缓冲区数据也会占用内存，多重因素叠加导致内存暴涨。

3. 事件循环相关疑问解析 #

Node.js事件循环不是必须等当前阶段队列空才处理定时器阶段，其执行逻辑是：

1. 事件循环按固定阶段顺序执行：timers → pending callbacks → idle/prepare → poll → check → close callbacks
2. 在poll阶段，Node.js会先处理队列中的事件（比如你的写回调），但不会无限制处理——要么处理完队列，要么达到系统设定的最大处理数。
3. 每次poll阶段的事件处理批次结束后，会检查是否有到期的定时器：
   • 如果有到期定时器，事件循环会立即切换回timers阶段，执行这些定时器的回调。
   • 即使poll队列里还有大量未处理的写回调，只要定时器到期时间到了，就会触发定时器阶段的处理。

这就是为什么你的写回调队列还没处理完，1秒后依然会出现监听超限警告：到期的定时器被触发，每个定时器回调又添加了新的drain监听，短时间内监听数就超过了上限。

内容的提问来源于stack exchange，提问作者Mathew