不正確的Swing線程是運行緩慢、無響應和不穩定的Swing應用的主要原因之一。這是許多原因造成的，從開發人員對Swing單線程模型的誤解，到保證正確的線程執行的困難。即使對Swing線程進行了很多努力，應用線程邏輯也是很難理解和維護的。本文闡述了如何在開發Swing應用中使用事件驅動編程，以大大簡化開發、維護，并提供高靈活性。 

　　背景

　　既然我們是要簡化Swing應用的線程，首先讓我們來看看Swing線程是怎么工作的，為什么它是必須的。Swing API是圍繞單線程模型設計的。這意味著Swing組件必須總是通過同一個線程來修改和操縱。為什么采用單線程模型，這有很多原因，包括開發成本和同步Swing的復雜性－－這都會造成一個遲鈍的API。為了達到單線程模型，有一個專門的線程用于和Swing組件交互。這個線程就是大家熟知的Swing線程，AWT（有時也發音為“ought”）線程，或者事件分派線程。在本文的下面的部分，我選用Swing線程的叫法。
既然Swing線程是和Swing組件進行交互的唯一的線程，它就被賦予了很多責任。所有的繪制和圖形，鼠標事件，組件事件，按鈕事件，和所有其它事件都發生在Swing線程。因為Swing線程的工作已經非常沉重了，當太多其它工作在Swing線程中進行處理時就會發生問題。會引起這個問題的最常見的位置是在非Swing處理的地方，像發生在一個事件監聽器方法中，比如JButton的ActionListener，的數據庫查找。既然ActionListener的actionPerformed()方法自動在Swing線程中執行，那么，數據庫查找也將在Swing線程中執行。這將占用了Swing的工作，阻止它處理它的其它任務－－像繪制，響應鼠標移動，處理按鈕事件，和應用的縮放。用戶以為應用死掉了，但實際上并不是這樣。在適當的線程中執行代碼對確保系統正常地執行非常重要。 

　　既然我們已經看到了在適當的線程中執行Swing應用的代碼是多么重要，現在讓我們如何實現這些線程。我們看看將代碼放入和移出Swing線程的標準機制。在講述過程中，我將突出幾個和標準機制有關的問題和難點。正如我們看到的，大部分的問題都來自于企圖在異步的Swing線程模型上實現同步的代碼模型。從那兒，我們將看到如何修改我們的例子到事件驅動－－移植整個方式到異步模型。

問題

　　我們在企圖強制通過異步模型進行同步執行－－企圖將一個方形的螺栓放到一個圓形的空中。只有我們嘗試這樣做，我們就會不斷地遭遇這些問題。從我的經驗，可以告訴你這些代碼很難閱讀，很難維護，并且易于出錯。

　　這看起來是一個常見的問題，所以一定有標準的方式來解決，對嗎？出現了一些框架用于管理Swing的復雜性，所以讓我們來快速預覽一下它們可以做什么。

　　一個可以得到的解決方案是Foxtrot，一個由Biorn Steedom寫的框架，可以在SourceForge上獲取。它使用一個叫做Worker的對象來控制非Swing任務在非Swing線程中的執行，阻塞直到非Swing任務執行完畢。它簡化了Swing線程，允許你編寫同步代碼，并在Swing線程和非Swing線程直接切換。下面是來自它的站點的一個例子：

public void actionPerformed(ActionEvent e)
{
　button.setText("Sleeping..."); 
　String text = null; 
　try 
　{
　　text = (String)Worker.post(new Task() {
　　　public Object run() throws Exception { 
　　　　Thread.sleep(10000); return "Slept !";
　　　　} 
　　　}
　　);
　}
　catch (Exception x) ... button.setText(text); somethingElse();} 

　　注意它是如何解決上面的那些問題的。我們能夠非常容易地在Swing線程中傳入傳出變量。并且，代碼塊看起來也很正確－－先編寫的先執行。但是仍然有一些問題障礙阻止使用從準同步異步解決方案。Foxtrot中的一個問題是異常管理。使用Foxtrot，每次調用Worker必須捕獲Exception。這是將執行代理給Worker來解決同步對異步問題的一個產物。

