vs网站开发,网站名称与主办单位,审美网站,python 采集 wordpress前段时间我遇到了Servlet 3.0中AsyncContext.start#xff08;…#xff09;的目的是什么#xff1f; 题。 引用上述方法的Javadoc #xff1a; 使容器调度线程#xff08;可能从托管线程池中#xff09;运行指定的Runnable 。 提醒大家#xff0c; AsyncContext是Servl… 前段时间我遇到了Servlet 3.0中AsyncContext.start…的目的是什么 题。 引用上述方法的Javadoc 使容器调度线程可能从托管线程池中运行指定的Runnable 。 提醒大家 AsyncContext是Servlet 3.0规范中定义的一种标准方式用于异步处理HTTP请求。 基本上HTTP请求不再绑定到HTTP线程这使我们以后可以使用更少的线程来处理它。 事实证明该规范提供了一个API用于处理不同线程池中的异步线程。 首先我们将了解该功能在Tomcat和Jetty中是如何被完全破坏和无用的然后我们将讨论为什么该功能的用途普遍存在疑问。 我们的测试servlet只会在给定的时间内睡眠。 在正常情况下这是可伸缩性的杀手因为即使Hibernate的Servlet不会占用CPU但是与该特定请求绑定的Hibernate的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工作线程但是就我们可以支持的并发长期运行任务而言我们的应用程序具有更大的可伸缩性。 在这个带有Hibernateservlet的简单不现实的示例中实际上我们可以使用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功能有限 。 翻译自: https://www.javacodegeeks.com/2012/05/servletrequest-startasync-limited.html
