|
由于线程可能进入堵塞状态而且由于对象可能拥有同步方法——除非同步锁定被解除否则线程不能访问那个对象——所以一个线程完全可能等候另一个对象而另一个对象又在等候下一个对象以此类推这个等候链最可怕的情形就是进入封闭状态——最后那个对象等候的是第一个对象！此时所有线程都会陷入无休止的相互等待状态大家都动弹不得我们将这种情况称为死锁尽管这种情况并非经常出现但一旦碰到程序的调试将变得异常艰难 就语言本身来说尚未直接提供防止死锁的帮助措施需要我们通过谨慎的设计来避免如果有谁需要调试一个死锁的程序他是没有任何窍门可用的 Java 对stop()suspend()resume()以及destroy()的反对 为减少出现死锁的可能Java 作出的一项贡献是反对使用Thread的stop()suspend()resume()以及destroy()方法 之所以反对使用stop()是因为它不安全它会解除由线程获取的所有锁定而且如果对象处于一种不连贯状态（被破坏）那么其他线程能在那种状态下检查和修改它们结果便造成了一种微妙的局面我们很难检查出真正的问题所在所以应尽量避免使用stop()应该采用Blockingjava那样的方法用一个标志告诉线程什么时候通过退出自己的run()方法来中止自己的执行 如果一个线程被堵塞比如在它等候输入的时候那么一般都不能象在Blockingjava中那样轮询一个标志但在这些情况下我们仍然不该使用stop()而应换用由Thread提供的interrupt()方法以便中止并退出堵塞的代码 //: Interruptjava // The alternative approach to using stop() // when a thread is blocked import javaawt*; import javaawtevent*; import javaapplet*; class Blocked extends Thread { public synchronized void run() { try { wait(); // Blocks } catch(InterruptedException e) { Systemoutprintln(InterruptedException); } Systemoutprintln(Exiting run()); } } public class Interrupt extends Applet { private Button interrupt = new Button(Interrupt); private Blocked blocked = new Blocked(); public void init() { add(interrupt); interruptaddActionListener( new ActionListener() { public void actionPerformed(ActionEvent e) { Systemoutprintln(Button pressed); if(blocked == null) return; Thread remove = blocked; blocked = null; // to release it removeinterrupt(); } }); blockedstart(); } public static void main(String[] args) { Interrupt applet = new Interrupt(); Frame aFrame = new Frame(Interrupt); aFrameaddWindowListener( new WindowAdapter() { public void windowClosing(WindowEvent e) { Systemexit(); } }); aFrameadd(applet BorderLayoutCENTER); aFramesetSize(); appletinit(); appletstart(); aFramesetVisible(true); } } ///:~ Blockedrun()内部的wait()会产生堵塞的线程当我们按下按钮以后blocked（堵塞）的句柄就会设为null使垃圾收集器能够将其清除然后调用对象的interrupt()方法如果是首次按下按钮我们会看到线程正常退出但在没有可供杀死的线程以后看到的便只是按钮被按下而已 suspend()和resume()方法天生容易发生死锁调用suspend()的时候目标线程会停下来但却仍然持有在这之前获得的锁定此时其他任何线程都不能访问锁定的资源除非被挂起的线程恢复运行对任何线程来说如果它们想恢复目标线程同时又试图使用任何一个锁定的资源就会造成令人难堪的死锁所以我们不应该使用suspend()和resume()而应在自己的Thread类中置入一个标志指出线程应该活动还是挂起若标志指出线程应该挂起便用wait()命其进入等待状态若标志指出线程应当恢复则用一个notify()重新启动线程我们可以修改前面的Counterjava来实际体验一番尽管两个版本的效果是差不多的但大家会注意到代码的组织结构发生了很大的变化——为所有听众都使用了匿名的内部类而且Thread是一个内部类这使得程序的编写稍微方便一些因为它取消了Counterjava中一些额外的记录工作 //: Suspendjava // The alternative approach to using suspend() // and resume() which have been deprecated // in Java import javaawt*; import javaawtevent*; import javaapplet*; public class Suspend extends Applet { private TextField t = new TextField(); private Button suspend = new Button(Suspend) resume = new Button(Resume); class Suspendable extends Thread { private int count = ; private boolean suspended = false; public Suspendable() { start(); } public void fauxSuspend() { suspended = true; } public synchronized void fauxResume() { suspended = false; notify(); } public void run() { while (true) { try { sleep(); synchronized(this) { while(suspended) wait(); } } catch (InterruptedException e){} tsetText(IntegertoString(count++)); } } } private Suspendable ss = new Suspendable(); public void init() { add(t); suspendaddActionListener( new ActionListener() { public void actionPerformed(ActionEvent e) { ssfauxSuspend(); } }); add(suspend); resumeaddActionListener( new ActionListener() { public void actionPerformed(ActionEvent e) { ssfauxResume(); } }); add(resume); } public static void main(String[] args) { Suspend applet = new Suspend(); Frame aFrame = new Frame(Suspend); aFrameaddWindowListener( new WindowAdapter() { public void windowClosing(WindowEvent e){ Systemexit(); } }); aFrameadd(applet BorderLayoutCENTER); aFramesetSize(); appletinit(); appletstart(); aFramesetVisible(true); } } Suspendable中的suspended（已挂起）标志用于开关挂起或者暂停状态为挂起一个线程只需调用fauxSuspend()将标志设为true（真）即可对标志状态的侦测是在run()内进行的就象本章早些时候提到的那样wait()必须设为同步（synchronized）使其能够使用对象锁在fauxResume()中suspended标志被设为false（假）并调用notify()——由于这会在一个同步从句中唤醒wait()所以fauxResume()方法也必须同步使其能在调用notify()之前取得对象锁（这样一来对象锁可由要唤醍的那个wait()使用）如果遵照本程序展示的样式可以避免使用wait()和notify() Thread的destroy()方法根本没有实现它类似一个根本不能恢复的suspend()所以会发生与suspend()一样的死锁问题然而这一方法没有得到明确的反对也许会在Java以后的版本（版以后）实现用于一些可以承受死锁危险的特殊场合 大家可能会奇怪当初为什么要实现这些现在又被反对的方法之所以会出现这种情况大概是由于Sun公司主要让技术人员来决定对语言的改动而不是那些市场销售人员通常技术人员比搞销售的更能理解语言的实质当初犯下了错误以后也能较为理智地正视它们这意味着Java能够继续进步即便这使Java程序员多少感到有些不便就我自己来说宁愿面对这些不便之处也不愿看到语言停滞不前 |