　　同樣以非常相似的方式，我此前也創建了一個框架，我稱它為鏈接運行引擎（Chained Runnable Engine） ，同樣也遭受來自類似同步對異步問題的困擾。使用這個框架，你將創建一個將被引擎執行的Runnable的集合。每一個Runnable都有一個指示器告訴引擎是否應該在Swing線程或者另外的線程中執行。引擎也保證Runnable以正確的順序執行。所以Runnable #2將不會放入隊列直到Runnable #1執行完畢。并且，它支持變量以HashMap的形式從Runnable到Runnable傳遞。

　　表面上，它看起來解決了我們的主要問題。但是當你深入進去后，同樣的問題又冒出來了。本質上，我們并沒有改變上面描述的任何東西－－我們只是將復雜性隱藏在引擎的后面。因為指數級增長的Runnable而使代碼編寫將變得非?？菰?，也很復雜，并且這些Runnable常常相互耦合。Runnable之間的非類型的HashMap變量傳遞變得難于管理。問題的列表還有很多。

　　在編寫這個框架之后，我意識到這需要一個完全不同的解決方案。這讓我重新審視了問題，看別人是怎么解決類似的問題的，并深入的研究了Swing的源代碼。

解決方案：事件驅動編程

　　所有前面的這些解決方案都存在一個共同的致命缺陷－－企圖在持續地改變線程的同時表示一個任務的功能集。但是改變線程需要異步的模型，而線程異步地處理Runnable。問題的部分原因是我們在企圖在一個異步的線程模型之上實現一個同步的模型。這是所有Runnable之間的鏈和依賴，執行順序和內部類scooping問題的根源。如果我們可以構建真正的異步，我們就可以解決我們的問題并極大地簡化Swing線程。
在這之前，讓我們先列舉一下我們要解決的問題：

　　1. 在適當的線程中執行代碼 

　　2. 使用SwingUtilities.invokeLater()異步地執行. 

　　異步地執行導致了下面的問題：

　　1. 互相耦合的組件 

　　2. 變量傳遞的困難 

　　3. 執行的順序 

　　讓我們考慮一下像Java消息服務（JMS）這樣的基于消息的系統，因為它們提供了在異步環境中功能組件之間的松散耦合。消息系統觸發異步事件，正如在Enterprise Integration Patterns 中描述的。感興趣的參與者監聽該事件，并對事件做成響應－－通常通過執行它們自己的一些代碼。結果是一組模塊化的，松散耦合的組件，組件可以添加到或者從系統中去除而不影響到其它組件。更重要的，組件之間的依賴被最小化了，而每一個組件都是良好定義的和封裝的－－每一個都僅對自己的工作負責。它們簡單地觸發消息，其它一些組件將響應這個消息，并對其它組件觸發的消息進行響應。

　　現在，我們先忽略線程問題，將組件解耦并移植到異步環境中。在我們解決了異步問題后，我們將回過頭來看看線程問題。正如我們所將要看到的，那時解決這個問題將非常容易。

　　讓我們還拿前面引入的例子，并把它移植到基于事件的模型。首先，我們把lookup調用抽象到一個叫LookupManager的類中。這將允許我們將所有UI類中的數據庫邏輯移出，并最終允許我們完全將這兩者脫耦。下面是LookupManager類的代碼：

class LookupManager { 
　private String[] lookup(String text) {
　　String[] results = ... // database lookup code return results 
　}
} 

　　現在我們開始向異步模型轉換。為了使這個調用異步化，我們需要抽象調用的返回。換句話，方法不能返回任何值。我們將以分辨什么相關的動作是其它類所希望知道的開始。在我們這個例子中最明顯的事件是搜索結束事件。所以讓我們創建一個監聽器接口來響應這些事件。該接口含有單個方法lookupCompleted()。下面是接口的定義：

interface LookupListener { public void lookupCompleted(Iterator results);} 

　　遵守Java的標準，我們創建另外一個稱作LookupEvent的類包含結果字串數組，而不是到處直接傳遞字串數組。這將允許我們在不改變LookupListener接口的情況下傳遞其它信息。例如，我們可以在LookupEvent中同時包括查找的字串和結果。下面是LookupEvent類：

