异步Servlets与同步Servlets

Question

由于支持Servlet 3.0 asynchronous processing。总是使用异步处理会更好吗？或者在什么情况下同步处理更好？

Answer 1

您使用异步servlet获得的最大成果是HTTP push，其中服务器可以在客户端选择时将信息发回客户端，而不是在客户端请求时发回客户端。前期非同步的servlet，这需要长时间运行的HTTP连接，每个捆绑的服务器线程，这是非常低效的。这种新的模式，从连接控制解耦服务器端处理。

Answer 2

异步处理已经推出了针对案件时，有没有必要在整个请求处理周期中保持一个线程。这种情况的典型例子是类似comet的功能。

在任何情况下也不会一文不值使用异步处理，因为通常后端处理消耗线程反正。

Answer 3

阅读文章，Servlet 3.0规范中的异步处理支持有一个非常特殊的用例 - 它被设计用来处理这种情况，即您有一个AJAX应用程序，该应用程序可以在后台触发潜在的长时间运行的进程。

我们需要类似这样的原因是为了响应thread-per-request模型中的一个问题，该模型在客户端每次从服务器请求页面时分配一个线程，而不是为客户端分配单个线程整个会议。这在AJAX之前很有效，当客户端会偶尔发出请求时，但是当AJAX应用程序显着增加客户端请求的数量时，好处就会丢失。

特别是，如果一个AJAX请求触发潜在的缓慢或堵塞的东西，如数据库操作，我们又回到了起点 - 从服务器的线程池线程都可能处于闲置状态。

支持异步处理尝试通过将请求集中到一个队列，使得线程不总是卡在等待过程中可能没有甚至尚未开始请求进行处理的结果，以减轻这一点。简而言之，我们正试图让我们的时间在任何时候都不受欢迎 - 也就是说，减少闲置时间（但可以为其他连接提供服务）。

就像任何新的进展，这是不能被用作一个尺寸适合所有工具的东西。在适当的地方查找应用程序中的特定情况。

Answer 4

我刚刚浏览了链接的文章，这是服务器端的改进，而不是客户端的异步。

总结的文章：

您可能需要使用异步的servlet的情况下，你有请求进来（类似于扑与AJAX请求您的服务器）的负荷，而你不想服务每请求一个线程。在这种情况下，当处理时间需要一点时间时，TPR可能会很危险，导致您耗尽线程池。

作业将卡住成一个作业队列，直到作业完成和响应最终提交时的资源释放，使其能够完成线程可以退休了。

很酷的东西。

Answer 5

其基于requrirement其中任何机会的某个线程这种情况ü应以其它方式使用异步Servlet的不东阳我们不能让这么多线程

得到空闲状态。如果一个servlet或过滤器达到一个潜在的在处理请求时可以阻止操作，它可以将操作分配给异步执行上下文，并立即将与请求关联的线程返回给容器，而不会生成响应。阻塞操作在另一个线程的异步执行上下文中完成，该线程可以生成响应或将请求分派给另一个servlet。

要在一个servlet启用异步处理，设置asyncSupported为true @WebServlet标注的参数如下：

@WebServlet（URL模式= { “/ asyncservlet”}，asyncSupported =真） 公共类AsyncServlet扩展HttpServlet {...}

同步（经典Web应用程序模型） 同步请求阻止客户端，直到操作完成，即浏览器不反应。在这种情况下，浏览器的Java脚本引擎被阻止。

异步（AJAX Web应用程序模型） 异步请求不会阻止客户端，即浏览器响应。此时，用户也可以执行其他操作。在这种情况下，浏览器的Java脚本引擎不会被阻止。

在同步通信中都是激活的，在其中，如在异步无需活性同时例如异步指消息有阻塞操作到一个新的线程和运行相关联的在容器上的螺纹的同时

应用程序服务器中的Web容器通常每个客户端请求使用一个服务器线程。在重负载条件下，容器需要大量线程来满足所有客户端请求。可伸缩性限制包括内存用尽或容器线程池耗尽。要创建可伸缩的Web应用程序，您必须确保没有与请求关联的线程闲置，因此容器可以使用它们来处理新的请求。

有两种常见的情况，其中与请求关联的线程可能处于空闲状态。

The thread needs to wait for a resource to become available or process data before building the response. For example, an application may need to query a database or access data from a remote web service before generating the response. 

The thread needs to wait for an event before generating the response. For example, an application may have to wait for a JMS message, new information from another client, or new data available in a queue before generating the response.