- 写在前面的话
- 引言
- 第 1 章 对象入门
- 第 2 章 一切都是对象
- 第 3 章 控制程序流程
- 第 4 章 初始化和清除
- 第 5 章 隐藏实施过程
- 第 6 章 类再生
- 第 7 章 多形性
- 第 8 章 对象的容纳
- 第 9 章 违例差错控制
- 第 10 章 Java IO 系统
- 第 11 章 运行期类型鉴定
- 第 12 章 传递和返回对象
- 第 十三 章 创建窗口和程序片
- 第 14 章 多线程
- 第 15 章 网络编程
- 第 16 章 设计范式
- 第 17 章 项目
- 附录 A 使用非 JAVA 代码
- 附录 B 对比 C++和 Java
- 附录 C Java 编程规则
- 附录 D 性能
- 附录 E 关于垃圾收集的一些话
- 附录 F 推荐读物
14.3.2 死锁
由于线程可能进入堵塞状态,而且由于对象可能拥有“同步”方法——除非同步锁定被解除,否则线程不能访问那个对象——所以一个线程完全可能等候另一个对象,而另一个对象又在等候下一个对象,以此类推。这个“等候”链最可怕的情形就是进入封闭状态——最后那个对象等候的是第一个对象!此时,所有线程都会陷入无休止的相互等待状态,大家都动弹不得。我们将这种情况称为“死锁”。尽管这种情况并非经常出现,但一旦碰到,程序的调试将变得异常艰难。
就语言本身来说,尚未直接提供防止死锁的帮助措施,需要我们通过谨慎的设计来避免。如果有谁需要调试一个死锁的程序,他是没有任何窍门可用的。
1. Java 1.2 对 stop(),suspend(),resume() 以及 destroy() 的反对
为减少出现死锁的可能,Java 1.2 作出的一项贡献是“反对”使用 Thread 的 stop(),suspend(),resume() 以及 destroy() 方法。
之所以反对使用 stop(),是因为它不安全。它会解除由线程获取的所有锁定,而且如果对象处于一种不连贯状态(“被破坏”),那么其他线程能在那种状态下检查和修改它们。结果便造成了一种微妙的局面,我们很难检查出真正的问题所在。所以应尽量避免使用 stop(),应该采用 Blocking.java 那样的方法,用一个标志告诉线程什么时候通过退出自己的 run() 方法来中止自己的执行。
如果一个线程被堵塞,比如在它等候输入的时候,那么一般都不能象在 Blocking.java 中那样轮询一个标志。但在这些情况下,我们仍然不该使用 stop(),而应换用由 Thread 提供的 interrupt() 方法,以便中止并退出堵塞的代码。
//: Interrupt.java // The alternative approach to using stop() // when a thread is blocked import java.awt.*; import java.awt.event.*; import java.applet.*; class Blocked extends Thread { public synchronized void run() { try { wait(); // Blocks } catch(InterruptedException e) { System.out.println("InterruptedException"); } System.out.println("Exiting run()"); } } public class Interrupt extends Applet { private Button interrupt = new Button("Interrupt"); private Blocked blocked = new Blocked(); public void init() { add(interrupt); interrupt.addActionListener( new ActionListener() { public void actionPerformed(ActionEvent e) { System.out.println("Button pressed"); if(blocked == null) return; Thread remove = blocked; blocked = null; // to release it remove.interrupt(); } }); blocked.start(); } public static void main(String[] args) { Interrupt applet = new Interrupt(); Frame aFrame = new Frame("Interrupt"); aFrame.addWindowListener( new WindowAdapter() { public void windowClosing(WindowEvent e) { System.exit(0); } }); aFrame.add(applet, BorderLayout.CENTER); aFrame.setSize(200,100); applet.init(); applet.start(); aFrame.setVisible(true); } } ///:~
Blocked.run() 内部的 wait() 会产生堵塞的线程。当我们按下按钮以后,blocked(堵塞)的句柄就会设为 null,使垃圾收集器能够将其清除,然后调用对象的 interrupt() 方法。如果是首次按下按钮,我们会看到线程正常退出。但在没有可供“杀死”的线程以后,看到的便只是按钮被按下而已。
suspend() 和 resume() 方法天生容易发生死锁。调用 suspend() 的时候,目标线程会停下来,但却仍然持有在这之前获得的锁定。此时,其他任何线程都不能访问锁定的资源,除非被“挂起”的线程恢复运行。对任何线程来说,如果它们想恢复目标线程,同时又试图使用任何一个锁定的资源,就会造成令人难堪的死锁。所以我们不应该使用 suspend() 和 resume(),而应在自己的 Thread 类中置入一个标志,指出线程应该活动还是挂起。若标志指出线程应该挂起,便用 wait() 命其进入等待状态。若标志指出线程应当恢复,则用一个 notify() 重新启动线程。我们可以修改前面的 Counter2.java 来实际体验一番。尽管两个版本的效果是差不多的,但大家会注意到代码的组织结构发生了很大的变化——为所有“听众”都使用了匿名的内部类,而且 Thread 是一个内部类。这使得程序的编写稍微方便一些,因为它取消了 Counter2.java 中一些额外的记录工作。
//: Suspend.java // The alternative approach to using suspend() // and resume(), which have been deprecated // in Java 1.2. import java.awt.*; import java.awt.event.*; import java.applet.*; public class Suspend extends Applet { private TextField t = new TextField(10); private Button suspend = new Button("Suspend"), resume = new Button("Resume"); class Suspendable extends Thread { private int count = 0; 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(100); synchronized(this) { while(suspended) wait(); } } catch (InterruptedException e){} t.setText(Integer.toString(count++)); } } } private Suspendable ss = new Suspendable(); public void init() { add(t); suspend.addActionListener( new ActionListener() { public void actionPerformed(ActionEvent e) { ss.fauxSuspend(); } }); add(suspend); resume.addActionListener( new ActionListener() { public void actionPerformed(ActionEvent e) { ss.fauxResume(); } }); add(resume); } public static void main(String[] args) { Suspend applet = new Suspend(); Frame aFrame = new Frame("Suspend"); aFrame.addWindowListener( new WindowAdapter() { public void windowClosing(WindowEvent e){ System.exit(0); } }); aFrame.add(applet, BorderLayout.CENTER); aFrame.setSize(300,100); applet.init(); applet.start(); aFrame.setVisible(true); } } ///:~
Suspendable 中的 suspended(已挂起)标志用于开关“挂起”或者“暂停”状态。为挂起一个线程,只需调用 fauxSuspend() 将标志设为 true(真)即可。对标志状态的侦测是在 run() 内进行的。就象本章早些时候提到的那样,wait() 必须设为“同步”(synchronized),使其能够使用对象锁。在 fauxResume() 中,suspended 标志被设为 false(假),并调用 notify()——由于这会在一个“同步”从句中唤醒 wait(),所以 fauxResume() 方法也必须同步,使其能在调用 notify() 之前取得对象锁(这样一来,对象锁可由要唤醍的那个 wait() 使用)。如果遵照本程序展示的样式,可以避免使用 wait() 和 notify()。
Thread 的 destroy() 方法根本没有实现;它类似一个根本不能恢复的 suspend(),所以会发生与 suspend() 一样的死锁问题。然而,这一方法没有得到明确的“反对”,也许会在 Java 以后的版本(1.2 版以后)实现,用于一些可以承受死锁危险的特殊场合。
大家可能会奇怪当初为什么要实现这些现在又被“反对”的方法。之所以会出现这种情况,大概是由于 Sun 公司主要让技术人员来决定对语言的改动,而不是那些市场销售人员。通常,技术人员比搞销售的更能理解语言的实质。当初犯下了错误以后,也能较为理智地正视它们。这意味着 Java 能够继续进步,即便这使 Java 程序员多少感到有些不便。就我自己来说,宁愿面对这些不便之处,也不愿看到语言停滞不前。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论