public class LookupEvent {
　String searchText; 
　String[] results;
　public LookupEvent(String searchText) { 
　　this.searchText = searchText;
　}
　public LookupEvent(String searchText, String[] results) { 
　　this.searchText = searchText;
　　this.results = results; 
　}
　public String getSearchText() {
　　return searchText; 
　}
　public String[] getResults() {
　　return results; 
　}
} 

　　注意LookupEvent類是不可變的。這是很重要的，因為我們并不知道在傳遞過程中誰將處理這些事件。除非我們創建事件的保護拷貝來傳遞給每一個監聽者，我們需要把事件做成不可變的。如果不這樣，一個監聽者可能會無意或者惡意地修訂事件對象，并破壞系統。

　　現在我們需要在LookupManager上調用lookupComplete()事件。我們首先要在LookupManager上添加一個LookupListener的集合：

List listeners = new ArrayList(); 

　　并提供在LookupManager上添加和去除LookupListener的方法：

public void addLookupListener(LookupListener listener){ 
　listeners.add(listener);
}
public void removeLookupListener(LookupListener listener){
　listeners.remove(listener);
} 

　　當動作發生時，我們需要調用監聽者的代碼。在我們的例子中，我們將在查找返回時觸發一個lookupCompleted()事件。這意味著在監聽者集合上迭代，并使用一個LookupEvent事件對象調用它們的lookupCompleted()方法。

我喜歡把這些代碼析取到一個獨立的方法fire[event-method-name] ，其中構造一個事件對象，在監聽器集合上迭代，并調用每一個監聽器上的適當的方法。這有助于隔離主要邏輯代碼和調用監聽器的代碼。下面是我們的fireLookupCompleted方法：

private void fireLookupCompleted(String searchText, String[] results){
　LookupEvent event = new LookupEvent(searchText, results); 
　Iterator iter = new ArrayList(listeners).iterator();
　while (iter.hasNext()) {
　　LookupListener listener = (LookupListener) iter.next();
　　listener.lookupCompleted(event); 
　}
} 

　　第2行代碼創建了一個新的集合，傳入原監聽器集合。這在監聽器響應事件后決定在LookupManager中去除自己時將發揮作用。如果我們不是安全地拷貝集合，在一些監聽器應該 被調用而沒有被調用時發生令人厭煩的錯誤。

　　下面，我們將在動作完成時調用fireLookupCompleted輔助方法。這是lookup方法的返回查詢結果的結束處。所以我們可以改變lookup方法使其觸發一個事件而不是返回字串數組本身。下面是新的lookup方法：

public void lookup(String text) { 
　//mimic the server call delay... 
　try { 
　　Thread.sleep(5000);
　} catch (Exception e){ 
　　e.printStackTrace(); 
　}
　//imagine we got this from a server 
　String[] results = new String[]{"Book one", "Book two", "Book three"}; 
　fireLookupCompleted(text, results);
} 

　　現在讓我們把監聽器添加到LookupManager。我們希望當查找返回時更新文本區域。以前，我們只是直接調用setText()方法。因為文本區域是和數據庫調用一起都在UI中執行的。既然我們已經將查找邏輯從UI中抽象出來了，我們將把UI類作為一個到LookupManager的監聽器，監聽lookup事件并相應地更新自己。首先我們將在類定義中實現監聽器接口：

public class FixedFrame implements LookupListener 

　　接著我們實現接口方法：

public void lookupCompleted(final LookupEvent e) {
　outputTA.setText("");
　String[] results = e.getResults(); 
　for (int i = 0; i < results.length; i++) {
　　String result = results[i]; 
　　outputTA.setText(outputTA.getText() + "\n" + result); 
　 }
} 

　　最后，我們將它注冊為LookupManager的一個監聽器：

public FixedFrame() { 
　lookupManager = new LookupManager(); 
　//here we register the listener 
　lookupManager.addListener(this);
　initComponents(); 
　layoutComponents();} 

