由异步servlet所想

 

 

我们一直在用程序模拟现实世界的规则，但是有些很常见的规则，当我们引入到计算机中后，确并不一定适用。因为这个虚拟世界的构建规则跟现实世界是有差异的。特别是当我们还在跟硬件，性能做抗争的时候，现实世界的优秀法则往往并不能完全的映射到这个虚拟世界中。

一个简单的例子。当我们去面包店买面包的时候一般过程是这样的，
1.我对店员说：“你好，我要买面包。”
2.店员听到后说：“请稍等...”然后店员去厨房取面包，我在面包店等待...
3.店员拿出面包交给我，我付钱。买面包完成。

这里一共有三个步骤：1.我发出买面包请求。2.店员接受处理我的请求，我等待。3.店员完成请求，返回给我面包。
事情的处理过程很好，规则简单而适用。于是我们的计算机也模拟这个过程，实现了web的请求/应答模式：1.浏览器向web服务器请求资源。2.服务器响应请求，查找资源。3.服务器返回资源，请求完成。

但是仔细看看我们就能发现这个模式的问题：在步骤2店员拿面包的时候我什么都没做！我在等待！在店员拿面包够快的话这样也没什么大问题，我等半分钟，也没浪费多少时间。但是如果面包还在烤炉里，我等了十分钟店员才从厨房出来！那我可要发火了！同步servlet正是这样处理请求的。（注意这里要把servlet当买面包的人而不是把浏览器。）

于是我们开始找解决办法：
1.我等了5分钟，店员如果没出来，我就不买了。到计算机里，就是常见的请求超时处理了。浏览器在访问一个不存在的站点的时候，就会尝试连接一段时间，然后打开错误界面：Internet Explorer 无法显示该网页。
2.店员出来告诉我，面包还在烤，问我愿意等吗？这种处理过程计算机也有使用。3.我在步骤1的时候对店员说：“你好，我要买面包。麻烦面包好了打电话给我，我来取。”在计算机里这确是最棒的解决方案！也就是异步servlet的处理方式：

首先，Servlet接收到请求之后，将请求转交给一个异步线程来执行业务处理，Servlet线程本身返回至容器，异步线程处理完业务以后，可以直接生成响应数据，或者将请求继续转发给其它Servlet。如此一来，Servlet线程不再是一直处于阻塞状态以等待业务逻辑的处理，而是启动异步线程之后可以立即返回。

但是不要因此而以为异步servlet应该取代所有的同步servlet！

当我们把请求交给异步线程来执行业务处理，让Servlet线程本身返回至容器，其实是释放了一个线程，也创建了一个线程，结果是1+1-1=1，还是需要一个线程来为我们服务。资源一点也没节省，处理却更复杂了！那么异步servlet的用途究竟在哪呢？

目前我知道的适用异步servlet的一种情况，就是当我们想实现一种服务器主动与客户端(浏览器)通信的机制(comet)的时候，异步servlet能在这种机制中帮我们极大的节省线程资源。还有一种可能被应用的场景就是对数据库的访问时，但是要实现异步访问数据库，对整个应用的编程模式都会有很大影响！

虽然异步servlet没有那么高的期望值，但我觉得异步处理这种机制本身确是应该大放光彩的！适用场景也非常多：
Ajax，我们发送异步请求来防止程序阻塞。其实异步请求可以完全替代同步请求！
JMS，消息服务最诱人的地方就在与对异步的支持吧。
NIO，事件触发机制其实也有异步请求的影子。

我觉得任何的请求/应答模式都应该优先考虑异步请求的方式实现。异步请求是高效而灵活的。只是你可能需要点时间适应callBack的编程模式。