我想这次我真的理解了 JavaScript 的单线程机制

今天面试的时候被问到一个问题，是关于 JS 异步的。当时我脑海中闪过了一个单线程的概念，但却没有把真正的原理阐述清楚。所以回来特意重新回顾了前面单线程和异步相关的一些知识点。

虽然之前学习的时候也接触了单线程模型相关的东西，但当时理解得并不是很清楚和明白。所以这道面试题也没有给出一语中的的答案。重新阅读阮一峰的 《JavaScript 运行机制详解》和我之前写的《setTimeout 异步与回调》之后。我决定重新写一篇博客来更加白话的总结 JS 的单线程机制和异步。

重演历史 - 为什么 JS 是单线程

当我们打开一个页面，页面的 JS 会去执行。从系统层面来说，他是单线程的去执行。换句话讲系统中只有一个线程去处理整个页面的渲染（代码的执行）。为什么会这样呢？因为简单，因为 JS 很早就被发明出来了，浏览器也是。那个时候考虑的第一件事，是功能简单。试想一下如果是多线程，一个处理页面渲染 DOM 操作，另外的线程也处理，就会出现混乱。因为搞不清楚谁做了什么，做到什么程度了。但如果只有一个线程单独处理这些操作，就非常好的能够管控。所以浏览器的模型就是单线程。

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

所以在早期，当使用大量同步的代码时，打开网页就会出现卡屏、卡页面的情况。因为在获取数据的时候，使用同步的代码，后面的数据还没到来之前，获取数据之后的代码都无法执行。只有等获取数据全部结束后，才会执行下面的代码。

所以后来，大家都知道了。开始使用异步。

同步队列 / 任务队列

既然是单线程，就意味着需要排队，即前面的任务结束，后面的任务才能执行。所以所有的任务被分成了两种，一种是同步任务，一种就是异步任务。同步任务指的就是在主线程上排队执行的任务，只有前一个任务执行完毕，才能继续执行后一个任务。而异步任务指的是，不进入主线程（同步队列 stack），而是进入任务队列（task queue）的任务。只有任务队列通知主线程，某个异步任务可以执行了，该任务才会进入主线程执行。

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

重新理解这张图

例如我们有一段代码，这些代码是用来做一些操作。正常情况下，代码都是放置在栈（stack）中的，正常执行的时候是一个个去执行的。但是有些时候，比如给页面元素绑定一个事件，发了一条 ajax 请求，或者还有一些异步处理。这个时候，就不能够放置在 stack 中了。不然就会处于长久的等待之中，其他的代码就无法按顺序即使的执行。

所以在浏览器里面，还有一个可以被称之为任务队列的地方。对于一些异步的任务，都是放到任务队列里面。举例来说，当用户给一个元素绑定事件 onClick，绑定事件的操作在 stack 执行，但 onClick 回调本身是放到任务队列里面的。

重新理解 setTimeout

之前认识 setTimeout 时，就已经见过这段代码了，他的输出结果是先输出 2，后才输出 1。原理也是因为单线程机制。

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

即 console.log(2) 被放入到 stack 中执行，setTimeout() 被放入到 callback queue 了。换句话说，必须要等所有 stack 中的同步的代码全都执行完后，才会去执行异步的事件。所以不管 setTimeout() 里面的时间是 0 还是 1000 都会被排到后面。

所以下面这个例子，1 永远不会被输出，且 2 被循环多次后，会被卡死。因为永远都在执行 console.log(2) 这个同步代码。而整个 stack 栈都被堵死了。 setTimeout() 根本没办法执行。

var isOk = truesetTimeout(function(){  console.log(1)
  isOk = false},1000)while(isOk){  console.log(2)
}

分析原生 Ajax

所以再去分析原生 Ajax 里面的代码，也能够更好的理解同步任务和异步任务。

这次，我想我真的理解了 JavaScript 的单线程机制。

作者：evenyao
链接：https://www.jianshu.com/p/99dcb05facd1