<b>Java理论与实践: 嗨,我的线程到哪里去了?</b>[Java编程]

当单线程利用程序中的主线程抛出一个未捕捉的非常时,因为掌握台中会打 印仓库跟踪（也因为程序终止）,所以您极大概注意到.但在多线程利用程序中 ,特别是在作为服务器运行并且不与掌握台相连的利用程序中,线程死亡大概成 为不太惹人注目的事件,这会招致部分系统失利,从而产生混乱的利用程序行为 .

在 Java theory and practice十月份的专栏文章 中,我们研究了线程池, 并研究了编写得不精确的线程池会若何“泄露”线程,直到终究丧失全部线程. 大大都线程池实现通过捕捉抛出的非常或重新启动死亡的线程来避免这一点,但 线程泄露的问题并不但限于线程池 ― 利用线程来为工作行列供应服务的服务器 利用程序也大概具有这种问题.当服务器利用程序丧失了一个工作线程（worker thread）时,在较长时间内利用程序仍大概显得一切正常,这使得该问题的真实 缘由难以肯定.

很多利用程序用线程来供应后台服务 ― 处理来自事件行列的任务、从套接 字读取号令或履行 UI 线程以外的长期任务.当由于抛出未捕捉的 RuntimeException 或 Error ,大概只是停下来,等候阻塞的 I/O 操作（本来 未预计到阻塞）,从而惹起这些线程之一死亡时,会发生什么呢?

有时,比方当线程履行由用户启动的长期任务（如拼写查抄）时,用户会注 意到任务没有进展,他们大概会非常终止操作或程序.但别的时间,后台线程执 行“清理保护”任务 ,它们大概消逝很长时间而不被发觉.

示例服务器利用程序

考虑这样一个假定的中间件服务器利用程序,它聚合来自各种输入源的消息 ,然后将它们提交到外部服务器利用程序,从外部利用程序接纳呼应并将呼应路 由回得当的输入源.关于每个输入源,都有一个以其自己的方法承受其输入消息 的插件（通过扫描文件目录、等候套接字衔接、轮询数据库表等）.插件可以由 第三方编写,即便它们是在服务器 JVM 上运行的.这个利用程序拥有（至少） 两个内部工作行列 ― 从插件处接纳的正在等候被发送到服务器的消息（“出站 消息”行列）,以及从服务器接纳的正在等候被传送到得当插件的呼应（“入站 呼应”行列）.通过调用插件对象上的服务例程 incomingResponse() ,消息被 路由到最初发出恳求的插件.

从插件接纳消息后,就被布列到出站消息行列中.由一个或多个从行列读取 消息的线程处理出站消息行列中的消息、记录其根源并将它提交给远程服务器应 用程序（假定通过 Web 服务接口）.远程利用程序终究通过 Web 服务接口返回 呼应,然后我们的服务器将接纳的呼应布列到入站呼应行列中.一个或多个呼应 线程从入站呼应行列读撤消息并将其路由到得当的插件,从而完成往复“路程” .

在这个利用程序中,有两个消息行列,辨别用于出站恳求和入站呼应,差别 的插件内大概也有别的的行列.我们还有几种服务线程,一个从出站消息行列读 取恳求并将其提交给外部服务器,一个从入站呼应行列读取呼应并将其路由到插 件,在用于向套接字或别的外部恳求源供应服务的插件中大概也有一些线程.

线程失利时并不老是显而易见的

假如这些线程中的一个（如呼应分配线程）消逝了,将会发生什么?因为插 件仍可以提交新消息,所以它们大概不会当即注意到某些方面出错了.消息仍将 通过各种输入源到达,并通过我们的利用程序提交到外部服务.因为插件并不期 待当即得到其呼应,因此它仍没有意识到出了问题.最后,接纳的呼应将排满队 列.假如它们存储在内存中,那么终究将耗尽内存.即便不耗尽内存,也会有人 在某个时刻发现呼应得不到传送 ― 但这大概需求一些时间,因为系统的别的方 面仍能正常施展作用.

当主要的任务处理方面由线程池而不是单个线程来处理时,关于无意的线程 泄露的后果有一定程度的保护,因为一个履行得很好的八线程的线程池,用七个 线程完成其工作的效率大概仍可以承受.起先,大概没有任何明显的差别.但是 ,系统性能终究将下降,固然这种下降的方法不易被发觉.

服务器利用程序中的线程泄露问题在于不是老是简单从外部检测它.因为大 大都线程只处理服务器的部份工作负载,或大概仅处理特定范例的后台任务,所 以当程序实际上遭受严重弊端时,在用户看来它仍在正常工作.这一点,再加上 惹起线程泄露的因素并不老是留下明显痕迹,就会惹起令人惊奇甚或令人迷惑的 利用程序行为.

　　以上是“<b>Java理论与实践: 嗨,我的线程到哪里去了?</b>[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：