이 글은 Node.js의 이벤트루프를 이해하는 데 도움이 될 것입니다.

메인 스레드는 "작업 대기열"에서 이벤트를 읽습니다. 이 프로세스는 순환적이므로 전체 작동 메커니즘을 이벤트 루프라고도 합니다. 다음 글은 Node.js의 eventloop를 익히는 데 도움이 될 것입니다.

사실 이전 글에서 브라우저의 이벤트루프에 대해서도 이야기한 적이 있습니다. 그러나 NodeJs의 이벤트루프는 브라우저의 이벤트루프와 다릅니다. eventloop를 마스터하는 것은 nodejs를 작성하는 사람들에게 매우 중요한 기술입니다. 이는 js를 작성할 수 있을 뿐만 아니라 NodeJ도 공부할 수 있다는 것을 의미하기 때문입니다.

이벤트루프가 왜 있나요?

NodeJs의 본질은 브라우저의 v8을 운영 체제에서 실행하도록 이동하여 브라우저의 이벤트 루프도 대신하는 것임을 알고 있습니다. 그런데 왜 eventloop 같은 디자인이 나타나는 걸까요?

역사적인 관점에서 볼 때, js는 페이지에서 DOM을 운영하기 위한 매우 간단한 언어로 설계되었습니다(JS가 단 10일 만에 설계되었다는 이야기는 다들 들어보셨을 거라 믿습니다). 이 목표를 위해 우리는 js의 실행이 가능한 한 간단하고 가벼워지기를 바랍니다. js만큼 가벼운 렌더링 엔진은 스레드에서 실행됩니다.

그런 다음 문제가 발생합니다. 스레드에서 js를 실행하면 코드가 선형이면 물론 문제가 없습니다. 하지만 페이지에서는 사용자 상호작용이 필요하며 이러한 상호작용은 왜, 언제 발생하는지 알 수 없습니다. js를 어떻게 처리하나요? 실행 중인 코드가 앞에 있다면 사용자가 상호 작용할 때 프로그램은 어떻게 반응해야 할까요? 사용자 상호 작용이 먼저 처리되면 원래 프로그램이 일시 중지(즉, 차단)됩니다. 이러한 종류의 차단을 피하기 위해 js는 이러한 종류의 사용자 상호 작용을 저장하기 위해 메시지 대기열을 사용하는 방법을 채택합니다. 모든 프로그램 실행이 완료된 후 메시지 대기열로 이동하여 상호 작용 이벤트를 가져온 다음 실행합니다. 이렇게 하면 차단 문제가 해결됩니다.

브라우저 이벤트 루프

우리 모두는 브라우저가 페이지를 탐색할 때 사용자에게 즉시 응답하기 위해 언제든지 사용자 상호 작용이 발생할 수 있다는 것을 알고 있습니다. Node.js는 닫히지 않고 계속 반복됩니다. 대략 다음과 같습니다:

向消息队列拿任务-->执行任务-->执行完毕--> 向消息队列拿任务--> ....

물론 이전 이벤트 루프 기사에서 다양한 비동기 작업을 분류하기 위해 실제로 이벤트 루프에서 매크로 작업과 마이크로 작업을 구분한다고 언급했습니다. 실행은 대략

向消息队列拿微任务-->执行微任务-->微任务执行完毕--> 向消息队列拿宏任务-->执行宏任务-->宏任务执行完毕-->向消息队列拿微任务-->...

NodeJs의 이벤트 루프

node의 이벤트 루프는 실제로 브라우저의 이벤트 루프와 유사하지만 nodeJ는 서로 다른 시간에 서로 다른 매크로 작업을 구별합니다. 다음은 공식 흐름도입니다.

nodeJs의 각 이벤트 루프는 6개의 특정 기간으로 나뉘며 각 기간은 지정된 매크로 작업을 사용하는 것을 볼 수 있습니다. 그런 다음 각 기간의 매크로 작업이 실행되기 전에 마이크로 작업 대기열이 먼저 실행됩니다. ㅋㅋㅋ 콜백 종료 s

다음 루프까지 실행이 지연됩니다. 반복 I/O 콜백

idle, prepare에 주의를 기울일 수 없습니다. 콜백(거의 모든 콜백이 실행됩니다. 타이머에 의해 예약된 닫기 콜백과 setImmediate()에 의해 예약된 콜백은 적절한 시간에 이 단계에서 차단됩니다.)setImmediate( )콜백 닫기예: socket.on('close', ...)

은 내부적으로만 사용되며 개발자는 새로운 I/O 이벤트를 검색하기 위한

poll

check

Execution

其实通过上述表格，我们已经很清晰知道整个事件循环机制的执行顺序了。但可能大家还会有一些疑问。下面来详细讲一下。

pending callbacks

这个阶段其实是处理由于操作系统出错，导致一些本应在上次事件循环中执行的回调。例如一些TCP错误。因此这部分，开发者不能主动操作，是NodeJs的一些容错机制。

check

同样的，setImmediate是nodejs特有的api，他可以立即创建一个异步宏任务。不仅如此，nodejs在事件循环中还专门设了一个check时期，在这个时期会专门执行setImmediate的回调。甚至你可以在这个时期中如果不停的产生setImmediate回调，eventloop会优先处理。

close callbacks

这个时期处理关闭事件，如socket.on('close', ...) 等这样可以确保在一些通讯结束前，所有任务都完成了。

微任务在eventloop中

我们先来回顾浏览器与nodejs的差异：

宏任务：

任务	浏览器	Node
I/O	✅	✅
setTimeout	✅	✅
setInterval	✅	✅
setImmediate	❌	✅
requestAnimationFrame	✅	❌

微任务：

任务	浏览器	Node
process.nextTick	❌	✅
MutationObserver	✅	❌
Promise.then catch finally	✅	✅

可以看到process.nextTick是nodejs特有的微任务，不仅如此，process.nextTick()的优先级高于所有的微任务,每一次清空微任务列表的时候，都是先执行 process.nextTick()

执行差异

不仅是任务类型上有差异，在执行上2个环境其实也有差异。在浏览器上执行任务的时候，每执行一个宏任务之前，需要先确保微任务队列执行完了。而在nodejs上是每个时期之前，先确保微任务队列执行完。也就是说在假如在timer时期，会先把所有setTimeout，setInterval的宏任务执行完。在执行完微任务，再进入下个时期。

注意：以上执行规则是在nodejs的v11版本之前的规则。在11版本之后nodejs的执行输出是跟浏览器一样的。

setImmediate() vs setTimeout()

setImmediate() 和 setTimeout()的执行先后顺序是不一定的，就是说如果你不停地执行以下代码，每次得到的结果可能是不一样的。

setTimeout(() => {
  console.log('timeout');
}, 0);

setImmediate(() => {
  console.log('immediate');
});

其中的原因是程序对时间的处理是有误差的。在setTimeout方法中设置的时间，不一定是准确的。同时在回调触发时，也无法确认事件循环处在哪个时期，可能是timer，也可能是check。所有会有不同的结果。

总结

eventloop是js运行机制里的重点内容，对于NodeJs来说，eventloop的操作空间则更大。因为它被细分为不同的时期，从而让我们可能把逻辑进一步细化。同时利用nextTick的最高优先级，可以写出在浏览器无法实现的代码。因此对于深入NodeJs的开发者来说，eventloop往往是他们考察新人对NodeJs理解的第一步。

更多node相关知识，请访问：nodejs 教程！！

위 내용은 이 글은 Node.js의 이벤트루프를 이해하는 데 도움이 될 것입니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!