【问题标题】:What is the intended use-case for AsyncContext.start()?AsyncContext.start() 的预期用例是什么?
【发布时间】:2012-04-25 06:08:22
【问题描述】:

有人刚刚指出 AsyncContext.start() 是一种从 Web 容器中启动线程的方法。我想知道将此调用添加到 Java EE 的预期用例是什么?

【问题讨论】:

    标签: jakarta-ee servlets servlet-3.0


    【解决方案1】:

    AsyncContext.start() 不太可能启动一个新线程。它几乎肯定会使用容器线程(来自用于处理请求的同一线程池)。例如,Tomcat 将始终使用请求处理线程池中的容器线程。

    用例是您不希望“主”线程在主线程可以继续之前必须等待您放入 Runnable 中的任何内容完成的任何情况。

    我能想到的大多数示例都是相当人为的,但是如果您使用 Servlet 3.0 异步实现了某种消息传递应用程序,并带有 5 个连接的客户端,则主线程可能会遍历 5 个客户端中每个客户端的 AsyncContext 并调用 start( ) 在每个上下文中发送广播消息。这样主线程就不会被慢速客户端阻塞。

    【讨论】:

    • 嗨,感谢您的回答。但是,您提出的 2 点没有足够的理由或证据: #1:用于将很快完成的工作;和#2:几乎可以肯定使用容器线程。 #2 是 #1 的合理结果,所以关键问题仍然存在:我们如何知道这确实是预期的用例? .start() 与启动线程一样通用;并且文档中没有暗示预计它是短暂的;所以启动线程的一般方式允许设计者启动任意长寿命线程
    • #1 不是我提出的观点,#2 是在规范中说明的,因为使用大多数(所有?)容器所做的单独线程池没有明显的好处
    • 我认为游泳池意味着短暂。但我会在规范中阅读更多内容。
    • 异步 API 的全部意义在于更有效地使用线程。重要的不是运行需要多长时间,而是线程正在做有用的工作。通常,任务很短,但不一定非要如此。使用容器线程池的原因是它为做有用工作的并发线程的数量设置了一个易于控制的上限。没有它,服务器很容易超载。
    猜你喜欢
    • 2012-04-21
    • 2013-12-30
    • 2013-05-31
    • 2014-04-16
    • 2012-09-23
    • 1970-01-01
    • 2014-11-24
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多