브라우저 이벤트 루프에 대한 심층적인 살펴보기(코드 예제)
- 不言앞으로
- 2018-11-12 17:06:451893검색
이 기사는 브라우저 이벤트 루프(코드 예제)에 대한 심층적인 이해를 제공합니다. 이는 특정 참조 가치가 있습니다. 도움이 필요한 친구가 도움이 되기를 바랍니다.
브라우저의 이벤트 루프는 프런트엔드에 매우 익숙하고 매일 접하게 되는 것입니다. 하지만 저는 항상 그것을 암기해 왔습니다. 이벤트 작업 대기열은 매크로태스크와 마이크로태스크로 나누어집니다. 브라우저는 먼저 매크로태스크에서 작업을 꺼내 실행한 다음 마이크로태스크의 모든 작업을 실행하고 매크로태스크로 이동합니다. 실행을 위한 작업을 수행합니다..., 이 주기가 계속됩니다. 그런데 다음 코드에서는 SetTimeout이 매크로태스크에 속해 있어서 헷갈렸습니다. 위의 규칙에 따르면 setTimeout을 먼저 꺼내서 실행해야 하는데 실행 결과에 뺨을 맞았습니다.
<script>
setTimeout(() => {
console.log(1)
}, 0)
new Promise((resolve) => {
console.log(2)
resolve()
}).then(() => {
console.log(3)
})
// 我曾经的预期是：2 1 3
// 实际输出：2 3 1
</script>
다른 사람들의 작업 대기열 소개를 주의 깊게 읽은 후 동기적으로 실행되는 js 코드가 실제로는 매크로 작업이라는 것을 깨달았습니다(정확히 말하면 각 스크립트 태그의 코드는 매크로 작업입니다). 따라서 위의 규칙은 없음 매크로 작업을 먼저 꺼내서 실행하면 문제가 발생합니다.
인터넷의 많은 기사에서는 위와 같이 설명하고 있습니다. 저는 이것이 HTML의 이벤트 루프 사양이라고 항상 생각하고 있으므로 이를 기억해야 합니다. 최근에 Mr. Li Yincheng의 기사(기사 마지막에 있는 참조 링크 참조)를 읽고서야 이전에 읽은 기사가 브라우저의 멀티스레딩 모델을 명확하게 분석하지 않았다는 것을 갑자기 깨달았습니다. 브라우저의 멀티스레딩 모델의 관점에서 볼 때, 브라우저의 이벤트 루프는 위의 규칙을 기반으로 하며 실제로는 브라우저의 멀티스레딩 모델의 결과입니다.
매크로태스크의 본질
매크로태스크는 본질적으로 브라우저의 여러 스레드 간 통신을 위한 메시지 대기열입니다.
크롬에서 각 페이지는 프로세스에 해당하며 프로세스에는 js 스레드, 렌더링 스레드, io 스레드, 네트워크 스레드, 타이머 스레드 등 이러한 스레드 간의 통신은 상대방의 작업 큐에 작업(PostTask)을 추가하여 이루어집니다.
브라우저의 다양한 스레드는 무한 루프에서 실행됩니다. 각 스레드에는 자체 작업 대기열이 있으며, 스레드 자체 또는 다른 스레드는 PostTask를 통해 이러한 작업 대기열에 작업을 추가할 수 있습니다. 실행을 위해 자신의 작업 대기열에서 작업을 꺼내거나, 설정된 시간이 되거나 PostTask가 수행될 때 누군가 깨울 때까지 절전 상태를 유지합니다.
브라우저의 각 스레드는 끊임없이 자신의 작업 대기열에서 작업을 꺼내서 실행하고, 작업을 다시 꺼내고, 다시 실행하는 것이 무한 루프로 계속된다는 것을 간단히 이해하면 됩니다.
다음 코드를 예로 들어 보겠습니다.
<script>
console.log(1)
setTimeout(() => {
console.log(2)
}, 1000)
console.log(3)
</script>
먼저 스크립트 태그의 코드를 작업으로 js 스레드의 작업 대기열에 넣고 js 스레드를 깨운 다음 작업을 꺼냅니다. 그리고 실행됨
먼저 console.log(1)을 실행한 다음 setTimeout을 실행하고 타이머 스레드에 작업을 추가한 다음 console.log(3)을 실행합니다. 이때 js 스레드의 작업 대기열은 다음과 같습니다. 비어 있고 js 스레드는 절전 모드로 전환됩니다
약 1000ms 후에 타이머 스레드는 예약된 작업(타이머 콜백)을 js 스레드의 작업 큐에 추가하고 js 스레드는 다시 깨어나 예약된 콜백 함수를 실행합니다. 마지막으로 console.log(2)를 실행합니다.
소위 매크로태스크는 브라우저가 어떤 작업이 매크로태스크인지 정의하는 것을 의미하지 않는다는 것을 알 수 있습니다. 브라우저의 각 스레드는 자신의 작업 대기열을 충실히 순환하고 그 안에 있는 작업을 지속적으로 실행합니다.
microtask
브라우저의 멀티스레딩 모델로 인해 발생하는 "환상"인 매크로태스크와 비교하면, 마이크로태스크는 다른 스레드 PostTask의 작업이 아니라 현재 스레드에 속하는 큐입니다. Promise.then, MutationObserver 등 지연 실행(정확히 말하면 현재 실행 중인 동기화 코드 다음에 실행됩니다).
다음 코드를 예로 들어 보겠습니다.
<script>
new Promise((resolve) => {
resolve()
console.log(1)
setTimeout(() => {
console.log(2)
},0)
}).then(() => {
console.log(3)
})
// 输出：1 3 2
</script>
먼저 스크립트 태그의 코드를 작업으로 js 스레드의 작업 대기열에 넣고 js 스레드를 깨운 다음 작업을 꺼냅니다. 그리고 실행
새 Promise를 실행하고 Promise에서 해결합니다. 해결 후 Promise의 콜백 함수는 지연되어야 하는 작업으로 사용되며 현재 실행된 모든 동기화 코드 뒤에 배치됩니다.
그런 다음 실행합니다. setTimeout을 실행하고 타이머 스레드에 작업을 추가합니다
-
이 때 동기화 코드가 실행된 후 지연된 작업이 실행되는데, 이는 Promise의 당시 콜백 함수, 즉 console.log(3)입니다. 실행됨
마지막으로 js 스레드의 작업 대기열이 비어 있고 js 스레드가 진입합니다. Sleep 후 약 1000ms가 지나면 타이머 스레드는 예약된 작업(타이머 콜백)을 js 스레드의 작업 대기열에 추가하고 js 스레드는 다시 깨어나 예약된 콜백 함수, 즉 console.log(2)를 실행합니다.
总结
通过上面的分析，可以看到，文章开头提到的规则：浏览器先从macrotask取出一个任务执行，再执行microtask内的所有任务，接着又去macrotask取出一个任务执行...，并没有说错，但这只是浏览器执行机制造成的现象，而不是说浏览器按照这样的规则去执行的代码。
这篇文章中的所有干货都来自李银成大佬的文章，我只是按照自己的理解，做了简化描述，方便大家理解，也加深自己的印象。
最后，看了这篇文章，大家能够基于浏览器的运行机制，分析出下面代码的执行结果了吗（ps：不要用死记硬背的规则去分析哟）
console.log('start')
const interval = setInterval(() => {
console.log('setInterval')
}, 0)
setTimeout(() => {
console.log('setTimeout 1')
Promise.resolve()
.then(() => {
console.log('promise 3')
})
.then(() => {
console.log('promise 4')
})
.then(() => {
setTimeout(() => {
console.log('setTimeout 2')
Promise.resolve()
.then(() => {
console.log('promise 5')
})
.then(() => {
console.log('promise 6')
})
.then(() => {
clearInterval(interval)
})
}, 0)
})
}, 0)
Promise.resolve()
.then(() => {
console.log('promise 1')
})
.then(() => {
console.log('promise 2')
})
// 执行结果
/* start
promise 1
promise 2
setInterval
setTimeout 1
promise 3
promise 4
setInterval
setTimeout 2
promise 5
promise 6
*/
위 내용은 브라우저 이벤트 루프에 대한 심층적인 살펴보기(코드 예제)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!