从浏览器多进程到JS单线程，全面梳理了解JS运行机制

矫情吗；* 2022-12-31 03:24 171阅读 0赞

### 文章目录 ###

*  一、区分线程和进程
 *  二、浏览器是多进程的
 *  三、浏览器都包含哪些进程？
 *  四、浏览器多进程的优势
 *  五、重点是浏览器内核（渲染进程）
 *  六、为什么JS引擎是单线程的？
 *  七、Browser进程和Renderer进程的通信过程
 *  八、浏览器渲染流程
 *  九、从Event Loop谈JS的运行机制
 *  十、单独说说定时器
 *  十一、事件循环进阶：macrotask与microtask
 *  参考文章

# 一、区分线程和进程 #

如何区分线程和进程？先看看下面这个形象的比喻：

> 进程是一个工厂，线程是工厂中的工人。  
> 工厂有它的独立资源 - 工厂之间相互独立 - 工厂内有一个或多个工人 - 工人之间共享空间 - 多个工人协作完成任务。

如果是 windows 电脑中，可以打开任务管理器，可以看到有一个后台进程列表。对，那里就是查看进程的地方，而且可以看到每个进程的内存资源信息以及 cpu 占有率。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nc1Rpbmc_size_16_color_FFFFFF_t_70]  
所以，应该更容易理解了：进程是cpu资源分配的最小单位（系统会给它分配内存）。

> 进程是 cpu 资源分配的最小单位（是能拥有资源和独立运行的最小单位）。  
> 线程是 cpu 调度的最小单位（线程是建立在进程的基础上的一次程序运行单位，一个进程中可以有多个线程）。

不同进程之间也可以通信，不过代价较大。

现在，一般通用的叫法：单线程与多线程，都是指在一个进程内的单和多（所以核心还是得属于一个进程才行）。

# 二、浏览器是多进程的 #

理解了进程与线程了区别后，接下来对浏览器进行一定程度上的认识：（先看下简化理解）

浏览器是多进程的

浏览器之所以能够运行，是因为系统给它的进程分配了资源（cpu、内存）

简单点理解，每打开一个Tab页，就相当于创建了一个独立的浏览器进程。

关于以上几点的验证，请再第一张图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nc1Rpbmc_size_16_color_FFFFFF_t_70 1]  
图中打开了Chrome浏览器的多个标签页，然后可以在Chrome的任务管理器中看到有多个进程（一个主进程，以及每一个Tab页面分别有一个独立的进程）。

**注意**：在这里浏览器应该也有自己的优化机制，有时候打开多个tab页后，可以在Chrome任务管理器中看到，有些进程被合并了（所以每一个Tab标签对应一个进程并不一定是绝对的）。譬如打开多个空白标签页后，会发现多个空白标签页被合并成了一个进程，如图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nc1Rpbmc_size_16_color_FFFFFF_t_70 2]

# 三、浏览器都包含哪些进程？ #

**1.Browser进程（也叫控制进程）**

浏览器的主进程（负责协调、主控），只有一个。作用如下：

*  负责浏览器界面显示，与用户交互。如前进，后退等；
 *  负责各个页面的管理，创建和销毁其他进程；
 *  将Renderer进程得到的内存中的Bitmap，绘制到用户界面上；
 *  网络资源的管理，下载等；

**2.第三方插件进程**

每种类型的插件对应一个进程，仅当使用该插件时才创建。

**3.GPU进程**

最多一个，用于3D绘制等。

**4.浏览器渲染进程（也叫浏览器内核 / Renderer进程）**

其内部是多线程的。默认每个Tab页面一个进程，互不影响。作用如下：

页面渲染，脚本执行，事件处理等（这些后面重点讲）。

# 四、浏览器多进程的优势 #

相比于单进程浏览器，多进程有如下优点：

*  避免单个page crash影响整个浏览器；
 *  避免第三方插件crash影响整个浏览器；
 *  多进程充分利用多核优势；
 *  方便使用沙盒模型隔离插件等进程，提高浏览器稳定性；

