Java开发中的线程安全选择与Swing(1)

Swing API的设计目标是强大、灵活和易用。特别地，我们希望能让程序员们方便地建立新的Swing组件，不论是从头开始还是通过扩展我们所提供的一些组件。

出于这个目的，我们不要求Swing组件支持多线程访问。相反，我们向组件发送请求并在单一线程中执行请求。

本文讨论线程和Swing组件。目的不仅是为了帮助你以线程安全的方式使用Swing API，而且解释了我们为什么会选择现在这样的线程方案。

本文包括以下内容：



◆单线程规则：Swing线程在同一时刻仅能被一个线程所访问。一般来说，这个线程是事件派发线程（event-dispatching thread）。

◆规则的例外：有些操作保证是线程安全的。

◆事件分发：如果你需要从事件处理（event-handling）或绘制代码以外的地方访问UI，那么你可以使用SwingUtilities类的invokeLater()或invokeAndWait()方法。

◆创建线程：如果你需要创建一个线程——比如用来处理一些耗费大量计算能力或受I/O能力限制的工作——你可以使用一个线程工具类如SwingWorker或Timer。

为什么我们这样实现Swing：我们将用一些关于Swing的线程安全的背景资料来结束这篇文章。

Swing的规则是：

一旦Swing组件被具现化（realized），所有可能影响或依赖于组件状态的代码都应该在事件派发线程中执行。

这个规则可能听起来有点吓人，但对许多简单的程序来说，你用不着为线程问题操心。在我们深入如何撰写Swing代码之前，让我们先来定义两个术语：具现化（realized）和事件派发线程（event-dispatching thread）。

具现化的意思是组建的paint()方法已经或可能会被调用。一个作为顶级窗口的Swing组件当调用以下方法时将被具现化：setVisible(true)、show()或（可能令你惊奇）pack()。当一个窗口被具现化，它包含的所有组件都被具现化。另一个具现化一个组件的方法是将它放入到一个已经具现化的容器中。稍后你会看到一些对组件具现化的例子。

事件派发线程是执行绘制和事件处理的线程。例如，paint()和actionPerformed()方法会自动在事件派发线程中执行。另一个将代码放到事件派发线程中执行的方法是使用SwingUtilities类的invokeLater()方法。

所有可能影响一个已具现化的Swing组件的代码都必须在事件派发线程中执行。但这个规则有一些例外：

有些方法是线程安全的：在Swing API的文档中，线程安全的方法用以下文字标记：

This method is thread safe, although most Swing methods are not.

（这个方法是线程安全的，尽管大多数Swing方法都不是。）

一个应用程序的GUI常常可以在主线程中构建和显示：下面的典型代码是安全的，只要没有（Swing或其他）组件被具现化：

public class MyApplication 

{

　public static void main(String[] args)

　{

JFrame f = new JFrame("Labels"); // 在这里将各组件 

// 加入到主框架…… 

f.pack(); 

f.show(); 

// 不要再做任何GUI工作……

　 }

}

上面所示的代码全部在“main”线程中运行。对f.pack()的调用使得JFrame以下的组件都被具现化。这意味着，f.show()调用是不安全的且应该在事件派发线程中执行。尽管如此，只要程序还没有一个看得到的GUI，JFrame或它的里面的组件就几乎不可能在f.show()返回前收到一个paint()调用。因为在f.show()调用之后不再有任何GUI代码，于是所有GUI工作都从主线程转到了事件派发线程，因此前面所讨论的代码实际上是线程安全的。

一个applet的GUI可以在init()方法中构造和显示：现有的浏览器都不会在一个applet的init()和start()方法被调用前绘制它。因而，在一个applet的init()方法中构造GUI是安全的，只要你不对applet中的对象调用show()或setVisible(true)方法。

要顺便一提的是，如果applet中使用了Swing组件，就必须实现为JApplet的子类。并且，组件应该添加到的JApplet内容窗格（content pane）中，而不要直接添加到JApplet。对任何applet，你都不应该在init()或start()方法中执行费时的初始化操作；而应该启动一个线程来执行费时的任务。

下述JComponent方法是安全的，可以从任何线程调用：repaint()、revalidate()、和invalidate()。repaint()和revalidate()方法为事件派发线程对请求排队，并分别调用paint()和validate()方法。invalidate()方法只在需要确认时标记一个组件和它的所有直接祖先。

监听者列表可以由任何线程修改：调用addListenerTypeListener()和removeListenerTypeListener()方法总是安全的。对监听者列表的添加/删除操作不会对进行中的事件派发有任何影响。

注意：revalidate()和旧的validate()方法之间的重要区别是，revalidate()会缓存请求并组合成一次validate()调用。这和repaint()缓存并组合绘制请求类似。

大多数初始化后的GUI工作自然地发生在事件派发线程。一旦GUI成为可见，大多数程序都是由事件驱动的，如按钮动作或鼠标点击，这些总是在事件派发线程中处理的。

不过，总有些程序需要在GUI成为可见后执行一些非事件驱动的GUI工作。比如：

在成为可用前需要进行长时间初始化操作的程序：这类程序通常应该在初始化期间就显示出GUI，然后更新或改变GUI。初始化过程不应该在事件派发线程中进行；否则，重绘组件和事件派发会停止。尽管如此，在初始化之后，GUI的更新/改变还是应该在事件派发线程中进行，理由是线程安全。

必须响应非AWT事件来更新GUI的程序：例如，想象一个服务器程序从可能运行在其他机器上的程序得到请求。这些请求可能在任何时刻到达，并且会引起在一些可能未知的线程中对服务器的方法调用。这个方法调用怎样更新GUI呢？在事件派发线程中执行GUI更新代码。

SwingUtilities类提供了两个方法来帮助你在事件派发线程中执行代码：

◆invokeLater()：要求在事件派发线程中执行某些代码。这个方法会立即返回，不会等待代码执行完毕。

◆invokeAndWait()：行为与invokeLater()类似，除了这个方法会等待代码执行完毕。一般地，你可以用invokeLater()来代替这个方法。

下面是一些使用这几个API的例子。请同时参阅《The Java Tutorial》中的“BINGO example”，尤其是以下几个类：CardWindow、ControlPane、Player和OverallStatusPane。