简单地说，JavaScript 是单线程执行的语言，但在使用中有很多异步执行的情况。异步的本质是用其他方式（相对同步）控制程序的执行顺序，这与其他语言中的多线程模型不同，所以常常有人对非顺序 JavaScript 代码的运行结果感到困惑不解。
一段简单的小程序
任何使用过 JavaScript 的程序员都能说出下面这段代码的输出：
console.log("A"); setTimeout(() => { console.log("B"); }, 100); console.log("C");
先后顺序是 A、C、B，因为第二个参数的作用是指定延迟的毫秒数，这段代码只有一个 setTimeout，所以不会让人迷惑。
对类似程序的解释通常是由 setTimeout 设置一个定时器，在指定毫秒数后调用回调函数。然而，它的执行机制并不是这么简单。实际上，setTimeout 的作用是在指定的毫秒数之后，在得到机会时，将 callback 放入 Event Loop Queue。
Event Loop
首先要抛出一些概念，通常所说的 JavaScript Engine 是指负责执行一个一个 chunk 的程序，它依赖宿主环境的调度，也需要通过宿主环境与操作系统产生关联并得到支持。JavaScript Engine 是 JavaScript Runtime(Hosting Environment) 的一部分。
每个 chunk 通常是以 function 为单位，一个 chunk 执行完成后，才会执行下一个 chunk。下一个 chunk 是什么呢？取决于当前 Event Loop Queue 中的队首。Event Loop Queue 中存放的都是消息，每个消息关联着一个函数，JavaScript Engine 就按照队列中的消息顺序执行它们，也就是执行 chunk。
所以上面的 setTimeout 实际执行起来更接近这样：
- chunk1执行：由 setTimeout 启动定时器（100毫秒）
- chunk2执行：得到机会，将 callback 放入 Event Loop Queue
- chunk3执行：此 callback 执行
不难发现，得到机会很重要！这也就可以解释用 setTimeout 延迟 1000 不一定是准确的，而是会至少延迟一秒。因为如果还有其他的任务在前面，它要等待那些任务对应的消息都出队，也就是程序都执行完成，它才能将 callback 放入队列。也就是实际延迟会大于或等于一秒。
通常所说的触发了一个事件，就是指这个 event listener 得到了执行。与 setTimeout 这个例子中的概念一样，这也是一次 chunk 的执行。像这样一个一个执行 chunk 的过程就叫 Event Loop。
还有一个经常提到的概念叫「无阻塞」，JavaScript 中的无阻塞就是指这种 Event Loop 模型。除去 alert 或同步 Ajax 请求等历史原因造成的问题，程序总是不会出现阻塞；也就是说 JavaScript Engine 总是可以处理下一个任务，如处理用户对浏览器的操作。
一些简单的小例子
将 setTimeout 加入 try 语句之中，结果会如何？
try { setTimeout(() => { throw new Error("Error - from try statement"); }, 0); } catch (e) { console.error(e); }
try catch 与 setTimeout 不在同一个 chunk，所以……你懂的。
再看下一个。
下面的堆栈信息会输出 C - B - A 吗？
setTimeout(function A() { setTimeout(function B() { setTimeout(function C() { throw new Error("Error - from function C"); }, 0); }, 0); }, 0);
它们并不对应同一条 Event Loop Queue 中的消息，分别有各自的调用栈，所以错误栈里面只有 C。
Job Queue
Job 是 ES6 中新增的概念，它与 Promise 的执行有关，可以理解为等待执行的任务；Job Queue 就是这种类型的任务的队列。JavaScript Runtime 对于 Job Queue 与 Event Loop Queue 的处理有所不同。
相同点：
- 都用作先进先出队列
相异点：
- 每个 JavaScript Runtime 可以有多个 Job Queue，但只有一个 Event Loop Queue
- 当 JavaScript Engine 处理完当前 chunk 后，优先执行所有的 Job Queue，然后再处理 Event Loop Queue
ES6 中，一个 Promise 就是一个 PromiseJob，一种 Job。
再来观察一段小程序：
console.log("A"); setTimeout(() => { console.log("A - setTimeout"); }, 0); new Promise((resolve) => { resolve(); }) .then(() => { return console.log("A - Promise 1"); }) .then(() => { return console.log("B - Promise 1"); }); new Promise((resolve) => { resolve(); }) .then(() => { return console.log("A - Promise 2"); }) .then(() => { return console.log("B - Promise 2"); }) .then(() => { return console.log("C - Promise 2"); }); console.log("AA");
在原生支持 Promise 的环境，输出是这样：
A
AA
A - Promise 1
A - Promise 2
B - Promise 1
B - Promise 2
C - Promise 2
A - setTimeout
理解这个输出：
- A 与 AA 最先输出，因为它们不是异步任务，属于第一个 chunk。
- Promise 1 与 Promise 2 先于 setTimeout 执行，因为 Job Queue 的执行优先于 Event Loop Queue。
- Promise 1 与 Promise 2 各自的输出都是顺序的，因为 Job Queue 是先进先出队列，同一 Job Queue 中的任务顺序执行。
- Promise 1 与 Promise 2 的后续任务是交错的，因为 Promise 1 与 Promise 2 都是独立的 PromiseJob（job 的其中一种），属于不同的 Job Queue，它们之间的顺序规范中没有规定。
并发
文章开头，我说「简单地说，JavaScript 是单线程执行的语言」，现在可以说得稍微复杂一点了：JavaScript Engine 对 JavaScript 程序的执行是单线程的，但是 JavaScript Runtime（整个宿主环境）并不是单线程的；而且，几乎所有的异步任务都是并发的，例如多个 Job Queue、Ajax、Timer、I/O(Node)等等。
上面说的是 JavaScript Runtime 层面，从开发者的 JavaScript 代码执行层面来说，也有一些特殊情况，例如：一个 Web Worker，是一个独立的线程，有自己的内存空间（栈、堆）以及 Event Loop Queue。要与这样的不同的线程通信，只能通过 postMessage。一次 postMessage 就是在另一个线程的 Event Loop Queue 中加入一条消息。
而一个跨域的 iframe 中，JavaScript 也有单独的内存空间（栈、堆）以及 Event Loop Queue，也只能通过 postMessage 与它通信。至于它与主页面是否运行在同一线程内，取决于浏览器的实现（目前是在同一线程内）。
