其实异步的I/O的难点与不适，在NodeJs、甚至JavaScript中有着很具体的体现。
异常处理难
在处理异常时，我们经常使用try/catch/final的语句块进行异常捕获，但这对于异步编程不太实用。我们来看书中的一个经典示例。
var async = function(callback){
process.nextTick(callback)
}
//上面的async方法为一个异步方法，按照传统的代码模型，我们很容易写出下面的这种代码
try{
async(callback)
}catch(e){
//TODO
}
//上面的这种代码并不能捕获到异步操作中的异常。
//Node在处理异常上形成了一种约定，将异常作为回调函数的第一个实参传回，如果为空值，则表明异步调用没有异常抛出。
var async_new = function(callback){
process.nextTick(function(){
var result = 'something'
if(error){
return callback(error)
}
callback(null,results)
})
}
//在编写异步方法时，只要将异步正确传递给用户的回调方法即可，无需过多处理。
阻塞代码
曾经我也在业务场景中写过这样的代码，现在想来是不应该的。
var start = new Date()
while(new Date()-start<1000){
//TODO
}
这段代码会持续占用CPU进行判断，与真正的线程睡眠相去甚远，完全破坏了事件循环的调度。由于Node单线程的原因，CPU的资源全都会用于为这段代码服务，导致任何请求都得不到响应。
回调嵌套过多
我们很容易写出下面的代码，在JS或者NodeJs中，当然后面有解决办法。
function a(err,res){
function b(err,res){
function c(err,res){
function d(err,res){
function e(err,res){
}
}
}
}
}
多线程编程
在浏览器端，HTML5提出了Web Workers 他通过将JS执行与UI渲染相分离，可以很好的利用duo多核CPU提供大量计算服务。
但是很遗憾，很多浏览器目前并没有将其实现，导致Web Workers并没有广泛应用起来。另外Web Workers能解决利用CPU和减少阻塞UI渲染，但是并不能解决UI渲染的效率问题。
在Nodejs端，借鉴了Web Workers的模式，使用child_process，这要求我们要跨线程的去开发业务逻辑，这在以往的JS使用经验中是很少考虑到的，比较难搞。
异步转同步
这是书中提出的，开发人员在异步写多了之后，面对同步代码的思想转化问题。我觉我个人而言，我也是从Java 开发慢慢的将精力转移到JS的学习之中的，我属于同步转向异步，所以我觉得并不是很难。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
