另外一种方法是（这也是一种 理想的 方法）-- 编译器应 自动 使用一个读/写锁来同步访问非不变 static 域，这样，程序员就不必担心这个问题。

后台线程的突然结束

当所有的非后台线程终止后，后台线程都被突然结束。当后台线程创建了一些全局资源（例如一个数据库连接或一个临时文件），而后台线程结束时这些资源没有被关闭或删除就会导致问题。

对于这个问题，我建议制定规则，使 Java 虚拟机在下列情况下不关闭应用程序：

有任何非后台线程正在运行，或者：

有任何后台线程正在执行一个 synchronized 方法或 synchronized 代码块。

后台线程在它执行完 synchronized 块或 synchronized 方法后可被立即关闭。

重新引入 stop() 、 suspend() 和 resume() 关键字

由于实用原因这也许不可行，但是我希望不要废除 stop() (在 Thread 和 ThreadGroup 中)。但是，我会改变 stop() 的语义，使得调用它时不会破坏已有代码。但是，关于 stop() 的问题，请记住，当线程终止后， stop() 将释放所有锁，这样可能潜在地使正在此对象上工作的线程进入一种不稳定（局部修改）的状态。由于停止的线程已释放它在此对象上的所有锁，所以这些对象无法再被访问。

对于这个问题，可以重新定义 stop() 的行为，使线程只有在不占有任何锁时才立即终止。如果它占据着锁，我建议在此线程释放最后一个锁后才终止它。可以使用一个和抛出异常相似的机制来实现此行为。被停止线程应设置一个标志，并且当退出所有同步块时立即测试此标志。如果设置了此标志，就抛出一个隐式的异常，但是此异常应不再能被捕捉并且当线程结束时不会产生任何输出。注意，微软的 NT 操作系统不能很好地处理一个外部指示的突然停止(abrupt)。（它不把 stop 消息通知动态连接库，所以可能导致系统级的资源漏洞。）这就是我建议使用类似异常的方法简单地导致 run() 返回的原因。

与这种和异常类似的处理方法带来的实际问题是，你必需在每个 synchronized 块后都插入代码来测试“stopped”标志。并且这种附加的代码会降低系统性能并增加代码长度。我想到的另外一个办法是使 stop() 实现一个“延迟的(lazy)”停止，在这种情况下，在下次调用 wait() 或 yield() 时才终止。我还想向 Thread 中加入一个 isStopped() 和 stopped() 方法（此时， Thread 将像 isInterrupted() 和 interrupted() 一样工作，但是会检测 “stop-requested”的状态)。这种方法不向第一种那样通用，但是可行并且不会产生过载。

应把 suspend() 和 resume() 方法放回到 Java 编程语言中，它们是很有用的，我不想被当成是幼儿园的小孩。由于它们可能产生潜在的危险（当被挂起时，一个线程可以占据一个锁）而去掉它们是没有道理的。请让我自己来决定是否使用它们。如果接收的线程正占据着锁，Sun 公司应该把它们作为调用 suspend() 的一个运行时间异常处理(run-time exception)；或者更好的方法是，延迟实际的挂起过程，直到线程释放所有的锁。

关于解决Java编程语言线程问题的建议(11)

被阻断的 I/O 应正确工作

应该能打断任何被阻断的操作，而不是只让它们 wait() 和 sleep() 。我在“ Taming Java Threads ”的第二章中的 socket 部分讨论了此问题。但是现在，对于一个被阻断的 socket 上的 I/O 操作，打断它的唯一办法是关闭这个 socket，而没有办法打断一个被阻断的文件 I/O 操作。例如，一旦开始一个读请求并且进入阻断状态后，除非到它实际读出一些东西，否则线程一直出于阻断状态。既使关掉文件

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