1. JavaScript引擎
JavaScript引擎是浏览器的重要组成部分，是JavaScript代码处理并执行的环境。其由多个组成部分组成。
2. JavaScript是单线程执行
2.1 进程与线程
如果是windows电脑，打开任务管理器就可以看到有一个后台进程列表。那里可以看到每个进程的内存资源信息和CPU占有率以及对其它系统资源的占用情况。
一般来说:
- 进程是cpu资源分配的最小单位（是能拥有资源和独立运行的最小单位，系统会分配内存）
- 线程是cpu调度的最小单位（线程是建立在进程的基础上的一次程序运行单位，一个进程中可以有多个线程）
需要注意：
- 不同进程之间也可以通信，不过代价较大
- 一般通用的叫法：单线程与多线程，都是指在一个进程内的单和多。（所以核心还是得属于一个进程才行）
2.2 浏览器是多进程
理解了进程与线程了区别后，接下来对浏览器进行一定程度上的认识：（先看下简化理解）
- 浏览器是多进程的
- 浏览器之所以能够运行，是因为系统给它的进程分配了资源（cpu、内存）
- 简单点理解，每打开一个Tab页，就相当于创建了一个独立的浏览器进程。
关于以上几点的验证，请再第一张图：
图中打开了Chrome浏览器的多个标签页，然后可以在Chrome的任务管理器中看到有多个进程（分别是每一个Tab页面有一个独立的进程，以及一个主进程）。
感兴趣的可以自行尝试下，如果再多打开一个Tab页，进程正常会+1以上（不过，某些版本的ie却是单进程的）
注意：在这里浏览器应该也有自己的优化机制，有时候打开多个tab页后，可以在Chrome任务管理器中看到，有些进程被合并了（所以每一个Tab标签对应一个进程并不一定是绝对的）
2.3 JavaScript的执行是单线程
2.3.1 为什么是单线程
JavaScript最早由布兰登·艾奇(Brendan Eich)花费了10天设计开发出来的。做为浏览器脚本语言，其重要用途是 a. 与用户互动 b. 操作DOM。虽然多线程可以提高工作效率，但是由于语言用途的限制，它只能是单线程，否则会带来很复杂的同步问题。比如，假定JavaScript同时有两个线程，一个线程在某个DOM节点上添加内容，另一个线程删除了这个节点，这时浏览器应该以哪个线程为准？
所以，为了避免复杂性，从一诞生，JavaScript就是单线程，这已经成了这门语言的核心特征，将来也不会改变。
为了利用多核CPU的计算能力，HTML5提出Web Worker标准，允许JavaScript脚本创建多个线程，但是子线程完全受主线程控制，且不得操作DOM。所以，这个新标准并没有改变JavaScript单线程的本质。
2.3.2 证明是单线程
单线程只能一个个排着队执行，所以执行以下代码会导致阻塞（有个while死循环），不会出现hello内容的弹框
while(1){}
alert('hello');
3. JavaScript调用栈(Call Stack)
JavaScript是一种单线程编程语言，这意味着它只有一个调用栈。因此，在同一时间它只能做一件事。
调用栈是一个数据结构，它会记录代码执行的位置。例如我们执行进入一个函数，我们会把这个函数放在堆栈的顶部，函数执行结束返回之后，我们把这个函数从堆栈中移除。这就是调用栈的功能。
简单代码示例：
function multiply(x, y) {
return x * y;
}
function printSquare(x) {
var s = multiply(x, x);
console.log(s);
}
printSquare(5);
调用栈的伪代码模拟如下：
//执行栈
var exeStack = [];
//先压如全局执行环境
exeStack.push('globalContext');
//遇到执行printSquare函数，ok，压进去
exeStack.push('printSquare');
//执行printSquare函数发现，还有个multiply函数，ok，压进栈
exeStack.push('multiply');
//执行完了multiply函数，弹栈
exeStack.pop();
//继续执行printSquare函数，又发现有console.log这个家伙，ok，你进栈
exeStack.push('console.log');
//执行了console后，输出计算后的值，console 弹栈
exeStack.pop();
//这时sayHello执行完，弹栈
exeStack.pop();
//最后整个代码执行完，全局环境弹栈
exeStack.pop();
当引擎执行这段代码时，调用栈为空，之后运行如下：
每个Step叫做堆栈帧(Stack Frame)。
调用栈就是通过堆栈帧来追踪异常，堆栈帧基本就是调用栈出现异常时候的状态。示例代码如下：
假设上面代码保存在foo.js文件，执行上面代码在Chrome浏览器中，Error的堆栈信息会如下图打印出来：
单线程执行代码是无法充分利用CPU资源，使得运行效率低。由于JavaScript只有一个调用栈，如果运行效率变低，那应该怎么解决呢？
4. 并发和事件循环
4.1 单线程导致的问题
想像一下如果调用栈里面有些函数的执行需要大量的时间，例如在浏览器中进行复杂的图片转化，情况会怎么样，为什么会有问题？
问题就是调用栈中的函数在执行的过程中，浏览器是不能做其它事情的，也就是会被调用栈中的函数阻塞，此时浏览器不能渲染和运行其它代码，完全被卡住了。这样就很难实现流畅的UIs体验。
而且另外一个问题也会由此发生，如果浏览器在调用栈中执行很多这样复杂且耗时的函数时，浏览器也会失去响应，出现假死状态。
4.2 异步代码的执行
单线程就意味着，所有任务需要排队，前一个任务结束，才会执行后一个任务。如果前一个任务耗时很长，后一个任务就不得不一直等着。
JavaScript引擎执行异步代码而不用等待，是因有为有消息队列和事件循环。
消息队列：消息队列是一个先进先出的队列，它里面存放着各种消息。
事件循环：事件循环是指主线程重复从消息队列中取消息、执行的过程。
实际上，主线程只会做一件事情，就是从消息队列里面取消息、执行消息，再取消息、再执行。当消息队列为空时，就会等待直到消息队列变成非空。而且主线程只有在将当前的消息执行完成后，才会去取下一个消息。这种机制就叫做事件循环机制，取一个消息并执行的过程叫做一次循环。
事件循环用代码表示大概是这样的：
while(true) {
var message = queue.get();
execute(message);
}
那么，消息队列中放的消息具体是什么东西？消息的具体结构当然跟具体的实现有关，但是为了简单起见，我们可以认为：
消息就是注册异步任务时添加的回调函数。
再次以异步AJAX为例，假设存在如下的代码：
$.ajax('http://segmentfault.com', function(resp) {
console.log('我是响应：', resp);
});
// 其他代码
...
...
...
主线程在发起AJAX请求后，会继续执行其他代码。AJAX线程负责请求segmentfault.com，拿到响应后，它会把响应封装成一个JavaScript对象，然后构造一条消息：
// 消息队列中的消息就长这个样子
var message = function () {
callbackFn(response);
}
其中的callbackFn就是前面代码中得到成功响应时的回调函数。
主线程在执行完当前循环中的所有代码后，就会到消息队列取出这条消息(也就是message函数)，并执行它。到此为止，就完成了工作线程对主线程的通知，回调函数也就得到了执行。如果一开始主线程就没有提供回调函数，AJAX线程在收到HTTP响应后，也就没必要通知主线程，从而也没必要往消息队列放消息。
用图表示这个过程就是：
从上文中我们也可以得到这样一个明显的结论，就是：
异步过程的回调函数，一定不在当前这一轮事件循环中执行。
事件循环进阶：macrotask与microtask
一张图展示JavaScript中的事件循环：
一次事件循环：先运行macroTask队列中的一个，然后运行microTask队列中的所有任务。接着开始下一次循环（只是针对macroTask和microTask，一次完整的事件循环会比这个复杂的多）。
JS中分为两种任务类型：macrotask和microtask，在ECMAScript中，microtask称为jobs，macrotask可称为task
它们的定义？区别？简单点可以按如下理解：
macrotask（又称之为宏任务），可以理解是每次执行栈执行的代码就是一个宏任务（包括每次从事件队列中获取一个事件回调并放到执行栈中执行）
每一个task会从头到尾将这个任务执行完毕，不会执行其它
浏览器为了能够使得JS内部task与DOM任务能够有序的执行，会在一个task执行结束后，在下一个 task 执行开始前，对页面进行重新渲染
（task->渲染->task->...）
microtask（又称为微任务），可以理解是在当前 task 执行结束后立即执行的任务
也就是说，在当前task任务后，下一个task之前，在渲染之前
所以它的响应速度相比setTimeout（setTimeout是task）会更快，因为无需等渲染
也就是说，在某一个macrotask执行完后，就会将在它执行期间产生的所有microtask都执行完毕（在渲染前）
分别很么样的场景会形成macrotask和microtask呢？
macroTask: 主代码块, setTimeout, setInterval, setImmediate, requestAnimationFrame, I/O, UI rendering（可以看到，事件队列中的每一个事件都是一个macrotask）
microTask: process.nextTick, Promise, Object.observe, MutationObserver
补充：在node环境下，process.nextTick的优先级高于Promise，也就是可以简单理解为：在宏任务结束后会先执行微任务队列中的nextTickQueue部分，然后才会执行微任务中的Promise部分。
另外，setImmediate则是规定：在下一次Event Loop（宏任务）时触发（所以它是属于优先级较高的宏任务），（Node.js文档中称，setImmediate指定的回调函数，总是排在setTimeout前面），所以setImmediate如果嵌套的话，是需要经过多个Loop才能完成的，而不会像process.nextTick一样没完没了。
实践：上代码
我们以setTimeout、process.nextTick、promise为例直观感受下两种任务队列的运行方式。
console.log('main1');
process.nextTick(function() {
console.log('process.nextTick1');
});
setTimeout(function() {
console.log('setTimeout');
process.nextTick(function() {
console.log('process.nextTick2');
});
}, 0);
new Promise(function(resolve, reject) {
console.log('promise');
resolve();
}).then(function() {
console.log('promise then');
});
console.log('main2');
别着急看答案，先以上面的理论自己想想，运行结果会是啥？
最终结果是这样的：
main1
promise
main2
process.nextTick1
promise then
setTimeout
process.nextTick2
process.nextTick 和 promise then在 setTimeout 前面输出，已经证明了macroTask和microTask的执行顺序。但是有一点必须要指出的是。上面的图容易给人一个错觉，就是主进程的代码执行之后，会先调用macroTask，再调用microTask，这样在第一个循环里一定是macroTask在前，microTask在后。
但是最终的实践证明：在第一个循环里，process.nextTick1和promise then这两个microTask是在setTimeout这个macroTask里之前输出的，这是为什么呢？
因为主进程的代码也属于macroTask（这一点我比较疑惑的是主进程都是一些同步代码，而macroTask和microTask包含的都是一些异步任务，为啥主进程的代码会被划分为macroTask，不过从实践来看确实是这样，而且也有理论支撑：【翻译】Promises/A+规范）。
主进程这个macroTask（也就是main1、promise和main2）执行完了，自然会去执行process.nextTick1和promise then这两个microTask。这是第一个循环。之后的setTimeout和process.nextTick2属于第二个循环
别看上面那段代码好像特别绕，把原理弄清楚了，都一样 ~
requestAnimationFrame、Object.observe(已废弃) 和 MutationObserver这三个任务的运行机制大家可以从上面看到，不同的只是具体用法不同。重点说下UI rendering。在HTML规范：event-loop-processing-model里叙述了一次事件循环的处理过程，在处理了macroTask和microTask之后，会进行一次Update the rendering，其中细节比较多，总的来说会进行一次UI的重新渲染。
事件循环机制进一步补充
这里就直接引用一张图片来协助理解：（参考自Philip Roberts的演讲《Help, I’m stuck in an event-loop》）
上图大致描述就是：
主线程运行时会产生执行栈，栈中的代码调用某些api时，它们会在事件队列中添加各种事件（当满足触发条件后，如ajax请求完毕）
而栈中的代码执行完毕，就会读取事件队列中的事件，去执行那些回调
如此循环
注意，总是要等待栈中的代码执行完毕后才会去读取事件队列中的事件
参考:
- JS是单线程，你了解其运行机制吗？
- 深入理解JavaScript的执行过程--单线程的JS
- JavaScript工作原理（一）：引擎，运行时，调用堆栈