为什么javascript是单线程？

因为最初javascript就是为了和浏览器交互而诞生的，如果 JS 是门多线程的语言话，我们在多个线程中处理 DOM 就可能会发生问题（一个线程中新加节点，另一个线程中删除节点），当然可以引入读写锁解决这个问题，为了避免复杂性，设计者还是把它设计成单线程模式。

后来，HTML5提出Web Worker标准, 允许JavaScript脚本创建多个线程，但是子线程完全受主线程控制，且不得操作DOM，所以这个新标准并没有改变JavaScript单线程本质。

Event Loop（浏览器、node）

什么是Event Loop？

一句话总结：Event Loop就是javascript运行机制。

为什么要有Event Loop？

因为Javascript设计之初就是一门单线程语言，因此为了实现主线程的不阻塞，Event Loop这样的方案应运而生。

任务队列

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

如果排队是因为计算量大，CPU忙不过来，倒也算了。

但是很多时候CPU是闲着的，因为IO设备（输入输出设备）很慢（比如Ajax操作从网络读取数据），不得不等着结果出来，再往下执行。

JavaScript语言的设计者意识到，这时主线程完全可以不管IO设备，挂起处于等待中的任务，先运行排在后面的任务。等到IO设备返回了结果，再回过头，把挂起的任务继续执行下去。

于是，所有任务可以分成两种，一种是同步任务（synchronous），另一种是异步任务（asynchronous）。

同步任务指的是：在主线程上排队执行的任务，只有前一个任务执行完毕，才能执行后一个任务。

异步任务指的是：不进入主线程、而进入"任务队列"（task queue）的任务，只有"任务队列"通知主线程，某个异步任务可以执行了，该任务才会进入主线程执行。

（1）所有同步任务都在主线程上执行，形成一个执行栈（execution context stack）。

（2）主线程之外，还存在一个"任务队列"（task queue）。只要异步任务有了运行结果，就在"任务队列"之中放置一个事件。

（3）一旦"执行栈"中的所有同步任务执行完毕，系统就会读取"任务队列"，看看里面有哪些事件。那些对应的异步任务，于是结束等待状态，进入执行栈，开始执行。

（4）主线程不断重复上面的第三步。

只要主线程空了，就会去读取"任务队列"，这就是JavaScript的运行机制。这个过程会不断重复。

任务队列分类

不同的任务源会被分配到不同的任务队列（task queue）中。

任务源可以分为 微任务（microtask-在 ES6 规范中，microtask 称为 jobs） 和 宏任务（macrotask-在 ES6 规范中，macrotask 称为 task）。

浏览器的Event loop

微任务：promise、MutationObserver

宏任务：script、setTimeout、setInterval、requestAnimationFrame、I/O

Event loop 执行顺序：

执行同步代码（script标签里面的代码---main script），这属于宏任务执行栈为空，查询是否有微任务需要执行执行所有微任务必要的话渲染 UI然后开始下一轮 Event loop，执行宏任务，然后到第二步

总结：宏任务->微任务->宏任务->微任务（这样循环）直至执行栈为空

通过上述的 Event loop 顺序可知，如果宏任务中的异步代码有大量的计算并且需要操作 DOM 的话，为了更快的 界面响应，我们可以把操作 DOM 放入微任务中。

好了，我们看例子：

console.log('执行 script start') setTimeout(function() { console.log('执行 setTimeout') }, 0) new Promise(resolve => { console.log('执行 Promise') resolve("执行 promise resolve") }).then(function(res) { console.log(res) }) for(let i=0; i<10000; i++) { console.log(i) } console.log('执行 script end') // 执行 script start // 执行 Promise // 0 // 1 // ... // 9999 // 执行 script end // 执行 promise resolve // 执行 setTimeout

就不用讲解了，自行补充，如果有兴趣可以留言。

讲讲setTimeout

setTimeout() ：在指定的毫秒数后调用函数或计算表达式。

HTML5标准规定了setTimeout()的第二个参数的最小值（最短间隔），不得低于4毫秒，如果低于这个值，就会自动增加。

在此之前，老版本的浏览器都将最短间隔设为10毫秒。

