Java理论与实践: 嗨，我的线程到哪里去了？ - 编程入门网

当主要的任务处理方面由线程池而不是单个线程来处理时，对于偶然的线程 泄漏的后果有一定程度的保护，因为一个执行得很好的八线程的线程池，用七个 线程完成其工作的效率可能仍可以接受。起初，可能没有任何显著的差异。但是 ，系统性能最终将下降，虽然这种下降的方式不易被察觉。

服务器应用程序中的线程泄漏问题在于不是总是容易从外部检测它。因为大 多数线程只处理服务器的部分工作负载，或可能仅处理特定类型的后台任务，所 以当程序实际上遭遇严重故障时，在用户看来它仍在正常工作。这一点，再加上 引起线程泄漏的因素并不总是留下明显痕迹，就会引起令人惊讶甚或使人迷惑的 应用程序行为。

Java理论与实践: 嗨，我的线程到哪里去了？(2)

RuntimeException 是导致线程死亡的首要原因

当线程抛出未捕获的异常或错误时它们可能消失；而当线程等待的 I/O 操作 永远不会完成，或没人为它们等待的监视器调用 notify() 时，它们只是停止工 作。意外线程死亡的最常见根源是 RuntimeException （如 NullPointerException 、 ArrayIndexOutOfBoundsException 等）。在我们的 示例应用程序中，在通过调用插件对象上的 incomingResponse() 将响应传递回 插件时，可能抛出 RuntimeException 。插件代码可能是由第三方编写的，或者 可能是在编写完应用程序之后编写的，因此应用程序编写者不可能审核其正确性 。如果一些插件抛出 RuntimeException 时某些响应服务线程会终止，这意味着 一个出错的插件会使整个系统崩溃。遗憾的是，这种脆弱性很常见。

当线程抛出未捕获的异常或错误时它们可能消失；而当线程等待的 I/O 操作 永远不会完成，或没人为它们等待的监视器调用 notify() 时，它们只是停止工 作。意外线程死亡的最常见根源是 RuntimeException 的结果很明显，并且对发 生异常的位置有明确的堆栈跟踪，这提供了问题通知以及解决问题的有用信息。 但是，在多线程应用程序中，由于未查出的异常，线程会无声无息地死亡 — 使 得用户和开发人员对于发生的问题和为什么发生这些问题毫无头绪。

处理任务的线程（类似于示例应用程序中的请求和响应处理程序），基本上 花费其整个生命周期穿过某个类似于 Runnable 的抽象障碍物来调用服务方法。 因为我们不知道在这个抽象障碍物的另一边是什么，所以，对于服务方法，我们 应该怀疑，它是不是真好到可以假设它从不抛出未查出异常的程度。如果服务例 程抛出 RuntimeException ，则调用线程应该捕获这个异常，并将它记录到日志 ，然后转到队列中的下一项或关闭线程然后再重新启动它。（后一个选项源自这 样的假定：任何抛出 RuntimeException 或 Error 的代码也可能已经破坏了线 程的状态。）

清单 1 中的代码是典型的从工作队列处理 Runnable 任务的线程，类似于我 们的示例中的入站响应线程。它并不防备抛出任何未查出异常的插件。

清单 1. 不防备 RuntimeException 的工作线程

private class TrustingPoolWorker extends Thread { 　　 public void run() { 　　　　 IncomingResponse ir; 　　　　 while (true) { 　　　　　　 ir = (IncomingResponse) queue.getNext(); 　　　　　　 PlugIn plugIn = findPlugIn(ir.getResponseId()); 　　　　　　 if (plugIn != null) 　　　　　　　　 plugIn.handleMessage(ir.getResponse()); 　　　　　　 else 　　　　　　　　 log("Unknown plug-in for response " + ir.getResponseId()); 　　　　 } 　　 } }

我们不必添加许多代码来使这个工作线程能够更健壮地处理插件代码中的故 障。只要通过捕获 RuntimeException ，然后进行纠正操作，就可以确保我们

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!