Monthly Archives: December 2013

三种i/o模式:异步模式与阻塞模式的组合

阻塞且同步: read()方法要等到读到数据了才返回,如果没数据就会一直等

非阻塞且同步: read()方法如果发现当前没数据,就会返回; 调用者可以去做别的事情。然后过段时间再读(轮询)

非阻塞且异步:read()方法如果发现当前没数据,会返回; 调用者可以去做别的事情,也不用再轮询,等操作系统把数据读好了,会通过回调方式把数据交给调用者。

阻塞并异步: 没有这样的组合,这种组合也没有意义

归纳一下:

  阻塞/非阻塞:读不到数据方法就不退出,就是阻塞

  同步/异步:   读不到数据需要主动重试,就是同步; 如果数据好了惊醒你,就是异步。

可以看出,”非阻塞且异步“是性能最好的模式,它避免无谓的等待,节省线程数;避免无效读,提高线程的工作效能。

参考材料:
http://www.artima.com/articles/io_design_patterns.html

有必要搞pipeline之类的东西吗?

有必要搞pipeline之类的东西吗? 把各块功能封装成独立的API,然后每个request handler分别调用不同的api组合不就行了吗?这样还免得搞框架,也不用写什么配置文件。

这种质疑不是没有道理,但最近的亲身体会表明,pipeline体系在开发效率、代码正确率上有确有一定优势。

比方说,要加一个切面功能的话,Pipeline模式中开发者要在各个request handler的xml配置中加上一行,API模式中开发者要修改各个 request handler类。

比较:

1. 在xml中加配置肯定比在各个类中加代码更快

2. 在xml中加不易出错,而在各个类代码中改相对容易出错

    a. java代码在结构上不如xml文件清晰,插错地方的可能性比较高

    b. 在java代码中新增API调用语句前要先收集输入,如果插入点的上下文没有直接可用的变量作为输入,则需要重构代码,引发bug隐患; 在xml中配置没有这个问题,因为pipeline体系中强制规定了输入变量应从pipeline context中获取,总是能获取到的。

    c. 在java代码中调用API后要根据输出和异常决定下一步怎么走,这可能导致比较大的流程变更,而且不同的request handler需要做不同的变更,这非常容易出错; 在xml中配置没有这个问题,因为pipeline体系各valve自己已经决定了下一个出口,不需要调用者操心。

总结一下,pipeline体系中的处理结点是特殊的API,它们有高度统一的接口和更高的自恰性,组装起来比普通API更容易,所以应对功能变更的能力也更强。