JavaScript 执行机制

• 同步任务

• 异步任务

• 同步和异步任务分别进入不同的执行"场所"，同步的进入主线程，异步的进入Event Table并注册函数。

• 当指定的事情完成时，Event Table会将这个函数移入Event Queue。

• 主线程内的任务执行完毕为空，会去Event Queue读取对应的函数，进入主线程执行。

• 上述过程会不断重复，也就是常说的Event Loop(事件循环)。

• 宏任务

• 微任务

• macro-task(宏任务)：包括整体代码script，setTimeout，setInterval

• micro-task(微任务)：Promise，process.nextTick

执行顺序： 宏任务 ->执行结束 -> 有无可执行的微任务 -> 执行所有的微任务 -> 开始新的宏任务

面试例子：

console.log('1');

setTimeout(function() {
    console.log('2');
    process.nextTick(function() {
        console.log('3');
    })
    new Promise(function(resolve) {
        console.log('4');
        resolve();
    }).then(function() {
        console.log('5')
    })
})
process.nextTick(function() {
    console.log('6');
})
new Promise(function(resolve) {
    console.log('7');
    resolve();
}).then(function() {
    console.log('8')
})

setTimeout(function() {
    console.log('9');
    process.nextTick(function() {
        console.log('10');
    })
    new Promise(function(resolve) {
        console.log('11');
        resolve();
    }).then(function() {
        console.log('12')
    })
})
复制代码

第一轮事件循环流程分析如下：

• 整体script作为第一个宏任务进入主线程，遇到console.log，输出1。
• 遇到setTimeout，其回调函数被分发到宏任务Event Queue中。我们暂且记为setTimeout1。
• 遇到process.nextTick()，其回调函数被分发到微任务Event Queue中。我们记为process1。
• 遇到Promise，new Promise直接执行，输出7。then被分发到微任务Event Queue中。我们记为then1。
• 又遇到了setTimeout，其回调函数被分发到宏任务Event Queue中，我们记为setTimeout2。

宏任务Event Queue	微任务Event Queue
setTimeout1	process1
setTimeout2	then1

• 上表是第一轮事件循环宏任务结束时各Event Queue的情况，此时已经输出了1和7。
• 我们发现了process1和then1两个微任务。
• 执行process1,输出6。
• 执行then1，输出8。

好了，第一轮事件循环正式结束，这一轮的结果是输出1，7，6，8。那么第二轮时间循环从setTimeout1宏任务开始：

• 首先输出2。接下来遇到了process.nextTick()，同样将其分发到微任务Event Queue中，记为process2。new Promise立即执行输出4，then也分发到微任务Event Queue中，记为then2。

宏任务Event Queue	微任务Event Queue
setTimeout2	process2
	then2

• 第二轮事件循环宏任务结束，我们发现有process2和then2两个微任务可以执行。
• 输出3。
• 输出5。
• 第二轮事件循环结束，第二轮输出2，4，3，5。
• 第三轮事件循环开始，此时只剩setTimeout2了，执行。
• 直接输出9。
• 将process.nextTick()分发到微任务Event Queue中。记为process3。
• 直接执行new Promise，输出11。
• 将then分发到微任务Event Queue中，记为then3。

宏任务Event Queue	微任务Event Queue
	process3
	then3

• 第三轮事件循环宏任务执行结束，执行两个微任务process3和then3。
• 输出10。
• 输出12。
• 第三轮事件循环结束，第三轮输出9，11，10，12。

整段代码，共进行了三次事件循环，完整的输出为1，7，6，8，2，4，3，5，9，11，10，12。 (请注意，node环境下的事件监听依赖libuv与前端环境不完全相同，输出顺序可能会有误差)

console.log(1)
setTimeout(()=>{
    console.log(2)
}, 0)
new Promise((resolve, reject)=>{
    console.log('new Promise')
    resolve()
}).then(()=>{
    console.log('then')
})
console.log(3)

流程如下:
// 遇到 console.log(1) ，直接打印 1
// 遇到定时器，属于新的宏任务，留着后面执行
// 遇到 new Promise，这个是直接执行的，打印 'new Promise'
// .then 属于微任务，放入微任务队列，后面再执行
// 遇到 console.log(3) 直接打印 3
// 好了本轮宏任务执行完毕，现在去微任务列表查看是否有微任务，发现 .then 的回调，执行它，打印 'then'
// 当一次宏任务执行完，再去执行新的宏任务，这里就剩一个定时器的宏任务了，执行它，打印 2

setTimeout 的运行机制

setTimeout()函数：用来指定某个函数或某段代码在多少毫秒之后执行。它返回一个整数，表示定时器timer的编号，可以用来取消该定时器。

console.log(1); 
setTimeout(function () { 
    console.log(2); 
}, 0); 
console.log(3);

