RE><CCID_CODE>This method is thread safe, RE><CCID_CODE>public class MyApplication ><BR><BR>上面所示的代码全部在“main”线程中运行。对f.pack()的调用使得JFrame以下的组件都被具现化。这意味着，f.show()调用是不安全的且应该在事件派发线程中执行。尽管如此，只要程序还没有一个看得到的GUI，JFrame或它的里面的组件就几乎不可能在f.show()返回前收到一个paint()调用。因为在f.show()调用之后不再有任何GUI代码，于是所有GUI工作都从主线程转到了事件派发线程，因此前面所讨论的代码实际上是线程安全的。</P>>一个applet的GUI可以在init()方法中构造和显示：现有的浏览器都不会在一个applet的init()和start()方法被调用前绘制它。因而，在一个applet的init()方法中构造GUI是安全的，只要你不对applet中的对象调用show()或setVisible(true)方法。<BR><BR>要顺便一提的是，如果applet中使用了Swing组件，就必须实现为JApplet的子类。并且，组件应该添加到的JApplet内容窗格（content pane）中，而不要直接添加到JApplet。对任何applet，你都不应该在init()或start()方法中执行费时的初始化操作；而应该启动一个线程来执行费时的任务。<BR><BR>下述JComponent方法是安全的，可以从任何线程调用：repaint()、revalidate()、和invalidate()。repaint()和revalidate()方法为事件派发线程对请求排队，并分别调用paint()和validate()方法。invalidate()方法只在需要确认时标记一个组件和它的所有直接祖先。<BR><BR>监听者列表可以由任何线程修改：调用addListenerTypeListener()和removeListenerTypeListener()方法总是安全的。对监听者列表的添加/删除操作不会对进行中的事件派发有任何影响。<BR><BR>注意：revalidate()和旧的validate()方法之间的重要区别是，revalidate()会缓存请求并组合成一次validate()调用。这和repaint()缓存并组合绘制请求类似。<BR><BR>大多数初始化后的GUI工作自然地发生在事件派发线程。一旦GUI成为可见，大多数程序都是由事件驱动的，如按钮动作或鼠标点击，这些总是在事件派发线程中处理的。不过，总有些程序需要在GUI成为可见后执行一些非事件驱动的GUI工作。比如：<BR><BR>在成为可用前需要进行长时间初始化操作的程序：这类程序通常应该在初始化期间就显示出GUI，然后更新或改变GUI。初始化过程不应该在事件派发线程中进行；否则，重绘组件和事件派发会停止。尽管如此，在初始化之后，GUI的更新/改变还是应该在事件派发线程中进行，理由是线程安全。<BR><BR>必须响应非AWT事件来更新GUI的程序：例如，想象一个服务器程序从可能运行在其他机器上的程序得到请求。这些请求可能在任何时刻到达，并且会引起在一些可能未知的线程中对服务器的方法调用。这个方法调用怎样更新GUI呢？在事件派发线程中执行GUI更新代码。<BR><BR>SwingUtilities类提供了两个方法来帮助你在事件派发线程中执行代码：<BR><BR>invokeLater()：要求在事件派发线程中执行某些代码。这个方法会立即返回，不会等待代码执行完毕。<BR><BR>invokeAndWait()：行为与invokeLater()类似，除了这个方法会等待代码执行完毕。一般地，你可以用invokeLater()来代替这个方法。<BR><BR>下面是一些使用这几个API的例子。请同时参阅《The Java Tutorial》中的“BINGO example”，尤其是以下几个类：CardWindow、ControlPane、Player和OverallStatusPane。<BR><BR>使用invokeLater()方法<BR><BR>你可以从任何线程调用invokeLater()方法以请求事件派发线程运行特定代码。你必须把要运行的代码放到一个Runnable对象的run()方法中，并将此Runnable对象设为invokeLater()的参数。invokeLater()方法会立即返回，不等待事件派发线程执行指定代码。这是一个使用invokeLater()方法的例子：<BR><BR></P>RE><CCID_CODE>Runnable doWorkRunnable = new Runnable()% D* d- V9 l/ }/ ]; }" m7 G! }0 p><BR><BR>使用invokeAndWait()方法 <BR><BR>invokeAndWait()方法和invokeLater()方法很相似，除了invokeAndWait()方法会等事件派发线程执行了指定代码才返回。在可能的情况下，你应该尽量用invokeLater()来代替invokeAndWait()。 <BR><BR>如果你真的要使用invokeAndWait()，请确保调用invokeAndWait()的线程不会在调用期间持有任何其他线程可能需要的锁。这是一个使用invokeAndWait()的例子： <BR><BR></P># r' h3 }* f2 Q; U8 |" M0 lRE><CCID_CODE>void showHelloThereDialog() throws Exception ><BR><BR>类似地，假设一个线程需要对GUI的状态进行存取，比如文本域的内容，它的代码可能类似这样： <BR><BR></P>, M9 x" P1 G( v, b+ ^0 fRE><CCID_CODE>void printTextField()><BR><BR>如果你能避免使用线程，最好这样做。线程可能难于使用，并使得程序的debug更困难。一般来说，对于严格意义下的GUI工作，线程是不必要的，比如对组件属性的更新。不管怎么说，有时候线程是必要的。下列情况是使用线程的一些典型情况： <BR><BR>执行一项费时的任务而不必将事件派发线程锁定。例子包括执行大量计算的情况，会导致大量类被装载的情况（如初始化），和为网络或磁盘I/O而阻塞的情况。重复地执行一项操作，通常在两次操作间间隔一个预定的时间周期。要等待来自客户的消息。<BR><BR>你可以使用两个类来帮助你实现线程：<BR><BR>SwingWorker：创建一个后台线程来执行费时的操作。<BR><BR>Timer：创建一个线程来执行或多次执行某些代码，在两次执行间间隔用户定义的延迟。<BR><BR>使用SwingWorker类<BR><BR>SwingWorker类在SwingWorker.java中实现，这个类并不包含在Java的任何发行版中，所以你必须单独下载它。<BR><BR>SwingWorker类做了所有实现一个后台线程所需的肮脏工作。虽然许多程序都不需要后台线程，后台线程在执行费时的操作时仍然是很有用的，它能提高程序的性能观感。<BR><BR></P>RE><CCID_CODE>SwingWorker's get() method. 8 i% U" _, _- v><BR><BR>要使用SwingWorker类，你首先要实现它的一个子类。在子类中，你必须实现construct()方法还包含你的长时间操作。当你实例化SwingWorker的子类时，SwingWorker创建一个线程但并不启动它。 <BR><BR>你要调用你的SwingWorker对象的start()方法来启动线程，然后start()方法会调用你的construct()方法。当你需要construct()方法返回的对象时，可以调用SwingWorker类的get()方法。这是一个使用SwingWorker类的例子： <BR><BR></P>RE><CCID_CODE>...// 在main方法中： 0 a4 @- D; P% e4 a/ }9 u: o( y><BR><BR>当程序的main()方法调用start()方法，SwingWorker启动一个新的线程来实例化ExpensiveDialogComponent。main()方法还构造了由一个窗口和一个按钮组成的GUI。 <BR><BR>当用户点击按钮，程序将阻塞，如果必要，阻塞到ExpensiveDialogComponent创建完成。然后程序显示一个包含ExpensiveDialogComponent的模式对话框。你可以在MyApplication.java找到整个程序。 <BR><BR>使用Timer类 <BR><BR>Timer类通过一个ActionListener来执行或多次执行一项操作。你创建定时器的时候可以指定操作执行的频率，并且你可以指定定时器的动作事件的监听者（action listener）。启动定时器后，动作监听者的actionPerformed()方法会被（多次）调用来执行操作。 <BR><BR>定时器动作监听者（action listener）定义的actionPerformed()方法将在事件派发线程中调用。这意味着你不必在其中使用invokeLater()方法。 <BR><BR>这是一个使用Timer类来实现动画循环的例子： <BR><BR></P>RE><CCID_CODE>public class AnimatorApplicationTimer ><BR><BR>在一个线程中执行所有的用户界面代码有这样一些优点： <BR><BR>组件开发者不必对线程编程有深入的理解：像ViewPoint和Trestle这类工具包中的所有组件都必须完全支持多线程访问，使得扩展非常困难，尤其对不精通线程编程的开发者来说。最近的一些工具包如SubArctic和IFC，都采用和Swing类似的设计。 <BR><BR>事件以可预知的次序派发：invokeLater()排队的runnable对象从鼠标和键盘事件、定时器事件、绘制请求的同一个队列派发。在一些组件完全支持多线程访问的工具包中，组件的改变被变化无常的线程调度程序穿插到事件处理过程中。这使得全面测试变得困难甚至不可能。 <BR><BR>更低的代价：尝试小心锁住临界区的工具包要花费实足的时间和空间在锁的管理上。每当工具包中调用某个可能在客户代码中实现的方法时（如public类中的任何public和protected方法），工具包都要保存它的状态并释放所有锁，以便客户代码能在必要时获得锁。当控制权交回到工具包，工具包又必须重新抓住它的锁并恢复状态。所有应用程序都不得不负担这一代价，即使大多数应用程序并不需要对GUI的并发访问。 <BR><BR>这是的SubArctic Java Toolkit的作者对在工具包中支持多线程访问的问题的描述： <BR><BR>我们的基本信条是，当设计和建造多线程应用程序，尤其是那些包括GUI组件的应用程序时，必须保证极端小心。线程的使用可能会很有欺骗性。在许多情况下，它们表现得能够极好的简化编成，使得设计“专注于单一任务的简单自治实体”成为可能。在一些情况下它们的确简化了设计和编码。 <BR><BR>然而，在几乎所有的情况下，它们都使得调试、测试和维护的困难大大增加甚至成为不可能。无论大多数程序员所受的训练、他们的经验和实践，还是我们用来帮助自己的工具，都不是能够用来对付非决定论的。 <BR><BR>例如，全面测试（这总是困难的）在bug依赖于时间时是几乎不可能的。尤其对于Java来说，一个程序要运行在许多不同类型的机器的操作系统平台上，并且每个程序都必须在抢先和非抢先式调度下都能正常工作。 <BR><BR>由于这些固有的困难，我们力劝你三思是否绝对有使用线程的必要。尽管如此，有些情况下使用线程是必要的（或者是被其他软件包强加的），所以subArctic提供了一个线程安全的访问机制。本章讨论了这一机制和怎样在一个独立线程中安全地操作交互树。 <BR><BR>他们所说的线程安全机制非常类似于SwingUtilities类提供的invokeLater()和invokeAndWait()方法。</P></DIV></TD></TR></TABLE></TD></TR></TABLE>| 欢迎光临 数学建模社区-数学中国 (http://www.madio.net/) | Powered by Discuz! X2.5 |