브라우저 UI 멀티스레딩 및 JavaScript 단일 스레드 기본 작동 메커니즘에 대한 이해

저는 JavaScript를 처음 배웠을 때부터 이 아이디어에 "세뇌"되었습니다.

JavaScript는 단일 스레드입니다
그러나 학습을 계속하면서 process
타이머와 ajax의 비동기 로딩에 대해 배웠습니다
한 번 이 문장을 의심하게 되었습니다
JavaScript는 단일 스레드인데 왜 여전히 비동기 로딩이 있나요?
나중에 브라우저에 js 스레드만 있는 것이 아니라 다른 스레드와 함께 있다는 것을 알게 되었습니다. - 브라우저 UI 멀티스레딩

오래 전부터 글을 쓰고 싶었습니다. 이렇다 보니 제가 충분히 이해하지 못한 것 같고, 제가 쓴 글이 여러분을 오해하게 할까봐 두려웠습니다
인터넷에 올라온 모든 사람들이 쓴 블로그 글을 다 읽고 나니 더욱 혼란스러워졌습니다
그런데 결국 용기를 내어 이야기를 나눠보기로 했습니다. ╮(╯_╰)╭
자바스크립트 스레드 문제는 잠시 접어두고 먼저 브라우저 UI 스레드가 무엇인지 살펴보겠습니다

브라우저 UI 멀티스레딩

먼저 이전 그림으로 가보겠습니다

일반적으로 브라우저에는 최소 3개의 상주 스레드가 있습니다

• GUI 렌더링 스레드(렌더링 페이지)

• JS 엔진 스레드(스크립트 처리)

• 이벤트 트리거 스레드 (제어 상호작용)

가끔 새 스레드를 여는 브라우저 포함(예: Ajax) 사용 후 버려지고 다른 스레드
이들은 함께 브라우저의 UI 스레드를 구성합니다
이 스레드는 UI 스레드의 제어 하에 질서 있게 작동합니다
이 상주 스레드에 대한 온라인 의견은 일관되지 않으며 구현 각 브라우저마다 다를 수 있으므로 여기에서는 다루지 않겠습니다.

js 엔진 스레드를 오른쪽 하단에 넣었지만 브라우저의 메인 스레드입니다
그리고 호환되지 않습니다. GUI 렌더링 스레드와 동시에 작업할 수 없으며
이유는 간단합니다. 왜냐하면 모두 DOM에서 작동하기 때문입니다. js 스레드가 특정 DOM 스타일을 원하면 렌더링 엔진이 작동을 중지해야 합니다(압도적인 대통령이 요청합니다). 거기 서서 움직이지 마세요)

js 싱글 스레드

JavaScript가 싱글 스레드인 이유
싱글 스레드는 동시에 한 가지 작업만 수행할 수 있다는 의미입니다
그렇다면 JavaScript의 멀티스레딩은 나쁘지 않습니까? 얼마나 효율적인가요?
좋지 않습니다
js는 DOM 처리
JavaScript가 멀티스레딩인 경우 다음을 처리해야 합니다. 멀티 스레드 동기화 문제 (C++ 스레드 동기화가 지배하는 공포를 어렴풋이 기억합니다)
js가 멀티 스레드이고 한 스레드가 동시에 DOM을 수정하려고 하면 다른 스레드가 해당 DOM을 삭제하려고 할 때 DOM
, 문제는 훨씬 더 복잡해집니다. 브라우저는 누구의 말을 들어야 할지 모릅니다. "잠금" 메커니즘이 도입되면 매우 번거로울 것입니다(그렇다면 프런트엔드를 배우지 않겠습니다(￣). _, ￣ )) ​​
그래서 우리처럼 스크립팅 언어가 그렇게 복잡할 필요는 없기 때문에 자바스크립트는 탄생부터 싱글스레드였습니다

H5가 Web Worker를 제안했지만, DOM이므로 이를 해결하려면 여전히 큰형님을 js 메인 스레드에 맡겨야 합니다
저는 이 Web Worker에 대해 잘 모르므로 여기서는 많이 말하지 않겠습니다
이 하위 스레드는 완전히 메인 스레드 빅 브라더에 의해 제어되므로 JavaScript의 단일 스레드 특성을 변경하지 않습니다

실행 스택

먼저 실행 스택이 무엇인지 살펴보겠습니다
스택 FILO(선입 후출) 데이터 구조
실행 스택은 실행 중인 작업을 저장하며, 각 작업을 "프레임"이라고 합니다.
예를 들어

function foo(c){
    var a = 1;
    bar(200);
}function bar(d){
    var b = 2;
}
foo(100);

한 번 살펴보겠습니다. 실행 스택이 어떻게 바뀌었는지

• 처음에 코드가 실행되지 않을 때 스택은 빈 스택이다

• foo 함수가 실행되면 형식 매개변수와 지역 변수를 포함하는 프레임이 생성되고(사전 컴파일 프로세스) 이 프레임을

• 의 스택에 푸시한 다음 foo 함수의 코드를 실행합니다. , bar 함수

• 를 실행하여 형식 매개변수와 지역 변수도 포함하고 스택에 푸시되는 새 프레임을 생성합니다

• bar 함수가 실행되고 스택이 팝됩니다

• foo 함수가 실행되고 스택이 팝됩니다

• 실행 스택이 비어 있습니다

실행 스택은 실제로 js 메인 스레드와 동일합니다

작업 대기열