正确答案：1 3 2 解析：无论setTimeout的执行时间是0还是1000，结果都是先输出3后输出2，这就是面试官常常考查的js运行机制的问题，接下来我们要引入一个概念，JavaScript 是单线程的。 也就是第一轮宏任务执行完（1，3）再执行Event Queue中第二轮宏任务（2）

JavaScript 单线程

JavasScript引擎是基于事件驱动和单线程执行的，JS引擎一直等待着任务队列中任务的到来，然后加以处理。 所有任务可以分成两种，一种是同步任务（synchronous），另一种是异步任务（asynchronous）。

单线程就意味着，所有任务需要排队，前一个任务结束，才会执行后一个任务。而异步任务指的是，不进入主线程、而进入"任务队列"（task queue）的任务，只有主线程执行完毕，主线程去通知"任务队列"，某个异步任务可以执行了，该任务才会进入主线程执行。 所以js的运行机制如下：

• 1. 所有同步任务都在主线程上执行，形成一个执行栈（Call Stack）
• 2. 主线程之外，还存在一个"任务队列"（task queue）。只要异步任务有了运行结果，就在"任务队列"之中放置一个事件
• 3. 一旦"执行栈"中的所有同步任务执行完毕，系统就会读取"任务队列"，看看里面有哪些事件。那些对应的异步任务，于是结束等待状态，进入执行栈，开始执行。
• 4. 主线程不断重复上面的第三步。

setTimeout运行机制

setTimeout 和 setInterval的运行机制，其实就是将指定的代码移出本次执行，等到下一轮 Event Loop 时，再检查是否到了指定时间。如果到了，就执行对应的代码；如果不到，就等到再下一轮 Event Loop 时重新判断。

这意味着，setTimeout指定的代码，必须等到本次执行的所有同步代码都执行完，才会执行。被称为宏任务。

setTimeout 为什么不能保证能够及时执行？

setTimeout 并不能保证执行的时间，是否及时执行取决于 JavaScript 线程是拥挤还是空闲。 浏览器的JS引擎遇到setTimeout，指定代码会在设定的时间后加⼊到异步任务队列中。当js引擎发现同步队列中没有要执行的东西了，即运行栈空了就从异步队列中读取，然后放到运行栈中执行。所以setTimeout可能会多了等待线程的时间。
这时setTimeout函数体就变成了运行栈中的执行任务，运行栈空了，再监听异步队列中有没有要执行的任务，如果有就继续执行，如此循环，就叫Event Loop。

async与await

async

async函数返回一个promise对象，下面两种方法是等效的

function f() {
  return Promise.resolve('TEST');
}

// asyncF is equivalent to f!
async function asyncF() {
  return 'TEST';
}

await

await命令后面是一个 Promise 对象，返回该对象的结果。如果不是 Promise 对象，就直接返回对应的值

async function f(){
  // 等同于
  // return 123
  return await 123
}
f().then(v => console.log(v)) // 123

不管await后面跟着的是什么，await都会阻塞后面的代码

async function fn1 (){
  console.log(1)
  await fn2()
  console.log(2) // 阻塞，此块阻塞代码会加入微队列任务中
}

async function fn2 (){
  console.log('fn2')
}

fn1()
console.log(3)

上面的例子中，await 会阻塞下面的代码（即加入微任务队列），先执行 async 外面的同步代码，同步代码执行完，再回到 async 函数中，再执行之前阻塞的代码

所以上述输出结果为：1，fn2，3，2

流程分析

async function async1() {
  console.log('async1 start')
  await async2()
  console.log('async1 end') // 被阻塞，放到微任务队列
}
async function async2() {
  console.log('async2')
}
console.log('script start')
setTimeout(function () {
  console.log('settimeout')
})
async1()
new Promise(function (resolve) {
  console.log('promise1')
  resolve()
}).then(function () {
  console.log('promise2')
})
console.log('script end')

分析过程：

1. 执行整段代码，遇到 console.log('script start') 直接打印结果，输出 script start
2. 遇到定时器了，它是宏任务，先放着不执行
3. 遇到 async1()，执行 async1 函数，先打印 async1 start，下面遇到await怎么办？先执行 async2，打印 async2，然后阻塞下面代码（即加入微任务列表），跳出去执行同步代码
4. 跳到 new Promise 这里，直接执行，打印 promise1，下面遇到 .then()，它是微任务，放到微任务列表等待执行
5. 最后一行直接打印 script end，现在同步代码执行完了，开始执行微任务，即 await 下面的代码，打印 async1 end
6. 继续执行下一个微任务，即执行 then 的回调，打印 promise2
7. 上一个宏任务所有事都做完了，开始下一个宏任务，就是定时器，打印 settimeout

所以最后的结果是：script start、async1 start、async2、promise1、script end、async1 end、promise2、settimeout

为什么JavaScript是单线程？

