ServletRequest startAsync（）的有用性有限

前段时间我遇到了Servlet 3.0中AsyncContext.start（…）的目的是什么？ 题。引用上述方法的Javadoc ：

使容器调度线程（可能从托管线程池中）运行指定的Runnable 。

提醒大家， AsyncContext是Servlet 3.0规范中定义的一种标准方式，用于异步处理HTTP请求。基本上，HTTP请求不再绑定到HTTP线程，这使我们以后可以使用更少的线程来处理它。事实证明，该规范提供了一个API，用于处理其他不同线程池中的异步线程。首先，我们将了解该功能在Tomcat和Jetty中是如何被完全破坏和无用的，然后我们将讨论为什么该功能的用途普遍存在疑问。

我们的测试servlet只会在给定的时间内睡眠。在正常情况下，这是可伸缩性的杀手，因为即使休眠的Servlet不会消耗CPU，但是与该特定请求绑定的休眠的HTTP线程也会消耗内存，并且其他传入请求都无法使用该线程。在我们的测试设置中，我将HTTP工作线程的数量限制为10个，这意味着即使应用程序本身几乎完全处于空闲状态，也只有10个并发请求完全阻塞了该应用程序（外部没有响应）。显然，睡眠是可扩展性的敌人。

@WebServlet(urlPatterns = Array("/*"))
class SlowServlet extends HttpServlet with Logging {protected override def doGet(req: HttpServletRequest, resp: HttpServletResponse) {logger.info("Request received")val sleepParam = Option(req.getParameter("sleep")) map {_.toLong}TimeUnit.MILLISECONDS.sleep(sleepParam getOrElse 10)logger.info("Request done")}
}

对这段代码进行基准测试可以发现，只要并发连接数低于HTTP线程数，平均响应时间就会接近sleep参数。毫不奇怪，一旦我们超过HTTP线程数，响应时间就会开始增加。第十一连接必须等待任何其他请求完成并释放工作线程。当并发级别超过100时，Tomcat开始断开连接-太多的客户端已排队。

那么花哨的AsyncContext.start()方法又如何呢（不要与ServletRequest.startAsync()混淆）？根据JavaDoc，我可以提交任何Runnable ，并且容器将使用某些托管线程池来处理它。这将在一定程度上有所帮助，因为我不再阻止HTTP工作线程（但仍使用servlet容器中某个位置的另一个线程）。快速切换到异步servlet：

@WebServlet(urlPatterns = Array("/*"), asyncSupported = true)
class SlowServlet extends HttpServlet with Logging {protected override def doGet(req: HttpServletRequest, resp: HttpServletResponse) {logger.info("Request received")val asyncContext = req.startAsync()asyncContext.setTimeout(TimeUnit.MINUTES.toMillis(10))asyncContext.start(new Runnable() {def run() {logger.info("Handling request")val sleepParam = Option(req.getParameter("sleep")) map {_.toLong}TimeUnit.MILLISECONDS.sleep(sleepParam getOrElse 10)logger.info("Request done")asyncContext.complete()}})}
}

我们首先启用异步处理，然后简单地将sleep()移至Runnable并希望移至其他线程池中，从而释放HTTP线程池。快速压力测试揭示了一些出乎意料的结果（此处：响应时间与并发连接数）：

猜猜是什么，响应时间与根本没有异步支持的响应时间完全相同 （！）。仔细检查后，我发现当调用AsyncContext.start() ，Tomcat将给定的任务提交回……HTTP工作线程池，即用于所有HTTP请求！基本上，这意味着我们发布了一个HTTP线程，只是为了在稍后的一毫秒内使用（甚至可能是同一线程）。 在Tomcat中调用AsyncContext.start()绝对没有好处。我不知道这是错误还是功能。一方面，这显然不是API设计人员想要的。假定servlet容器管理单独的独立线程池，因此HTTP工作线程池仍然可用。我的意思是，异步处理的全部目的是逃避HTTP池。 Tomcat假装将我们的工作委托给另一个线程，而它仍然使用原始的工作线程池。

那么，为什么我认为这是一个功能？因为Jetty以完全相同的方式“破坏”了……无论它是按设计运行还是仅是不良的API实现，因此在Tomcat和Jetty中使用AsyncContext.start()都是没有意义的，并且只会不必要地使代码复杂化。它不会给您任何好处，该应用程序在高负载下的工作原理完全相同，就好像根本没有异步逻辑一样。

但是，如何在正确的实现（例如IBM WAS）上使用此API功能呢？更好，但API仍然没有像在扩展性方面给我们带来太多好处。再次说明：异步处理的全部要点是能够将HTTP请求与基础线程分离，最好通过使用同一线程处理多个连接来实现。

AsyncContext.start()将在单独的线程池中运行提供的Runnable 。您的应用程序仍然可以响应，可以处理普通的请求，而您决定异步处理的长期运行的请求则在单独的线程池中处理。更好的是，不幸的是线程池和每个连接线程的成语仍然是瓶颈。对于JVM，启动什么类型的线程都没有关系–它们仍然占用内存。因此，我们不再阻塞HTTP工作线程，但就我们可以支持的并发长期运行任务而言，我们的应用程序具有更大的可伸缩性。

在这个带有休眠servlet的简单，不现实的示例中，实际上，我们可以使用Servlet 3.0异步支持（只有一个额外的线程）并且不使用AsyncContext.start()来支持数千个并发（等待）连接。你知道如何？提示： ScheduledExecutorService 。

后记：斯卡拉善良

我差点忘了。尽管示例是用Scala编写的，但我还没有使用任何出色的语言功能。这是一个：隐式转换。使它在您的范围内可用：

implicit def blockToRunnable[T](block: => T) = new Runnable {def run() {block}
}

突然之间，您可以使用代码块来代替手动和显式实例化Runnable ：

asyncContext start {logger.info("Handling request")val sleepParam = Option(req.getParameter("sleep")) map { _.toLong}TimeUnit.MILLISECONDS.sleep(sleepParam getOrElse 10)logger.info("Request done")asyncContext.complete()
}

甜！

参考： Javax 和 servlet 社区的 JCG合作伙伴 Tomasz Nurkiewicz提供的javax.servlet.ServletRequest.startAsync（）用途有限。