【发布时间】:2012-11-22 18:19:38
【问题描述】:
我的处境很奇怪。在我的网络服务器(tomcat)中,在网络请求中,我基本上需要取消以前的请求。我引用了执行上一个请求的线程。所以我可以直接中断那个线程,然后节点会做剩下的事情。
我知道你不应该中断你不拥有的线程。但是在这种情况下中断tomcat线程是否安全?另一种方法是什么?维护自己的线程池是浪费资源和开销
【问题讨论】:
标签: java multithreading tomcat
我的处境很奇怪。在我的网络服务器(tomcat)中,在网络请求中,我基本上需要取消以前的请求。我引用了执行上一个请求的线程。所以我可以直接中断那个线程,然后节点会做剩下的事情。
我知道你不应该中断你不拥有的线程。但是在这种情况下中断tomcat线程是否安全?另一种方法是什么?维护自己的线程池是浪费资源和开销
【问题讨论】:
标签: java multithreading tomcat
维护自己的线程池是一种资源浪费,但在其他方面也有好处,比如应用服务器的稳定性。因此,您需要决定什么更重要:几千字节的内存和 CPU 周期,还是一个稳定、可靠的应用程序。
中断另一个线程的问题是您通常无法确定其他线程在代码中的什么位置。您可能希望为此使用锁定:
线程 A 在可以安全中断的情况下锁定某些东西,线程 B 检查锁定,如果无法获得,则中断 A。
但是当A即将放弃锁,B检查锁,A解锁并开始清理,B发送中断时会发生什么?
所以你真的应该使用自己的线程池。
【讨论】:
我不会这样做。不是 100% 确定为什么,但我认为这些线程来自 Tomcat 自己的工作线程池,并且一个接一个地杀死它们会/可能最终导致一个无响应的 Tomcat 实例。 (这只是一个假设)。
我认为“维护自己的线程池是浪费资源和开销”。我认为这是一件小事,线程池是个好人,不要害怕他们。我不知道您的应用程序的详细信息,但我认为如果您通过 JConsole 测量开销,您可以决定进行一些优化,线程池不太可能成为瓶颈。
我可以向您建议的最好的想法是完全重新设计:通过将任务提交到ExecutorService 或其他东西,使用短返回 HTTP 请求在后台启动长时间运行的异步操作。这样就不需要损害 Tomcat 自己的线程,并且从用户/客户端的角度来看,您的应用程序的整体可用性也可以得到改善。
总结一下:我认为做你提到的事情是不安全的,上一段描述了一种可能的其他方式来做你想做的事情。
【讨论】: