Servlet 3.0 异步处理详解

Github地址

相关系列文章:

Servlet 3.0 开始提供了AsyncContext用来支持异步处理请求,那么异步处理请求到底能够带来哪些好处?

Web容器一般来说处理请求的方式是:为每个request分配一个thread。我们都知道thread的创建不是没有代价的,Web容器的thread pool都是有上限的。 那么一个很容易预见的问题就是,在高负载情况下,thread pool都被占着了,那么后续的request就只能等待,如果运气不好客户端会报等待超时的错误。 在AsyncContext出现之前,解决这个问题的唯一办法就是扩充Web容器的thread pool。

但是这样依然有一个问题,考虑以下场景:

有一个web容器,线程池大小200。有一个web app,它有两个servlet,Servlet-A处理单个请求的时间是10s,Servlet-B处理单个请求的时间是1s。 现在遇到了高负载,有超过200个request到Servlet-A,如果这个时候请求Servlet-B就会等待,因为所有HTTP thread都已经被Servlet-A占用了。 这个时候工程师发现了问题,扩展了线程池大小到400,但是负载依然持续走高,现在有400个request到Servlet-A,Servlet-B依然无法响应。

看到问题了没有,因为HTTP thread和Worker thread耦合在了一起(就是同一个thread),所以导致了当大量request到一个耗时操作时,就会将HTTP thread占满,导致整个Web容器就会无法响应。

但是如果使用AsyncContext,我们就可以将耗时的操作交给另一个thread去做,这样HTTP thread就被释放出来了,可以去处理其他请求了。

注意,只有使用AsyncContext才能够达到上面所讲的效果,如果直接new Thread()或者类似的方式的,HTTP thread并不会归还到容器。

下面是一个官方的例子:

@WebServlet(urlPatterns={"/asyncservlet"}, asyncSupported=true)
public class AsyncServlet extends HttpServlet {
   /* ... Same variables and init method as in SyncServlet ... */

   @Override
   public void doGet(HttpServletRequest request, 
                     HttpServletResponse response) {
      response.setContentType("text/html;charset=UTF-8");
      final AsyncContext acontext = request.startAsync();
      acontext.start(new Runnable() {
         public void run() {
            String param = acontext.getRequest().getParameter("param");
            String result = resource.process(param);
            HttpServletResponse response = acontext.getResponse();
            /* ... print to the response ... */
            acontext.complete();
            }
      });
   }
}

陷阱

在这个官方例子里,每个HTTP thread都会开启另一个Worker thread来处理请求,然后把HTTP thread就归还给Web容器。但是看AsyncContext.start()方法的javadoc:

Causes the container to dispatch a thread, possibly from a managed thread pool, to run the specified Runnable.

实际上这里并没有规定Worker thread到底从哪里来,也许是HTTP thread pool之外的另一个thread pool?还是说就是HTTP thread pool?

The Limited Usefulness of AsyncContext.start()文章里写道:不同的Web容器对此有不同的实现,不过Tomcat实际上是利用HTTP thread pool来处理AsyncContext.start()的。

这也就是说,我们原本是想释放HTTP thread的,但实际上并没有,因为有HTTP thread依然被用作Worker thread,只不过这个thread和接收请求的HTTP thread不是同一个而已。

这个结论我们也可以通过AsyncServlet1SyncServlet的Jmeter benchmark看出来,两者的throughput结果差不多。启动方法:启动Main,然后利用Jmeter启动benchmark.jmx(Tomcat默认配置下HTTP thread pool=200)。

使用ExecutorService

前面看到了Tomcat并没有单独维护Worker thread pool,那么我们就得自己想办法搞一个,见AsyncServlet2,它使用了一个带Thread pool的ExecutorService来处理AsyncContext。

其他方式

所以对于AsyncContext的使用并没有固定的方式,你可以根据实际需要去采用不同的方式来处理,为此你需要一点Java concurrent programming的知识。

对于性能的误解

AsyncContext的目的并不是为了提高性能,也并不直接提供性能提升,它提供了把HTTP thread和Worker thread解藕的机制,从而提高Web容器的响应能力

不过AsyncContext在某些时候的确能够提高性能,但这个取决于你的代码是怎么写的。 比如:Web容器的HTTP thread pool数量200,某个Servlet使用一个300的Worker thread pool来处理AsyncContext。 相比Sync方式Worker thread pool=HTTP thread pool=200,在这种情况下我们有了300的Worker thread pool,所以肯定能够带来一些性能上的提升(毕竟干活的人多了)。

相反,如果当Worker thread的数量<=HTTP thread数量的时候,那么就不会得到性能提升,因为此时处理请求的瓶颈在Worker thread。 你可以修改AsyncServlet2的线程池大小,把它和SyncServlet比较benchmark结果来验证这一结论。

一定不要认为Worker thread pool必须比HTTP thread pool大,理由如下:

  1. 两者职责不同,一个是Web容器用来接收外来请求,一个是处理业务逻辑
  2. thread的创建是有代价的,如果HTTP thread pool已经很大了再搞一个更大的Worker thread pool反而会造成过多的Context switch和内存开销
  3. AsyncContext的目的是将HTTP thread释放出来,避免被操作长期占用进而导致Web容器无法响应

所以在更多时候,Worker thread pool不会很大,而且会根据不同业务构建不同的Worker thread pool。 比如:Web容器thread pool大小200,一个慢速Servlet的Worker thread pool大小10,这样一来,无论有多少请求到慢速操作,它都不会将HTTP thread占满导致其他请求无法处理。

相关资料

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏区块链入门

第2课 不懂技术,如何抢注热门EOS账号?

【本文目标】 通过本文学习,可以抢注12位的EOS心意账号,便于后续增值和使用。 【前置条件】 本文无技术前置条件,但是需要有EOS代币的创世账号。 如...

1723
来自专栏smy

Gitbash如何支持交互式命令?如何让gitbash的命令不乱码?winpty是什么鬼?干嘛用的?

 winpty 是一个 Windows 软件包,提供了类似 Unix pty-master 一样的接口,用于实现控制台程序之间的通讯。该软件包包括一个开发库 (...

2894
来自专栏Golang语言社区

跳出Go module的泥潭

Go 1.11 前天已经正式发布了,这个版本包含了两个最重要的feature就是 module和web assembly。虽然也有一些简单的教程介绍了go mo...

4573
来自专栏耕耘实录

RHEL 7及CentOS 7 彻底禁用IPv6的方法

版权声明:本文为耕耘实录原创文章,各大自媒体平台同步更新。欢迎转载,转载请注明出处,谢谢

1814
来自专栏java一日一条

生产者消费者模式

在并发编程中使用生产者和消费者模式能够解决绝大多数并发问题。该模式通过平衡生产线程和消费线程的工作能力来提高程序的整体处理数据的速度。

961
来自专栏北京马哥教育

Linux之HA高可用集群的基础概念总结

HA(High Availability)高可用集群,其特点为根据实际需求为前端Diretor,后端RS-server,数据库服务器,共享存储等集群节点做一个...

4306
来自专栏解Bug之路

解Bug之路-记一次JVM堆外内存泄露Bug的查找 顶

JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存,同时对物理内存的使用做了定量的分析,从而实锤了Bug的源头。笔...

984
来自专栏程序员的碎碎念

如何解决Python包依赖问题

以简洁高效(指编程较为高效, 而不是运行速度)出名的Python, 在包依赖问题上有时候让人挠头.

1852
来自专栏微服务生态

论代码级性能优化变迁之路(一)

大家好,很久没有和大家一起讨论技术了,那么今天我将和大家一起探讨我负责的某项目的性能变迁之路。

822
来自专栏Java架构

今咱们来聊聊JVM 堆外内存泄露的BUG是如何查找的

JVM的堆外内存泄露的定位一直是个比较棘手的问题。此次的Bug查找从堆内内存的泄露反推出堆外内存,同时对物理内存的使用做了定量的分析,从而实锤了Bug的源头。笔...

1.2K17

扫码关注云+社区

领取腾讯云代金券