另外，对于那些DOM的变动（尤其是涉及页面重新渲染的部分），通常不会立即执行，而是每16毫秒执行一次。

这时使用requestAnimationFrame()的效果要好于setTimeout()。

需要注意的是，setTimeout()只是将事件插入了"任务队列"，必须等到当前代码（执行栈）执行完，主线程才会去执行它指定的回调函数。要是当前代码耗时很长，有可能要等很久，所以并没有办法保证，回调函数一定会在setTimeout()指定的时间执行（看上面例子就知道了）。

讲讲setInterval

setInterval() ：指定某个任务每隔一段时间就执行一次，也就是无限次的定时执行，直到 clearInterval() 被调用或窗口被关闭。

HTML5标准规定了setInterval()的第二个参数的最小值（最短间隔），不得低于10毫秒，如果低于这个值，就会自动增加。

setInterval()将事件插入"任务队列"，跟settimeout一样。

讲讲requestAnimationFrame

requestAnimationFrame 比起 setTimeout、setInterval的优势主要有两点：

1、requestAnimationFrame 会把每一帧中的所有DOM操作集中起来，在一次重绘或回流（重排）中就完成，并且重绘或回流（重排）的时间间隔紧紧跟随浏览器的刷新频率，一般来说，这个频率为每秒60帧。

2、在隐藏或不可见的元素中，requestAnimationFrame将不会进行重绘或回流，这当然就意味着更少的的cpu，gpu和内存使用量。

如果你有循环定时器的需求，其实完全可以通过来requestAnimationFrame实现：

function setInterval(callback, interval) { let timer const now = Date.now let startTime = now() let endTime = startTime const loop = () => { timer = window.requestAnimationFrame(loop) endTime = now() if (endTime - startTime >= interval) { startTime = endTime = now() callback(timer) } } timer = window.requestAnimationFrame(loop) return timer } let a = 0 setInterval(timer => { console.log(1) a++ if (a === 3) cancelAnimationFrame(timer) }, 1000)

屏幕刷新频率：屏幕刷新率是指显示器的屏幕每秒钟会刷新多少次。

目前，大部分的显示器的刷新频率为60次/秒，也就是说，屏幕刷新的间隔时间为大约1000/60=16.67ms。

所以，一般来说，如果动画的执行频率跟屏幕的刷新频率一致，动画看起来就可以达到流畅的极限

首先 requestAnimationFrame 自带函数节流功能，基本可以保证在 16.6 毫秒内只执行一次（不掉帧的情况下），并且该函数的延时效果是精确的，没有其他定时器时间不准的问题，当然你也可以通过该函数来实现 setTimeout。

node的Event loop

我们都知道Node.js 是一个基于 Chrome V8 引擎的 JavaScript 运行环境，也就是能够让js在服务端运行。

但是Node中的Event Loop是用libuv模拟的，它将不同的任务分配给不同的线程，形成一个Event Loop，以异步的方式将任务的执行结果返回给V8引擎。

微任务：promise、process.nextTick、setImmediate

宏任务：script、setTimeout、setInterval、I/O

Node 中的 Event loop 和浏览器中的不相同，Node 的 Event Loop 分为 6 个阶段，它们会按照顺序反复运行。每当进入某一个阶段的时候，都会从对应的回调队列中取出函数去执行。当队列为空或者执行的回调函数数量到达系统设定的阈值，就会进入下一阶段。

timers

imers 阶段会执行 setTimeout（）和 setInterval（）回调，并且是由 poll 阶段控制的。

一个 timer 指定的时间并不是准确时间，而是在达到这个时间后尽快执行回调，可能会因为系统正在执行别的事务而延迟。

下限的时间有一个范围：[1, 2147483647] ，如果设定的时间不在这个范围，将被设置为 1。

I/O

I/O 阶段会执行除了 close 事件，定时器和 setImmediate 的回调。

idle, prepare

idle, prepare 阶段内部实现。

poll

poll 阶段很重要，这一阶段中，系统会做两件事情：

执行到点的定时器执行 poll 队列中的事件

并且当 poll 中没有定时器的情况下，会发现以下两件事情：

