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