JS执行机制与异步回调

[转]理解JavaScript 执行机制及异步回调(setTimeout/setInterval/Promise)

‘javascript执行机制‘ / ‘代码执行顺序‘ / ‘函数生命周期加载‘ 等类似问题 都与javascript执行机制相关。

1. 关于JavaScript

JavaScript 是一门 单线程语言，在最新的HTML5中提出了Web-Worker，但JS 是单线程这一核心仍未改变。所以一切JS 版的"多线程"都是用单线程模拟出来的，一切 JavaScript 多线程 都是纸老虎！

2. JavaScript事件循环

既然JS是单线程，排队 办理业务, js任务也要一个一个顺序执行。如 任务耗时过长，后一个任务必须等着。浏览新闻 超清图片加载慢 需要异步加载 任务分为两类：

• 同步任务\
  打开网站，网页渲染 过程 就是 同步任务，比如 页面骨架和 页面元素的渲染。

• 异步任务\
  而 加载 图片 音乐之类占用资源大耗时久的任务，就是异步任务。

  关于这部分有严格的文字定义，但本文的目的是用最小的学习成本彻底弄懂执行机制，所以用导图来说明：
  

  导图要表达的内容用文字来表述的话：
  
  同步和异步任务分别进入不同的执行”场所”，同步的进入主线程，异步的进入Event Table并注册函数。当指定的事情完成时，Event Table会将这个函数 移入Event Queue。主线程内的任务执行完毕为空，会去Event Queue读取对应的函数，进入主线程执行。

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

  我们不禁要问了，那怎么知道主线程执行栈为空啊？js引擎存在monitoring process进程，会持续不断检查主线程执行栈是否为空，一旦为空，就会去Event Queue那里检查是否有等待被调用的函数。
  说了这么多文字，不如直接一段代码更直白：略

3. 又爱又恨的setTimeout

大名鼎鼎的setTimeout无需再多言，大家对他的第一印象就是异步可以延时执行，我们经常这么实现延时3秒执行：

setTimeout(() => {
    console.log('延时3秒');
},3000)

随着setTimeout使用的增加，问题也出现了，有时候明明写的延时3秒，实际却5，6秒才执行函数，这是为何？

渐渐的setTimeout用的地方多了，问题也出现了，有时候明明写的延时3秒，实际却5，6秒才执行函数，这又咋回事啊？

先看一个例子：

setTimeout(() => {
    task();
},3000)
console.log('执行console');

根据前面我们的结论，setTimeout是异步的，应该先执行console.log这个同步任务，所以我们的结论是：

//执行console
//task()

去验证一下，结果正确！
然后我们修改一下前面的代码：

setTimeout(() => {
    task()
},3000)

sleep(10000000)

乍一看其实差不多，但把这段代码在chrome执行一下，却发现控制台执行task()需要的时间远远超过3秒，为何需要这么长时间？

这时候我们需要重新理解setTimeout的定义。我们先说上述代码是怎么执行的：

• task()进入Event Table并注册,计时开始。

• 执行sleep函数，很慢，非常慢，计时仍在继续。

• 3秒到了，计时事件timeout完成，task()进入Event Queue，但是sleep也太慢了吧，还没执行完，只好等着。

• sleep终于执行完了，task()终于从Event Queue进入了主线程执行。

上述的流程走完，我们知道setTimeout这个函数，是经过指定时间后，把要执行的任务(本例中为task())加入到Event Queue中，又因为是单线程任务要一个一个执行，如果前面的任务需要的时间太久，那么只能等着，导致真正的延迟时间远远大于3秒。