简单点理解：如果浏览器是单进程，那么某个Tab页崩溃了或者插件崩溃了，就影响了整个浏览器。

当然，内存等资源消耗也会更大，有点空间换时间的意思。

# 五、重点是浏览器内核（渲染进程） #

重点来了，我们可以看到，上面提到了这么多的进程，那么，对于普通的前端操作来说，最终要的是什么呢？答案是渲染进程。

> 浏览器的渲染进程是多线程的。

渲染进程的主要常驻线程：

**1.GUI渲染线程**

*  负责渲染浏览器界面，解析HTML，CSS，构建DOM树和RenderObject树，布局和绘制等；
 *  当界面需要重绘（Repaint）或由于某种操作引发回流(reflow)时，该线程就会执行；

**2.JS引擎线程（JS内核）**

*  负责处理Javascript脚本程序（例如V8引擎）；
 *  负责解析Javascript脚本，运行代码；
 *  JS引擎一直等待着任务队列中任务的到来，然后加以处理，一个Tab页（renderer进程）中无论什么时候都只有一个JS线程在运行JS程序；

> 注意，**GUI渲染线程与JS引擎线程是互斥的**，当JS引擎执行时GUI线程会被挂起（相当于被冻结了），GUI更新会被保存在一个队列中等到JS引擎空闲时立即被执行。  
> 所以如果JS执行的时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞。

**3.事件触发线程**

*  归属于浏览器而不是JS引擎，用来控制事件循环（可以理解，JS引擎自己都忙不过来，需要浏览器另开线程协助）；
 *  当JS引擎执行代码块如setTimeOut时（或是来自浏览器内核的其他线程，如鼠标点击、AJAX异步请求等），会将对应任务添加到事件线程中；
 *  当对应的事件符合触发条件被触发时，该线程会把事件添加到待处理队列的队尾，等待JS引擎的处理；
 *  注意，由于JS的单线程关系，所以这些待处理队列中的事件都得排队等待JS引擎处理（当JS引擎空闲时才会去执行）；

**4.定时触发器线程**

*  传说中的setInterval与setTimeout所在线程；
 *  浏览器定时计数器并不是由JavaScript引擎计数的（因为JavaScript引擎是单线程的，如果处于阻塞线程状态就会影响记计时的准确）；
 *  因此通过单独线程来计时并触发定时（计时完毕后，添加到事件队列中，等待JS引擎空闲后执行）；
 *  注意，W3C在HTML标准中规定，规定要求setTimeout中低于4ms的时间间隔算为4ms；

**5.异步http请求线程**

*  XMLHttpRequest在连接后是通过浏览器新开一个线程请求；
 *  将检测到状态变更时，如果设置有回调函数，异步线程就**产生状态变更事件**，将这个回调再放入事件队列中。再由JavaScript引擎执行。

# 六、为什么JS引擎是单线程的？ #

JavaScript 语言的一大特点就是单线程，也就是说，同一个时间只能做一件事。那么，为什么JavaScript 不能有多个线程呢 ？这样能提高效率啊。

JavaScript 的单线程，与它的用途有关。作为浏览器脚本语言，JavaScript 的主要用途是与用户互动，以及操作 DOM。这决定了它只能是单线程，否则会带来很复杂的同步问题。比如，假定JavaScript 同时有两个线程，一个线程在某个 DOM 节点上添加内容，另一个线程删除了这个节点，这时浏览器应该以哪个线程为准？

所以，为了避免复杂性，从一诞生，JavaScript 就是单线程，这已经成了这门语言的核心特征，将来也不会改变。

为了利用多核 CPU 的计算能力，HTML5 提出 Web Worker 标准，允许 JavaScript 脚本创建多个线程，但是子线程完全受主线程控制，且不得操作 DOM。所以，这个新标准并没有改变 JavaScript 单线程的本质。

# 七、Browser进程和Renderer进程的通信过程 #

