Java開發中的執行緒安全選擇與Swing(轉)

Java開發中的執行緒安全選擇與Swing(轉)[@more@]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。
使用invokeLater()方法

　　你可以從任何執行緒呼叫invokeLater()方法以請求事件派發執行緒執行特定程式碼。你必須把要執行的程式碼放到一個Runnable物件的 run()方法中，並將此Runnable物件設為invokeLater()的引數。invokeLater()方法會立即返回，不等待事件派發執行緒執行指定程式碼。這是一個使用invokeLater()方法的例子：

Runnable doWorkRunnable = new Runnable()
{
　public void run()
　{
　　doWork();
　 }
};
SwingUtilities.invokeLater(doWorkRunnable);

　　使用invokeAndWait()方法

　　invokeAndWait()方法和invokeLater()方法很相似，除了invokeAndWait()方法會等事件派發執行緒執行了指定程式碼才返回。在可能的情況下，你應該儘量用invokeLater()來代替invokeAndWait()。如果你真的要使用 invokeAndWait()，請確保呼叫invokeAndWait()的執行緒不會在呼叫期間持有任何其他執行緒可能需要的鎖。
這是一個使用invokeAndWait()的例子：

void showHelloThereDialog() throws Exception
{
　Runnable showModalDialog = new Runnable()
　{
　　public void run()
　　{
　　　JOptionPane.showMessageDialog( myMainFrame, "Hello There");
　　 }
　 };
　SwingUtilities.invokeAndWait (showModalDialog);
}

　　類似地，假設一個執行緒需要對GUI的狀態進行存取，比如文字域的內容，它的程式碼可能類似這樣：

void printTextField()
　 throws Exception {
　　 final String[] myStrings = new String[2];
　　 Runnable getTextFieldText = new Runnable() {
　　　 public void run() {
　　　　 myStrings[0] = textField0.getText();
　　　　 myStrings[1] = textField1.getText();
　　　 }
　　 };
　　 SwingUtilities.invokeAndWait (getTextFieldText);
　　 System.out.println(myStrings[0] + " " + myStrings[1]);}

　　如果你能避免使用執行緒，最好這樣做。執行緒可能難於使用，並使得程式的debug更困難。一般來說，對於嚴格意義下的GUI工作，執行緒是不必要的，比如對元件屬性的更新。

　　不管怎麼說，有時候執行緒是必要的。下列情況是使用執行緒的一些典型情況：

　　執行一項費時的任務而不必將事件派發執行緒鎖定。例子包括執行大量計算的情況，會導致大量類被裝載的情況（如初始化），和為網路或磁碟I/O而阻塞的情況。

　　重複地執行一項操作，通常在兩次操作間間隔一個預定的時間週期。

　　要等待來自客戶的訊息。

　　你可以使用兩個類來幫助你實現執行緒：

　　　SwingWorker：建立一個後臺執行緒來執行費時的操作。

　　　Timer：建立一個執行緒來執行或多次執行某些程式碼，在兩次執行間間隔使用者定義的延遲。
使用SwingWorker類

　　SwingWorker類在SwingWorker.java中實現，這個類並不包含在Java的任何發行版中，所以你必須單獨下載它。

　　SwingWorker類做了所有實現一個後臺執行緒所需的骯髒工作。雖然許多程式都不需要後臺執行緒，後臺執行緒在執行費時的操作時仍然是很有用的，它能提高程式的效能觀感。

SwingWorker´s get() method. Here´s an example of using SwingWorker:

　　要使用SwingWorker類，你首先要實現它的一個子類。在子類中，你必須實現construct()方法還包含你的長時間操作。當你例項化SwingWorker的子類時，SwingWorker建立一個執行緒但並不啟動它。你要呼叫你的SwingWorker物件的start()方法來啟動執行緒，然後start()方法會呼叫你的construct()方法。當你需要construct()方法返回的物件時，可以呼叫 SwingWorker類的get()方法。這是一個使用SwingWorker類的例子：

...// 在main方法中：
final SwingWorker worker = new SwingWorker() {
　public Object construct() {
　　return new expensiveDialogComponent();
　 }
};
worker.start();
...
// 在動作事件處理方法中:
JOptionPane.showMessageDialog (f, worker.get());

　　當程式的main()方法呼叫start()方法，SwingWorker啟動一個新的執行緒來例項化ExpensiveDialogComponent。main()方法還構造了由一個視窗和一個按鈕組成的GUI。

