其实异步的I/O的难点与不适,在NodeJs
,甚至JavaScript
中有这很具体的体现。
难点1:异常处理难。
在处理异常时,我们经常使用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)
})
}
//在编写异步方法时,只要将异步正确的传递给用户的回调方法即可,无需过多处理。
难点2:阻塞代码(曾经我也在业务场景中写过这样的代码,现在想来时不应该的)
var start = new Date()
while(new Date()-start<1000){
//TODO
}
这段代码会持续占用CPU进行判断,与真正的线程睡眠相去甚远,完全破坏了事件循环的调度。由于Node单线程的原因,CPU的资源全都会用于为这段代码服务,导致任何请求都得不到响应。
难点3:回调嵌套过多,出现回调地狱
我们很容易写出下面的代码,在JS或者NodeJs中,当然后面有解决办法,敬请期待。
function a(err,res){
function b(err,res){
function c(err,res){
function d(err,res){
function e(err,res){
}
}
}
}
}
难点4:多线程编程
在浏览器端,HTML5提出了Web Workers 他通过将JS执行与UI渲染相分离,可以很好的利用duo多核CPU提供大量计算服务。但是很遗憾,很多浏览器目前并没有将其实现,导致Web Workers并没有广泛应用起来。 另外Web Workers能解决利用CPU和减少阻塞UI渲染,但是并不能解决UI渲染的效率问题。
在Nodejs端,借鉴了Web Workers的模式,使用child_process ,这要求我们要跨线程的去开发业务逻辑,这在以往的JS使用经验中时很少考虑到的,比较难搞。
难点5:异步转同步
这是书中提出的,开发人员在异步写多了之后,面对同步代码的思想转化问题。我觉我个人而言,我也是从Java 开发慢慢的将精力转移到JS的学习之中的,我属于同步转向异步,所以我觉得并不是很难_。
后续将更新异步IO编程中的主要方式。
敬请期待,祝好!
网友评论