看到这里，应该对浏览器内的进程和线程都有一定理解了，那么接下来，再谈谈浏览器的Browser进程（浏览器主控进程）是如何和Renderer进程（浏览器内核）通信的。这点也理解后，就可以将这部分的知识串联起来，从头到尾有一个完整的概念。

如果自己打开任务管理器，然后打开一个浏览器，就可以看到：任务管理器中出现了两个进程（一个是主控进程，一个则是打开Tab页的渲染进程），然后在这前提下，简单看下整个通信过程：

*  Browser进程收到用户请求，首先需要获取页面内容（譬如通过网络下载资源），随后将该任务通过RendererHost接口传递给Render进程；
 *  Renderer进程的Renderer接口收到消息，简单解释后，交给渲染线程，然后开始渲染；
 *  渲染线程接收请求，加载网页并渲染网页，这其中可能需要Browser进程获取资源和需要GPU进程来帮助渲染；
 *  当然可能会有JS线程操作DOM（这样可能会造成回流并重绘）；
 *  最后Render进程将结果传递给Browser进程；
 *  Browser进程接收到结果并将结果绘制出来；  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nc1Rpbmc_size_16_color_FFFFFF_t_70 3]

看完这一整套流程，应该对浏览器的运作有了一定理解了，这样有了知识架构的基础后，后续就方便往上填充内容。

# 八、浏览器渲染流程 #

为了简化理解，前期工作直接省略成：（要展开的或完全可以写另一篇超长文）

> 浏览器输入url，浏览器主进程接管，开一个下载线程，然后进行http请求（略去DNS查询，IP寻址等等操作），然后等待响应，获取内容，随后将内容通过RendererHost接口转交给Renderer进程，浏览器渲染流程开始。

浏览器器内核拿到内容后，渲染大概可以划分成以下几个步骤：

*  解析html建立dom树；
 *  解析css构建render树（将CSS代码解析成树形的数据结构，然后结合DOM合并成render树）；
 *  布局render树（Layout/reflow），负责各元素尺寸、位置的计算；
 *  绘制render树（paint），绘制页面像素信息；
 *  浏览器会将各层的信息发送给GPU，GPU会将各层合成（composite），显示在屏幕上。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nc1Rpbmc_size_16_color_FFFFFF_t_70 4]

渲染完毕后就是load事件了，之后就是自己的JS逻辑处理了。

下面提一些可能需要注意的细节：

**1.load事件与DOMContentLoaded事件的先后**

上面提到，渲染完毕后会触发load事件，那么你能分清楚load事件与DOMContentLoaded事件的先后么？

当 DOMContentLoaded 事件触发时，仅当DOM加载完成，不包括样式表，图片。(譬如如果有async加载的脚本就不一定完成)

当 onload 事件触发时，页面上所有的DOM，样式表，脚本，图片都已经加载完成了。（渲染完毕了）

所以，顺序是：DOMContentLoaded => load

**2.css加载是否会阻塞dom树渲染？**

这里说的是头部引入css的情况。

首先，我们都知道：**css是由单独的下载线程异步下载的**。

然后再说下几个现象：

> **css加载不会阻塞DOM树解析**（异步加载时DOM照常构建），**但会阻塞render树渲染**（渲染时需等css加载完毕，因为render树需要css信息）

这可能也是浏览器的一种优化机制。

因为你加载css的时候，可能会修改下面DOM节点的样式，如果css加载不阻塞render树渲染的话，那么当css加载完之后，render树可能又得重新重绘或者回流了，这就造成了一些没有必要的损耗。

所以干脆就先把DOM树的结构先解析完，把可以做的工作做完，然后等你css加载完之后，在根据最终的样式来渲染render树，这种做法性能方面确实会比较好一点。

**3.普通图层和复合图层**

渲染步骤中就提到了composite概念。可以简单的这样理解，浏览器渲染的图层一般包含两大类：普通图层以及复合图层。