　　當使用者點選按鈕，程式將阻塞，如果必要，阻塞到ExpensiveDialogComponent建立完成。然後程式顯示一個包含ExpensiveDialogComponent的模式對話方塊。你可以在MyApplication.java找到整個程式。

　　使用Timer類

　　Timer類透過一個ActionListener來執行或多次執行一項操作。你建立定時器的時候可以指定操作執行的頻率，並且你可以指定定時器的動作事件的監聽者（action listener）。啟動定時器後，動作監聽者的actionPerformed()方法會被（多次）呼叫來執行操作。

　　定時器動作監聽者（action listener）定義的actionPerformed()方法將在事件派發執行緒中呼叫。這意味著你不必在其中使用invokeLater()方法。

　　這是一個使用Timer類來實現動畫迴圈的例子：

public class AnimatorApplicationTimer
　extends JFrame implements ActionListener {
　　...//在這裡定義例項變數
　　Timer timer;
　　public AnimatorApplicationTimer(...) {
　　　... // 建立一個定時器來
　　　// 來呼叫此物件action handler。
　　　timer = new Timer(delay, this);
　　　timer.setInitialDelay(0);
　　　timer.setCoalesce(true);
　　　...
　　}
　　public void startAnimation() {
　　　if (frozen) {
　　　　// 什麼都不做。應使用者要求
　　　　// 停止變換影像。
　　　} else {
　　　　// 啟動（或重啟動）動畫！
　　　　timer.start();
　　　}
　　}
　　public void stopAnimation() {
　　　// 停止動畫執行緒。
　　　timer.stop();
　　}
　　public void actionPerformed (ActionEvent e)
　　{
　　　// 進到下一幀動畫。
　　　frameNumber++;
　　　// 顯示。
　　　repaint();
　　}
　 ...
}
在一個執行緒中執行所有的使用者介面程式碼有這樣一些優點：

　　元件開發者不必對執行緒程式設計有深入的理解：像ViewPoint和Trestle這類工具包中的所有元件都必須完全支援多執行緒訪問，使得擴充套件非常困難，尤其對不精通執行緒程式設計的開發者來說。最近的一些工具包如SubArctic和IFC，都採用和Swing類似的設計。

　　事件以可預知的次序派發：invokeLater()排隊的runnable物件從滑鼠和鍵盤事件、定時器事件、繪製請求的同一個佇列派發。在一些元件完全支援多執行緒訪問的工具包中，元件的改變被變化無常的執行緒排程程式穿插到事件處理過程中。這使得全面測試變得困難甚至不可能。

　　更低的代價：嘗試小心鎖住臨界區的工具包要花費實足的時間和空間在鎖的管理上。每當工具包中呼叫某個可能在客戶程式碼中實現的方法時（如 public類中的任何public和protected方法），工具包都要儲存它的狀態並釋放所有鎖，以便客戶程式碼能在必要時獲得鎖。當控制權交回到工具包，工具包又必須重新抓住它的鎖並恢復狀態。所有應用程式都不得不負擔這一代價，即使大多數應用程式並不需要對GUI的併發訪問。

　　這是的SubArctic Java Toolkit的作者對在工具包中支援多執行緒訪問的問題的描述：

　　我們的基本信條是，當設計和建造多執行緒應用程式，尤其是那些包括GUI元件的應用程式時，必須保證極端小心。執行緒的使用可能會很有欺騙性。在許多情況下，它們表現得能夠極好的簡化編成，使得設計“專注於單一任務的簡單自治實體”成為可能。在一些情況下它們的確簡化了設計和編碼。然而，在幾乎所有的情況下，它們都使得除錯、測試和維護的困難大大增加甚至成為不可能。無論大多數程式設計師所受的訓練、他們的經驗和實踐，還是我們用來幫助自己的工具，都不是能夠用來對付非決定論的。例如，全面測試（這總是困難的）在bug依賴於時間時是幾乎不可能的。尤其對於Java來說，一個程式要執行在許多不同型別的機器的作業系統平臺上，並且每個程式都必須在搶先和非搶先式排程下都能正常工作。

　　由於這些固有的困難，我們力勸你三思是否絕對有使用執行緒的必要。儘管如此，有些情況下使用執行緒是必要的（或者是被其他軟體包強加的），所以subArctic提供了一個執行緒安全的訪問機制。本章討論了這一機制和怎樣在一個獨立執行緒中安全地操作互動樹。

　　他們所說的執行緒安全機制非常類似於SwingUtilities類提供的invokeLater()和invokeAndWait()方法。