JavaScript的单线程，与它的用途有关。作为浏览器脚本语言，JavaScript的主要用途是与用户互动，以及操作DOM。假定JavaScript同时有两个线程，一个线程在某个DOM节点上添加内容，另一个线程删除了这个节点，这时浏览器应该以哪个线程为准？ 为了利用多核CPU的计算能力，允许JavaScript脚本创建多个线程，但是子线程完全受主线程控制，且不得操作DOM。所以，这个新标准并没有改变JavaScript单线程的本质。

谈谈你对浏览器中进程和线程的理解

浏览器是多进程的

它主要包括以下进程：

Browser 进程：浏览器的主进程，唯一，负责创建和销毁其它进程、网络资源的下载与管理、浏览器界面的展示、前进后退等。 GPU 进程：用于 3D 绘制等，最多一个。 第三方插件进程：：每种类型的插件对应一个进程，仅当使用该插件时才创建。 浏览器渲染进程（浏览器内核）:内部是多线程的，每打开一个新网页就会创建一个进程，主要用于页面渲染，脚本执行，事件处理等。

渲染进程（浏览器内核）

浏览器的渲染进程是多线程的，页面的渲染，JavaScript 的执行，事件的循环，都在这个进程内进行：

• GUI 渲染线程：负责渲染浏览器界面，当界面需要重绘（Repaint）或由于某种操作引发回流(Reflow)时，该线程就会执行。
• JavaScript 引擎线程：也称为 JavaScript 内核，负责处理 Javascript 脚本程序、解析 Javascript 脚本、运行代码等。（例如 V8 引擎）
• 事件触发线程：用来控制浏览器事件循环，注意这不归 JavaScript 引擎线程管，当事件被触发时，该线程会把事件添加到待处理队列的队尾，等待 JavaScript 引擎的处理。
• 定时触发器线程：传说中的 setInterval 与 setTimeout 所在线程
• 异步 http 请求线程：在 XMLHttpRequest 连接后通过浏览器新开一个线程请求，将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件，将这个回调再放入事件队列中。再由 JavaScript 引擎执行。 注意，GUI 渲染线程与 JavaScript 引擎线程是互斥的，当 JavaScript 引擎执行时 GUI 线程会被挂起（相当于被冻结了），GUI 更新会被保存在一个队列中等到 JavaScript 引擎空闲时立即被执行。所以如果 JavaScript 执行的时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞。

html文档渲染过程，css文件和js文件的下载，是否会阻塞渲染？

浏览器内有多个进程， 其中渲染进程被称为浏览器内核，负责页面渲染和执行 JS 脚本等。 渲染进程负责浏览器的解析和渲染，内部有 JS 引擎线程、 GUI 渲染线程、事件循环管理线程、定时器线程、HTTP 线程。 JS 引擎线程负责执行 JS 脚本，GUI 渲染线程负责页面的解析和渲染，两者是互斥的，也就是执行 JS 的时候页面是停止解析和渲染的。 浏览器的 HTML/CSS 的解析和渲染都属于 GUI渲染线程，所以和 JS 引擎线程是互斥、阻塞的。下面从代码实际运行的角度分析浏览器解析和渲染的顺序，以及互相间的阻塞关系。

CSS 阻塞

• css 文件的下载和解析不会影响 DOM 的解析，但是会阻塞 DOM 的渲染。因为 CSSOM Tree 要和 DOM Tree 合成 Render Tree 才能绘制页面。下面的 test1 在 css 下载并解析完成前是默认样式，test2 在 css 下载并解析完成之前不会显示：

• css 文件没下载并解析完成之前，**后续的** js 脚本不能执行。下面的 alert('ok') 在 css 下载并解析完成之前不会弹出来：

• css 文件的下载不会阻塞 **前面的** js 脚本执行。下面的 alert('ok') 会在 css 下载完成前弹出：

所以在需要提前执行不操作 dom 元素的 js 时，不妨把 js 放到 css 文件之前。

js 阻塞

js 文件的下载和解析会阻塞 GUI 渲染进程，也就是会阻塞 DOM 和 CSS 的解析和渲染。 js 文件没下载并解析完成之前，后续的 HTML 和 CSS 无法解析：

• js 文件的下载不会阻塞前面 HTML 和 CSS 的解析：

需要注意的点

• 第一，GUI 渲染线程会尽可能早的将内容呈现到屏幕上，并不会等到所有的 HTML 都解析完成之后再去构建和布局 Render Tree，而是解析完一部分内容就显示一部分内容，同时，可能还在通过网络下载其余内容。下面 test1 会在 js 文件下载完成前渲染完成，而 test2 则会在 js 文件下载并执行完之后渲染：

• 第二，文件的下载是不会被阻塞的，不管是 css 还是 js 文件，浏览器的主线程会在页面解析前开启下载，所以就算在外部脚本执行前删除脚本，脚本也还是会下载。

堆与栈有什么区别？