큐는 선입선출(FIFO)입니다. 데이터 구조
js 스레드에도 작업 대기열이 있습니다
작업 대기열에는 처리할 일련의 작업이 포함되어 있습니다
단일 스레드는 작업이 수행되는 경우 모든 작업을 차례로 실행해야 함을 의미합니다. 실행하는 데 시간이 너무 오래 걸리면 다음 작업을 기다려야 합니다
마치 간호사가 줄을 선 아이들에게 주사를 놓는 것과 같습니다. 앞에 있는 아이가 계속 바늘을 굴리면 주사는 계속되고 뒤에 있는 아이들은 계속됩니다. 기다려야 할 것입니다(이 비유는 적절하지 않은 것 같습니다)
그러나 앞에 있는 아이가 바늘에 맞아 기절하면
간호사 이모가 일어나면 뒤에 있는 아이에게 주사를 놓아야 합니다. 먼저
아이를 "시작"(비동기)하는 것과 같습니다.

그래서 작업은 두 가지 유형으로 나눌 수 있습니다

• 동기 작업

• 비동기 작업

同步任务就是正在主线程执行栈中执行的任务（在屋子内打针的小朋友）
而异步任务是在任务队列等候处理的任务（在屋子外等候打针的小朋友）
一旦执行栈中没有任务了，它就会从执行队列中获取任务执行

事件与回调

任务队列是一个事件的队列，IO设备（输入/输出设备）每完成一项任务，就会在任务队列中添加事件处理
用户触发了事件，也同样会将回调添加到任务队列中去
主线程执行异步任务，便是执行回调函数（事件处理函数）
只要执行栈一空，排在执行队列前面的会被优先读取执行，
不过主线程会检查时间，某些事件需要到了规定时间才能进入主线程处理（定时器事件）

事件循环

主线程从执行队列不断地获取任务，这个过程是循环不断地，叫做“Event Loop”事件循环
同步任务总是会在异步任务之前执行
只有当前的脚本执行完，才能够去拿任务队列中的任务执行
前面也说到了，任务队列中的事件可以是定时器事件
定时器分为两种 setTimeout() 和 setInterval()
前者是定时执行一次，后者定时重复执行
第一个参数为执行的回调函数，第二个参数是间隔时间（ms）
来看这样一个例子

setTimeout(function(){
    console.log('timer');
},1000);console.log(1);console.log(2);console.log(3);

这个没什么问题，浏览器打印的是 1 2 3 timer
但是这样呢

setTimeout(function(){
    console.log('timer');
},0);//0延时console.log(1);
console.log(2);
console.log(3);

浏览器打印依然打印的是 1 2 3 timer
也许有同学知道，旧版浏览器，setTimeout定时至少是10ms（即便你设置了0ms），
H5新规范是定时至少4ms（我读书少不知道为什么），改变DOM也是至少16ms
也许这是因为这个原因
那么我再改动一下代码

setTimeout(function(){
    console.log('timer');
},0);var a = +new Date();for(var i = 0; i < 1e5; i++){
    console.log(1);
}var b = +new Date();
console.log(b - a);

这回够刺激了吧，输出10w次，我浏览器都假死了（心疼我chrome）
不仅如此，我还打印了循环所用时间
来看看控制台

输出了10w个1，用了将近7s
timer依然是最后打印的
这就证明了我前面说的话: 同步任务总是会在异步任务之前执行
只有我执行栈空了，才会去你任务队列中取任务执行

实例

最后我举一个例子加深一下理解

demo.onclick = function(){
    console.log('click');
}function foo(a){
    var b = 1;
    bar(200);
}function bar(c){
    var d = 2;
    click//伪代码 此时触发了click事件（这里我假装程序运行到这里手动点击了demo）
    setTimeout(function(){
        console.log('timer');
    }, 0);
}
foo(100);

怕大家蒙我就不写Ajax了
Ajax如果处理结束后（通过Http请求线程），也会将回调函数放在任务队列中
还有一点click那一行伪代码我最开始是想用demo.click()模拟触发事件
后来在测试过程中，发现它好像跟真实触发事件不太一样
它应该是不通过触发事件线程，而是存在于执行栈中，就相当于单纯地执行click回调函数
不过这只是我自己的想法有待考证，不过这不是重点，重点是我们理解这个过程，请大家不要吐槽我╰(￣▽￣)╭

下面看看执行这段代码时发生了什么（主要说栈和队列的问题，不会赘述预编译过程）

• 主线程开始执行，产生了栈、堆、队列

• demo节点绑定了事件click，交给事件触发线程异步监听

• 执行foo函数（之前同样有预编译过程），创建了帧包括foo函数的形参、局部变量压入执行栈中

• foo函数内执行bar函数，创建帧包括bar函数的形参、局部变量压入执行栈中

• 触发了click事件，事件触发线程将回调事件处理函数放到js线程的任务队列中

• 触发了定时器事件，事件触发线程立即（4ms）将回调处理函数放到js线程的任务队列中

• bar函数执行完毕，弹出栈

• foo函数执行完毕，弹出栈

• 此时执行栈为空

• 执行栈向任务队列中获取一个任务：click回调函数，输出‘click’

• 执行栈项任务队列中获取一个任务：定时器回调函数，输出‘timer’

• 执行结束

这里从任务队列里不断取任务的过程就是Event Loop

有一些我的理解，如果发现不对或者有疑问的地方，请联系我
相信大家看了这个例子应该对js底层运行机制有了一个大概的了解

 以上就是브라우저 UI 멀티스레딩 및 JavaScript 단일 스레드 기본 작동 메커니즘에 대한 이해及对JavaScript单线程底层运行机制的理解的内容，更多相关内容请关注PHP中文网（www.php.cn）！