　　為了簡化，我在類的構造器中將它添加為監聽器。這在大多數系統上都允許良好。當系統變得更加復雜時，你可能會重構、從構造器中提煉出監聽器注冊代碼，以允許更大的靈活性和擴展性。

　　到現在為止，你看到了所有組件之間的連接，注意職責的分離。用戶界面類負責信息的顯示－－并且僅負責信息的顯示。另一方面，LookupManager類負責所有的lookup連接和邏輯。并且，LookupManager負責在它變化時通知監聽器－－而不是當變化發生時應該具體做什么。這允許你連接任意多的監聽器。

　　為了演示如何添加新的事件，讓我們回頭添加一個lookup開始的事件。我們可以添加一個稱作lookupStarted()的事件到LookupListener，我們將在查找開始執行前觸發它。我們也創建一個fireLookupStarted()事件調用所有LookupListener的lookupStarted()?，F在lookup方法如下：

public void lookup(String text) { 
　　fireLookupStarted(text); 
　　//mimic the server call delay... 
　　try { 
　　　Thread.sleep(5000);
　　} catch (Exception e){ 
　　　 e.printStackTrace(); 
　　}
　　//imagine we got this from a server 
　　String[] results = new String[]{"Book one", "Book two", "Book three"}; 
　　fireLookupCompleted(text, results);} 

　　我們也添加新的觸發方法fireLookupStarted()。這個方法等同于fireLookupCompleted()方法，除了我們調用監聽器上的lookupStarted()方法，并且該事件也不包含結果集。下面是代碼：

private void fireLookupStarted(String searchText){
　LookupEvent event = new LookupEvent(searchText); 
　Iterator iter = new ArrayList(listeners).iterator();
　while (iter.hasNext()) { 
　　LookupListener listener = (LookupListener) iter.next();
　　listener.lookupStarted(event);
　}
} 

　　最后，我們在UI類上實現lookupStarted()方法，設置文本區域提示當前搜索的字符串。

public void lookupStarted(final LookupEvent e) {
　outputTA.setText("Searching for: " + e.getSearchText());
} 

　　這個例子展示了添加新的事件是多么容易。現在，讓我們看看展示事件驅動脫耦的靈活性。我們將通過創建一個日志類，當一個搜索開始和結束時在命令行中輸出信息來演示。我們稱這個類為Logger。下面是它的代碼：

public class Logger implements LookupListener { 
　public void lookupStarted(LookupEvent e) { 
　　System.out.println("Lookup started: " + e.getSearchText());
　}
　public void lookupCompleted(LookupEvent e) {
　　System.out.println("Lookup completed: " + e.getSearchText() + " " + e.getResults()); 
　}
} 

　　現在，我們添加Logger作為在FixedFrame構造方法中的LookupManager的一個監聽器。

public FixedFrame() {
　lookupManager = new LookupManager();
　lookupManager.addListener(this); 
　lookupManager.addListener(new Logger());
　initComponents();
　layoutComponents();
}  

　　現在你已經看到了添加新的事件、創建新的監聽器－－向您展示了事件驅動方案的靈活性和擴展性。你會發現隨著你更多地開發事件集中的程序，你會更加嫻熟地在你的應用中創建通用動作。像其它所有事情一樣，這只需要時間和經驗?？雌饋碓谑录Ｐ蜕弦呀涀隽撕芏嘌芯?，但是你還是需要把它和其它替代方案相比較。考慮開發時間成本；最重要的，這是一次性成本。一旦你創建好了監聽器模型和它們的動作，以后向你的應用中添加監聽器將是小菜一蝶。

線程

　　到現在，我們已經解決了上面的異步問題；通過監聽器使組件脫耦，通過事件對象傳遞變量，通過事件產生和監聽器的注冊的組合決定執行的順序。讓我們回到線程問題，因為正是它把我們帶到了這兒。實際上非常容易：因為我們已經有了異步功能的監聽器，我們可以簡單地讓監聽器自己決定它們應該在哪個線程中執行?？紤]UI類和LookupManager的分離。UI類基于事件，決定需要什么處理。并且，該類也是Swing，而日志類不是。所以讓UI類負責決定它應該在什么線程中執行將更加有意義。所以，讓我們再次看看UI類。下面是沒有線程的lookupCompleted()方法：