*  首先，普通文档流内可以理解为一个复合图层（这里称为默认复合层，里面不管添加多少元素，其实都是在同一个复合图层中）；
 *  其次，absolute布局（fixed也一样），虽然可以脱离普通文档流，但它仍然属于默认复合层；
 *  然后，可以通过**硬件加速**的方式，声明一个新的复合图层，它会单独分配资源（当然也会脱离普通文档流，这样一来，不管这个复合图层中怎么变化，也不会影响默认复合层里的回流重绘）；

可以简单理解下：GPU中，各个复合图层是单独绘制的，所以互不影响，这也是为什么某些场景硬件加速效果一级棒。

**注意：**

> 一般一个元素开启硬件加速后会变成复合图层，可以独立于普通文档流中，改动后可以避免整个页面重绘，提升性能；  
> 但是，尽量不要大量使用复合图层，否则由于资源消耗过度，页面反而会变的更卡；

# 九、从Event Loop谈JS的运行机制 #

浏览器页面初次渲染完毕后，就到了JS引擎的一些运行机制分析。

在了解JS运行机制之前，我们先看一个问题：

**JavaScript是单线程，怎样执行异步的代码 ？**

单线程就意味着，所有任务需要排队，前一个任务结束，才会执行后一个任务。如果前一个任务耗时很长，后一个任务就不得不一直等着。

js 引擎执行异步代码之所以不用等待，是因有为有消息队列和事件循环。

> 消息队列：消息队列（也叫任务队列）是一个先进先出的队列，它里面存放着各种消息（任务）。  
> 事件循环：事件循环是指主线程重复从消息队列中取消息、执行的过程。

实际上，主线程只会做一件事情，就是从消息队列里面取消息、执行消息，再取消息、再执行。当消息队列为空时，就会等待直到消息队列变成非空。而且主线程只有在将当前的消息执行完成后，才会去取下一个消息。这种机制就叫做事件循环机制，取一个消息并执行的过程叫做一次循环。

那么，消息队列中放的消息具体是什么东西？我们可以认为：

> 消息就是注册异步任务时添加的回调函数。

**总结：**

*  JS分为同步任务和异步任务；
 *  同步任务都在主线程上执行，形成一个执行栈；
 *  主线程之外，事件触发线程管理着一个任务队列（消息队列），只要异步任务有了运行结果，就在任务队列之中放置一个事件；
 *  一旦执行栈中的所有同步任务执行完毕（此时JS引擎空闲），系统就会读取任务队列，将可运行的异步任务添加到可执行栈中，开始执行；  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nc1Rpbmc_size_16_color_FFFFFF_t_70 5]

看到这里，应该就可以理解：为什么有时候setTimeout推入的事件不能准时执行？因为可能在它推入到事件列表时，主线程还不空闲，正在执行其它代码，所以自然有误差。

# 十、单独说说定时器 #

在调用setTimeout后，是如何等待特定时间后才添加到事件队列中的？

是JS引擎检测的么？当然不是了。它是由定时器线程控制（因为JS引擎自己都忙不过来，根本无暇分身）。

为什么要有单独的定时器线程？因为JavaScript引擎是单线程的，如果处于阻塞线程状态就会影响记计时的准确，因此很有必要单独开一个线程用来计时。

什么时候会用到定时器线程？当使用setTimeout或setInterval时，它需要定时器线程计时，计时完成后就会将特定的事件推入事件队列中。

例如:

setTimeout(function(){ console.log('hello!');}, 1000);

这段代码的作用是当1000毫秒计时完毕后（由定时器线程计时），将回调函数推入事件队列中，等待主线程执行。

setTimeout(function(){ console.log('hello!');}, 0);
    console.log('begin');
    
    //begin 
    //hello

这段代码的效果是最快的时间内将回调函数推入事件队列中，等待主线程执行。

**注意：**

只有可执行栈内空了后才会主动读取事件队列。具体的setTimeout运用场景点击[这里][Link 1]查看。

# 十一、事件循环进阶：macrotask与microtask #

上文中将JS事件循环机制梳理了一遍，在ES5的情况是够用了，但是在ES6盛行的现在，仍然会遇到一些问题，例如下面这题：

