标签：
js程序是构建在事件之上的。输入可能来自不同的外部源。在一些语言中，我们习惯地编写代码来等待某个特定的输入。
var text=downloadSync(‘http://example.com/file.txt‘);
console.log(text);
像这样的形式downloadSync称为同步函数（或阻塞函数）。程序会停止做任何工作，而等待它的输入。在这个例子中，也就是等待从网络上下载文件的结果。由于在等待下载完成的期间，计算机可以做其他有用的工作，因此这样的语言通常为程序员提供一种方法来创建多个线程，即并行执行子计算。它允许程序的一部分停下来等待（阻塞）一个低速的输入，而程序的另一部分可以继续进行独立的工作。
在js中，大多的I/O操作都提供了异步的或非阻塞的API。程序员提供一个回调函数，一旦输入完成就可以被系统调用，而不是程序阻塞在等待结果的线程上。
var text=downloadSync(‘http://example.com/file.txt‘,function(text){
console.log(text);
});
该API初始化下载进行，然后在内部注册表中存储了回调函数后立即返回，而不是被网络请求阻塞。当下载完成之后，系统会将下载完的文件的文本作为参数调用该已注册的回调函数。
随着事件的发生，事件被添加到应用程序的事件队列的末尾。js系统使用一个内部循环机制来执行应用程序。该循环机制每次都拉取队列底部的事件，以接收到这些事件的顺序来调用这些已经注册的js事件处理程序，并将事件的数据作为该事件处理程序的参数。
运行到完成机制担保的好处是当代码运行时，你完全掌握应用程序的状态。根本不必担心一些变量和对象属性的改变由于并发执行代码而超出你的控制。并发编程在js中往往比使用线程和锁的c++,java或c#更容易。
然而，运行到完成机制的不足是，实际上所有你编写的代码支撑着余下应用程序的继续执行。像浏览器这样的交互式应用程序中，一个阻塞的事件处理程序会阻塞任何将被处理的其他用户输入，甚至可能阻塞一个页面的渲染，从而导致页面失去响应的用户体验。在服务器环境中，一个阻塞的事件处理程序可能会阻塞将被处理的其他网络请求，从而导致服务器失去响应。
js并发的一个最重要的规则是绝不要在应用程序事件队列中使用阻塞I/O的API。在浏览器中，甚至几乎没有任何阻塞API是可用的，尽管有一些平台实现了。提供类似于downloadAsync功能的网络I/O的XMLHttpRequest库有一个同步的版本实现，被认为是不好的。对于web应用程序的交互性，同步的I/O会导致灾难性的后果，它在I/O操作完成之前一直会阻塞用户与页面的交互。
相比之下，异步的API用在基于事件的环境中是安全的，它们迫使应用程序逻辑在一个独立的事件循环“轮询”中继续处理。如上面的例子，假设需要几秒钟来下载网络资源，在这段时间里，数量庞大的其他事件很可能发生。在同步的实现中，这些事件就会堆积在事件队列中，而事件循环将停留等待该JS代码执行完成，这将阻塞任何其他事件的处理。在异步的版本中，JS代码注册一个事件处理程序并立即返回，这将在下载完成之前，允许其他处理程序处理这期间的事件。
在主应用程序事件队列不受影响的环境中，阻塞操作很少出问题。例如，web平台提供了Worker的API，该API使得产生大量的并行计算成为可能。不同于传统的线程执行，Workers在一个完全隔离的状态下执行，没有获取全局作用域或应用程序主线程web页面内容的能力。因此，它们不会妨碍主事件队列中运行的代码的执行。在一个Worker中，使用XMLHttpRequest同步的变种很少出问题。下载操作的确会阻塞Worker继续执行，但这并不会阻止页面的渲染或事件队列中的事件响应。在服务器端环境中，阻塞的API在启动一开始是没有问题的，也就是在服务器开始响应输入的请求之前。然后在处理请求期间，浏览器事件队列中存在阻塞的API就是有问题的啦。
异步API使用回调函数来延缓处理代价高昂的操作以避免阻塞主应用程序
js并发地接收事件，但会使用一个事件队列按序地处理事件处理程序
在应用程序事件队列中绝不要使用阻塞的I/O
[Effective JavaScript 笔记]第61条：不要阻塞I/O事件队列
标签：
原文地址：http://www.cnblogs.com/wengxuesong/p/5674544.html