如果 poll 队列不为空，会遍历回调队列并同步执行，直到队列为空或者系统限制如果 poll 队列为空，会有两件事发生 如果有 setImmediate 需要执行，poll 阶段会停止并且进入到 check 阶段执行 setImmediate如果没有 setImmediate 需要执行，会等待回调被加入到队列中并立即执行回调

如果有别的定时器需要被执行，会回到 timer 阶段执行回调。

check

check阶段执行setImmediat()的回调。

close callbacks

close callbacks 阶段执行 close 事件

例如：

console.log("---script----") setTimeout(() => { console.log('timeout1') Promise.resolve().then(() => { console.log('promise1') }) Promise.resolve().then(() => { console.log('promise2') }) }, 0) setTimeout(() => { console.log('timeout2') Promise.resolve().then(() => { console.log('promise3') }) }, 0) Promise.resolve().then(() => { console.log('script- promise') }) process.nextTick(() => { console.log('script- nextTick') }) for (let i=0; i< 100; i++) { console.log(i) } console.log("---end script----") // ---script---- // 0 // 1 // .... // 99 // ---end script---- // script- nextTick // script- promise // timeout1 // promise1 // promise2 // timeout2 // promise3

讲解：

先执行script里面的代码，执行console.log("---script----")，

把第一个定时器setTimeout扔进宏任务，

把第二个定时器扔进宏任务，

把script里的Promise扔进微任务，

把script里的process扔进微任务，

执行到forconsole.log(i)

for结束，执行console.log("---end srcipt----")

检查微任务，发现process，执行console.log('script- nextTick')

检查微任务，发现Promise，执行console.log('script- promise')

微任务执行完，开始检查宏任务，发现第一个定时器

执行console.log('timeout2')，把第一个Promise扔进微任务，把第二个Promise扔进微任务

宏任务执行完，这时候检查微任务，发现有两个，依次console.log('promise1')，console.log('promise2')

现在在检查宏任务发现第二个定时器，执行console.log('timeout2')，发现Promise把它扔进微任务，

当前宏任务执行完，检查微任务，执行Promise，console.log('promise3')

个别例子：

并且在 Node 中，有些情况下的定时器执行顺序是随机的

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

讲解：

 可能输出 setTimeout、setImmediate

可能也会相反的输出，这取决于性能

因为可能进入 event loop 用了不到 1 毫秒，这时候会执行 setImmediate

否则会执行 setTimeout

 当然在这种情况下，执行顺序是相同的

var fs = require('fs') fs.readFile(__filename, () => { setTimeout(() => { console.log('timeout') }, 0) setImmediate(() => { console.log('immediate') }) })

讲解：

因为 readFile 的回调在 poll 中执行

发现有 setImmediate ，所以会立即跳到 check 阶段执行回调

再去 timer 阶段执行 setTimeout

所以以上输出一定是 setImmediate，setTimeout

上面介绍的都是 宏任务（macrotask ）的执行情况，微任务（microtask ）会在以上每个阶段完成后立即执行。

setTimeout(() => { console.log('timer1') Promise.resolve().then(function() { console.log('promise1') }) }, 0) setTimeout(() => { console.log('timer2') Promise.resolve().then(function() { console.log('promise2') }) }, 0)

讲解：

以上代码在浏览器和 node 中打印情况是不同的

浏览器中一定打印 timer1, promise1, timer2, promise2

node 中可能打印 timer1, timer2, promise1, promise2

也可能打印 timer1, promise1, timer2, promise2

Node 中的 process.nextTick 会先于其他 微任务（microtask ）执行。

setTimeout(() => { console.log('timer1') Promise.resolve().then(function() { console.log('promise1') }) }, 0) process.nextTick(() => { console.log('nextTick') }) // nextTick, timer1, promise1

参考：

https://juejin.im/post/59e85eebf265da430d571f89

https://yuchengkai.cn/docs/frontend/browser.html#close-callbacks

http://47.98.159.95/my_blog/js-v8/006.html#_1-三大关键阶段

http://www.ruanyifeng.com/blog/2014/10/event-loop.html

https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/

https://juejin.im/post/5b63b4cb6fb9a04fb4017f5a