NodeJS事件循环单轮迭代各阶段回调硬限制及队列查询问题

NodeJS事件循环的每一个周期，都会同步处理各阶段队列中排队的回调，且每个阶段单次执行的回调数量存在上限。

根据NodeJS官方文档说明：

当事件循环进入某个指定阶段时，会先执行该阶段对应的特定操作，之后执行该阶段队列中的回调，直到队列被清空，或是已执行的回调数量达到上限为止。

事件循环阶段顺序：timers --> pending callbacks --> idle, prepare --> poll --> check --> close callbacks

例如poll阶段的回调上限由libuv设定：

为避免poll阶段长期占用资源导致事件循环饥饿，作为实现Node.js事件循环及平台所有异步行为的C语言库，libuv设置了系统相关的硬上限，达到该上限后就会停止轮询更多事件。

1. 各阶段回调执行硬限制数值的查询渠道 #

没有面向应用开发者的公开官方文档会公示固定的限制数值，这类数值属于libuv内部实现细节，会随版本、运行操作系统动态调整，不属于对外承诺的稳定API。
如果需要确认对应环境下的具体数值，唯一可靠的渠道是查阅对应Node.js版本依赖的libuv源码：

• 跨阶段通用的回调计数截断逻辑在libuv源码根目录的src/uv-common.c中定义，对应uv_run函数的主循环逻辑
• timers阶段的处理上限在平台相关的src/unix/timer.c、src/win/timer.c文件中，新版本不再使用固定计数上限，改为结合最大执行时间片动态截断
• poll阶段的硬限制在各平台的IO多路复用适配层定义：Linux平台在src/unix/linux-core.c中，默认和epoll单次返回的最大事件数对齐，数值为1024；Windows平台在src/win/winpoll.c中，对应IOCP单次处理的最大事件数，默认值为512；macOS/BSD平台在src/unix/kqueue.c中定义对应数值
• pending callbacks、idle/prepare、check、close callbacks阶段没有固定的计数硬上限，默认会清空当前队列中所有就绪的回调，仅在事件循环整体执行时间超过阈值时才会截断进入下一轮循环

2. 可编程获取各阶段回调队列长度的方式 #

原生Node.js没有提供稳定的公开API支持直接读取libuv内部维护的各阶段队列长度，这些队列属于运行时内部结构体，默认不对JS层暴露。
如果是调试场景需要获取近似值，可以通过以下方式实现：

• 开启async_hooks模块，监听异步资源的初始化、销毁、回调执行事件，自行维护不同类型异步任务的计数，间接统计对应阶段的待执行回调数量，注意这种方式统计的结果有一定延迟，和libuv内部实时队列长度存在偏差
• 使用Node.js内置的inspector协议，对接调试工具，可以在调试面板中看到各阶段异步任务的排队数量，但该能力仅用于调试，不适合生产环境调用
• 不要在生产环境使用任何直接读取libuv私有结构体的第三方扩展包，这类实现跨版本、跨平台兼容性极差，很容易导致进程崩溃。

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