public void lookupCompleted(final LookupEvent e) {
　outputTA.setText(""); 
　String[] results = e.getResults(); 
　for (int i = 0; i < results.length; i++) {
　　String result = results[i]; 
　　outputTA.setText(outputTA.getText() + "\n" + result); 
　}
} 

　　我們知道這將在非Swing線程中調用，因為該事件是直接在LookupManager中觸發的，這將不是在Swing線程中執行。因為所有的代碼功能上都是異步的（我們不必等待監聽器方法允許結束后才調用其它代碼），我們可以通過SwingUtilities.invokeLater()將這些代碼改道到Swing線程。下面是新的方法，傳入一個匿名Runnable到SwingUtilities.invokeLater():

public void lookupCompleted(final LookupEvent e) { 
　//notice the threading 
　SwingUtilities.invokeLater( new Runnable() { 
　　public void run() { 
　　　outputTA.setText("");
　　　String[] results = e.getResults(); 
　　　for (int i = 0; i < results.length; i++) {
　　　　String result = results[i]; 
　　　　outputTA.setText(outputTA.getText() + "\n" + result);
　　　}
　　}
　}
);
} 

　　如果任何LookupListener不是在Swing線程中執行，我們可以在調用線程中執行監聽器代碼。作為一個原則，我們希望所有的監聽器都迅速地接到通知。所以，如果你有一個監聽器需要很多時間來處理自己的功能，你應該創建一個新的線程或者把耗時代碼放入ThreadPool中等待執行。

　　最后的步驟是讓LookupManager在非Swing線程中執行lookup。當前，LookupManager是在JButton的ActionListener的Swing線程中被調用的?，F在是我們做出決定的時候，或者我們在JButton的ActionListener中引入一個新的線程，或者我們可以保證lookup自己在非Swing線程中執行，自己開始一個新的線程。我選擇盡可能和Swing類貼近地管理Swing線程。這有助于把所有Swing邏輯封裝在一起。如果我們把Swing線程邏輯添加到LookupManager，我們將引入了一層不必要的依賴。并且，對于LookupManager在非Swing線程環境中孵化自己的線程是完全沒有必要的，比如一個非繪圖的用戶界面，在我們的例子中，就是Logger。產生不必要的新線程將損害到你應用的性能，而不是提高性能。LookupManager執行的很好，不管Swing線程與否－－所以，我喜歡把代碼集中在那兒。

　　現在我們需要將JButton的ActionListener執行lookup的代碼放在一個非Swing線程中。我們創建一個匿名的Thread，使用一個匿名的Runnable執行這個lookup。

private void searchButton_actionPerformed() {
　new Thread(){ 
　　public void run() {
　　　lookupManager.lookup(searchTF.getText());
　　}
　}.start();
} 

　　這就完成了我們的Swing線程。簡單地在actionPerformed()方法中添加線程，確保監聽器在新的線程中執行照顧到了整個線程問題。注意，我們不用處理像第一個例子那樣的任何問題。通過把時間花費在定義一個事件驅動的體系，我們在和Swing線程相關處理上節約了更多的時間。

　　結論

　　如果你需要在同一個方法中執行大量的Swing代碼和非Swing代碼，很容易將某些代碼放錯位置。事件驅動的方式將迫使你將代碼放在它應該在的地方－－它僅應該在的地方。如果你在同一個方法中執行數據庫調用和更新UI組件，那么你就在一個類中寫入了太多的邏輯。分析你系統中的事件，創建底層的事件模型將迫使你將代碼放到正確的地方。將費時的數據庫調用代碼放在非UI類中，也不要在非UI組件中更新UI組件。采用事件驅動的體系，UI負責UI更新，數據庫管理類負責數據庫調用。在這一點上，每一個封裝的類都只用關心自己的線程，不用擔心系統其它部分如何動作。當然，設計、構建一個事件驅動的客戶端也很有用，但是需要花費的時間代價遠超過帶來的結果系統的靈活性和可維護性的提高。