处理非正常的线程

阳光穿透心脏的1/2处 2024-03-16 13:01 57阅读 0赞

当单线程的控制台程序由于发生了一个未捕获的异常而终止时，程序将停止运行，并产生与程序正常输出非常不同的栈追踪信息，这种情况是很容易理解的。然而，如果并发程序中的某个线程发生故障，那么通常并不会如此明显。在控制台中可能会输出栈追踪信息，但没有人会观察控制台。此外，当线程发生故障时，应用程序可能看起来仍然在工作，所以这个失败很可能会被忽略。幸运的是，我们有可以监测并防止在程序中“遗漏”线程的方法。

导致线程提前死亡的最主要原因就是RuntimeException。由于这些异常表示出现了某种编程错误或者其他不可修复的错误，因此它们通常不会被捕获。它们不会在调用栈中逐层传递，而是默认地在控制台中输出栈追踪信息，并终止线程。

线程非正常退出的后果可能是良性的，也可能是恶性的，这要取决于线程在应用程序中的作用。虽然在线程池中丢失一个线程可能会对性能带来一定影响，但如果程序能在包含50个线程的线程池上运行良好，那么在包含49个线程的线程池上通常也能运行良好。然而，如果在GUI程序中丢失了事件分派线程，那么造成的影响将非常显著——应用程序将停止处理事件并且GUI会因此失去响应。在第6章的OutOfTime 中给出了由于遗漏线程而造成的严重后果：Timer 表示的服务将永远无法使用。

任何代码都可能抛出一个RuntimeException。每当调用另一个方法时，都要对它的行为保持怀疑，不要盲目地认为它一定会正常返回，或者一定会抛出在方法原型中声明的某个已检查异常。对调用的代码越不熟悉，就越应该对其代码行为保持怀疑。

在任务处理线程(例如线程池中的工作者线程或者Swing 的事件派发线程等)的生命周期中，将通过某种抽象机制(例如Runnable)来调用许多未知的代码，我们应该对在这些线程中执行的代码能否表现出正确的行为保持怀疑。像Swing 事件线程这样的服务可能只是因为某个编写不当的事件处理器抛出NullPointerException 而失败，这种情况是非常糟糕的。因此，这些线程应该在try-catch 代码块中调用这些任务，这样就能捕获那些未检查的异常了，或者也可以使用try-finally 代码块来确保框架能够知道线程非正常退出的情况，并做出正确的响应。在这种情况下，你或许会考虑捕获RuntimeException，即当通过Runnable这样的抽象机制来调用未知的和不可信的代码时。⊖

在程序清单7-23 中给出了如何在线程池内部构建一个工作者线程。如果任务抛出了一个未检查异常，那么它将使线程终结，但会首先通知框架该线程已经终结。然后，框架可能会用新的线程来代替这个工作线程，也可能不会，因为线程池正在关闭，或者当前已有足够多的线程能满足需要。ThreadPoolExecutor和Swing都通过这项技术来确保行为糟糕的任务不会影响到后续任务的执行。当编写一个向线程池提交任务的工作者线程类时，或者调用不可信的外部代码时(例如动态加载的插件)，使用这些方法中的某一种可以避免某个编写得糟糕的任务或插件不会影响调用它的整个线程。

程序清单7-23典型的线程池工作者线程结构

public void run()\{

Throwable thrown =null;

try \{

while (!isInterrupted())

runTask(getTaskFromWorkQueue());

\}catch (Throwable e)\{

thrown =e;

\}finally \{

threadExited(this, thrown);

这项技术的安全性存在着一些争议。当线程抛出一个未检查异常时，整个应用程序都可能受到影响。但其替代方法——关闭整个应用程序，通常是更不切实际的。

未捕获异常的处理

上节介绍了一种主动方法来解决未检查异常。在Thread API中同样提供了Uncaught-ExceptionHandler，它能检测出某个线程由于未捕获的异常而终结的情况。这两种方法是互补的，通过将二者结合在一起，就能有效地防止线程泄漏问题。

当一个线程由于未捕获异常而退出时，JVM会把这个事件报告给应用程序提供的UncaughtExceptionHandler异常处理器(见程序清单7-24)。如果没有提供任何异常处理器,那么默认的行为是将栈追踪信息输出到System. err。θ

程序清单7-24 UncaughtExceptionHandler接口

public interface UncaughtExceptionHandler \{

void uncaught Exception(Thread t, Throwable e);

异常处理器如何处理未捕获异常，取决于对服务质量的需求。最常见的响应方式是将一个错误信息以及相应的栈追踪信息写入应用程序日志中，如程序清单7-25所示。异常处理器还可以采取更直接的响应，例如尝试重新启动线程，关闭应用程序，或者执行其他修复或诊断等操作。

程序清单7-25将异常写入日志的UncaughtExceptionHandler

public class UEHLogger implements Thread. Uncaught ExceptionHandler \{

public void uncaughtException(Thread t, Throwable e)\{

Logger logger =Logger. getAnonymousLogger();

logger. log(Level. SEVERE,

"Thread terminated with exception:"+. t. getName(),

e) ;

在运行时间较长的应用程序中，通常会为所有线程的未捕获异常指定同一个异常处理器，并且该处理器至少会将异常信息记录到日志中。

要为线程池中的所有线程设置一个UncaughtExceptionHandler,需要为ThreadPool-Executor的构造函数提供一个ThreadFactory。(与所有的线程操控一样，只有线程的所有者

⊖在Java 5.0之前,控制UncaughtExceptionHandler的唯一方法就是对ThreadGroup进行子类化。在Java 5.0及之后的版本中,可以通过Thread. setUncaughtExceptionHandler为每个线程设置一个Uncaught-ExceptionHandler,还可以使用setDefaultUncaughtExceptionHandier来设置默认的UncaughtException-Handler。然而，在这些异常处理器中，只有其中一个将被调用---JVM 首先搜索每个线程的异常处理器，然后再搜索一个ThreadGroup的异常处理器。ThreadGroup中的默认异常处理器实现将异常处理工作逐层委托给它的上层ThreadGroup，直至其中某个ThreadGroup的异常处理器能够处理该未捕获异常，否则将一直传递到顶层的ThreadGroup。顶层ThreadGroup的异常处理器委托给默认的系统处理器(如果存在，在默认情况下为空)，否则将把栈追踪信息输出到控制台。

能够改变线程的UncaughtExceptionHandler。)标准线程池允许当发生未捕获异常时结束线程，但由于使用了一个try-finally代码块来接收通知，因此当线程结束时，将有新的线程来代替它。如果没有提供捕获异常处理器或者其他的故障通知机制，那么任务会悄悄失败，从而导致极大的混乱。如果你希望在任务由于发生异常而失败时获得通知，并且执行一些特定于任务的恢复操作，那么可以将任务封装在能捕获异常的Runnable 或Callable 中，或者改写ThreadPoolExecutor的afterExecute方法。

令人困惑的是，只有通过execute 提交的任务，才能将它抛出的异常交给未捕获异常处理器，而通过submit 提交的任务，无论是抛出的未检查异常还是已检查异常，都将被认为是任务返回状态的一部分。如果一个由submit提交的任务由于抛出了异常而结束，那么这个异常将被Future. get 封装在ExecutionException中重新抛出。