诊断这种崩溃的一个辅助手段是捕捉由各种线程抛出的异常并在退出之前通知该问题的依靠线程。这正是我在清单 2 中所做的。
清单 2. 把错误通知给客户机线程的示例
import Java.util.Vector;
public class Server2 extends Thread {
Client2 client;
int counter;
public Server2(Client2 _client) {
this.client = _client;
this.counter = 0;
}
public void run() {
try {
while (counter < 10) {
this.client.queue.addElement(new Integer(counter));
counter++;
}
throw new RuntimeException("counter >= 10");
}
catch (Exception e) {
this.client.interruptFlag = true;
throw new RuntimeException(e.toString());
}
}
public static void main(String[] args) {
Client2 c = new Client2();
Server2 s = new Server2(c);
c.start();
s.start();
}
}
class Client2 extends Thread {
Vector queue;
boolean interruptFlag;
public Client2() {
this.queue = new Vector();
this.interruptFlag = false;
}
public void run() {
while (! interruptFlag) {
if (! (queue.size() == 0)) {
processNextElement();
}
}
// Processes whatever elements remain on the queue before exiting.
while (! (queue.size() == 0)) {
processNextElement();
}
System.out.flush();
}
private void processNextElement() {
Object next = queue.elementAt(0);
queue.removeElementAt(0);
System.out.println(next);
}
}
处理被抛出的异常的其它选项可能是调用 System.exit。这个选项在程序的主线程发生崩溃而其它线程不治理任何临界资源的时候是有意义的。然而在其它情况下，这可能是危险的。例如，考虑这样一个示例，其它线程中的一个正在治理一个打开的文件。假如这是实际的情况，那么只是退出程序会导致资源泄漏。
即使在上面的简单示例中，在 server 线程中调用 System.exit 也会导致 client 未处理其队列上的任何剩余元素就退出。
事实上，就是这样的问题促使 Sun 不建议线程的 stop 方法。由于强行停止一个线程会使资源陷入非一致状态，所以 stop 方法破坏了语言的安全性模型。
想了解 Sun 的更多不建议理由，请参阅参考资料。
总结
这里是本周错误模式的总结：
模式：孤线程
症状：一个锁定多线程程序，它具有或不具有将堆栈跟踪打印到标准错误。
致因：多个程序线程一直等待来自某个线程的输入，而该线程在抛出一个未被捕捉的异常后就退出了。
治疗和预防措施：把异常处理代码放到主线程中以在崩溃来临之际通知依靠线程。
参考资料
参加本文的讨论论坛。
阅读关于为什么不建议 Thread.stop 的 Sun 的解释。
Neel V. Kumar 在他的文章“Java 程序中的多线程”（developerWorks，2000 年 3 月）中提供调试多线程 Java 的途径。