console.log('start');
    setTimeout(function(){ 
    	console.log('setTimeout');
    }, 0);
    Promise.resolve()
    .then(function(){ 
    	console.log('promise1');
    })
    .then(function(){ 
    	console.log('promise2');}
    );
    console.log('end');

执行顺序如下：

start
    end 
    promise1 
    promise2 
    setTimeout

为什么呢？在JS中分两种任务类型：macrotask和microtask，在ECMAScript中，macrotask称为task，microtask称为jobs。

它们的定义和区别如下：

*  **macrotask（宏任务）**，可以理解是每次执行栈执行的代码就是一个宏任务（包括每次从事件队列中获取一个事件回调并放到执行栈中执行）；
 *  每一个task会从头到尾将这个任务执行完毕，不会执行其它；
 *  浏览器为了能够使得JS内部task与DOM任务能够有序的执行，会在一个task执行结束后，在下一个 task 执行开始前，对页面进行重新渲染（task->渲染->task->…）；
 *  **microtask（微任务）**，可以理解是在当前 task 执行结束后立即执行的任务；
 *  也就是说，在当前task任务后，下一个task之前，在渲染之前；
 *  所以它的响应速度相比setTimeout（setTimeout是task）会更快，因为无需等渲染；
 *  也就是说，在某一个macrotask执行完后，就会将在它执行期间产生的所有microtask都执行完毕（在渲染前）；

在什么样的场景会形成macrotask和microtask呢？

*  **macrotask（宏任务）**：主代码块，setTimeout，setInterval等（可以看到，事件队列中的每一个事件都是一个macrotask）；
 *  **microtask（微任务）**：Promise，process.nextTick等，并且在node环境下，process.nextTick的优先级高于Promise；

我们以 setTimeout、process.nextTick、promise 为例再次直观感受下两种任务队列的运行方式：

console.log('main1');
    process.nextTick(function() { 
        console.log('process.nextTick1');
    });
    setTimeout(function() { 
        console.log('setTimeout');
        process.nextTick(function() { 
            console.log('process.nextTick2');
        });
    }, 0);
    new Promise(function(resolve, reject) { 
        console.log('promise');
        resolve();
    }).then(function() { 
        console.log('promise then');
    });
    console.log('main2');

别着急看答案，先以上面的理论自己想想，运行结果会是啥？

最终结果是这样的：

main1
    promise
    main2
    process.nextTick1
    promise then
    setTimeout
    process.nextTick2

# 参考文章 #

[https://mp.weixin.qq.com/s/vIKDUrbuxVNQMi\_g\_fiwUA][https_mp.weixin.qq.com_s_vIKDUrbuxVNQMi_g_fiwUA]  
[https://www.jianshu.com/p/f478f15c1671][https_www.jianshu.com_p_f478f15c1671]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nc1Rpbmc_size_16_color_FFFFFF_t_70]: /images/20221120/66866f440ede4d80bb2cc955ec2af1de.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nc1Rpbmc_size_16_color_FFFFFF_t_70 1]: /images/20221120/8133d02a4c984f329d3f44fb41a72d09.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nc1Rpbmc_size_16_color_FFFFFF_t_70 2]: /images/20221120/1d3e6a3b16144f0fb38baf893a299c71.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nc1Rpbmc_size_16_color_FFFFFF_t_70 3]: /images/20221120/f67572eb9ab84bb1916bc22f659692f3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nc1Rpbmc_size_16_color_FFFFFF_t_70 4]: /images/20221120/a9566ab99f644a929aa1d61780579dad.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0h1YW5nc1Rpbmc_size_16_color_FFFFFF_t_70 5]: /images/20221120/e13ee9dfc92a4ec48dd940cbd8cb515d.png
[Link 1]: https://blog.csdn.net/HuangsTing/article/details/111609424
[https_mp.weixin.qq.com_s_vIKDUrbuxVNQMi_g_fiwUA]: https://mp.weixin.qq.com/s/vIKDUrbuxVNQMi_g_fiwUA
[https_www.jianshu.com_p_f478f15c1671]: https://www.jianshu.com/p/f478f15c1671