這篇文章將為大家詳細講解有關(guān)Java開發(fā)中線程安全選擇與Swing怎么用，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。
Swing API的設(shè)計目標是強大、靈活和易用。特別地，我們希望能讓程序員們方便地建立新的Swing組件，不論是從頭開始還是通過擴展我們所提供的一些組件。
出于這個目的，我們不要求Swing組件支持多線程訪問。相反，我們向組件發(fā)送請求并在單一線程中執(zhí)行請求。
本文討論線程和Swing組件。目的不僅是為了幫助你以線程安全的方式使用Swing API，而且解釋了我們?yōu)槭裁磿x擇現(xiàn)在這樣的線程方案。
本文包括以下內(nèi)容：
單線程規(guī)則：Swing線程在同一時刻僅能被一個線程所訪問。一般來說，這個線程是事件派發(fā)線程（event-dispatching thread）。
規(guī)則的例外：有些操作保證是線程安全的。
事件分發(fā)：如果你需要從事件處理（event-handling）或繪制代碼以外的地方訪問UI，那么你可以使用SwingUtilities類的invokeLater()或invokeAndWait()方法。
創(chuàng)建線程：如果你需要創(chuàng)建一個線程??比如用來處理一些耗費大量計算能力或受I/O能力限制的工作??你可以使用一個線程工具類如SwingWorker或Timer。
為什么我們這樣實現(xiàn)Swing：我們將用一些關(guān)于Swing的線程安全的背景資料來結(jié)束這篇文章。
Swing的規(guī)則是：
一旦Swing組件被具現(xiàn)化（realized），所有可能影響或依賴于組件狀態(tài)的代碼都應(yīng)該在事件派發(fā)線程中執(zhí)行。
這個規(guī)則可能聽起來有點嚇人，但對許多簡單的程序來說，你用不著為線程問題操心。在我們深入如何撰寫Swing代碼之前，讓我們先來定義兩個術(shù)語：具現(xiàn)化（realized）和事件派發(fā)線程（event-dispatching thread）。
具現(xiàn)化的意思是組建的paint()方法已經(jīng)或可能會被調(diào)用。一個作為頂級窗口的Swing組件當調(diào)用以下方法時將被具現(xiàn)化： setVisible(true)、show()或（可能令你驚奇）pack()。當一個窗口被具現(xiàn)化，它包含的所有組件都被具現(xiàn)化。另一個具現(xiàn)化一個組件的方法是將它放入到一個已經(jīng)具現(xiàn)化的容器中。稍后你會看到一些對組件具現(xiàn)化的例子。
事件派發(fā)線程是執(zhí)行繪制和事件處理的線程。例如，paint()和actionPerformed()方法會自動在事件派發(fā)線程中執(zhí)行。另一個將代碼放到事件派發(fā)線程中執(zhí)行的方法是使用SwingUtilities類的invokeLater()方法。
所有可能影響一個已具現(xiàn)化的Swing組件的代碼都必須在事件派發(fā)線程中執(zhí)行。但這個規(guī)則有一些例外：
有些方法是線程安全的：在Swing API的文檔中，線程安全的方法用以下文字標記：
This method is thread safe, although most Swing methods are not.
（這個方法是線程安全的，盡管大多數(shù)Swing方法都不是。）
一個應(yīng)用程序的GUI常?？梢栽谥骶€程中構(gòu)建和顯示：下面的典型代碼是安全的，只要沒有（Swing或其他）組件被具現(xiàn)化：
public class MyApplication
{
public static void main(String[] args)
{
JFrame f = new JFrame("Labels"); // 在這里將各組件
// 加入到主框架……
f.pack();
f.show();
// 不要再做任何GUI工作……
}
}
上面所示的代碼全部在“main”線程中運行。對f.pack()的調(diào)用使得JFrame以下的組件都被具現(xiàn)化。這意味著，f.show() 調(diào)用是不安全的且應(yīng)該在事件派發(fā)線程中執(zhí)行。盡管如此，只要程序還沒有一個看得到的GUI，JFrame或它的里面的組件就幾乎不可能在f.show() 返回前收到一個paint()調(diào)用。因為在f.show()調(diào)用之后不再有任何GUI代碼，于是所有GUI工作都從主線程轉(zhuǎn)到了事件派發(fā)線程，因此前面所討論的代碼實際上是線程安全的。
一個applet的GUI可以在init()方法中構(gòu)造和顯示：現(xiàn)有的瀏覽器都不會在一個applet的init()和start()方法被調(diào)用前繪制它。因而，在一個applet的init()方法中構(gòu)造GUI是安全的，只要你不對applet中的對象調(diào)用show()或 setVisible(true)方法。
要順便一提的是，如果applet中使用了Swing組件，就必須實現(xiàn)為JApplet的子類。并且，組件應(yīng)該添加到的JApplet內(nèi)容窗格（content pane）中，而不要直接添加到JApplet。對任何applet，你都不應(yīng)該在init()或start()方法中執(zhí)行費時的初始化操作；而應(yīng)該啟動一個線程來執(zhí)行費時的任務(wù)。
下述JComponent方法是安全的，可以從任何線程調(diào)用：repaint()、revalidate()、和invalidate()。 repaint()和revalidate()方法為事件派發(fā)線程對請求排隊，并分別調(diào)用paint()和validate()方法。 invalidate()方法只在需要確認時標記一個組件和它的所有直接祖先。
監(jiān)聽者列表可以由任何線程修改：調(diào)用addListenerTypeListener()和removeListenerTypeListener()方法總是安全的。對監(jiān)聽者列表的添加/刪除操作不會對進行中的事件派發(fā)有任何影響。
注意：revalidate()和舊的validate()方法之間的重要區(qū)別是，revalidate()會緩存請求并組合成一次validate()調(diào)用。這和repaint()緩存并組合繪制請求類似。
大多數(shù)初始化后的GUI工作自然地發(fā)生在事件派發(fā)線程。一旦GUI成為可見，大多數(shù)程序都是由事件驅(qū)動的，如按鈕動作或鼠標點擊，這些總是在事件派發(fā)線程中處理的。
不過，總有些程序需要在GUI成為可見后執(zhí)行一些非事件驅(qū)動的GUI工作。比如：
在成為可用前需要進行長時間初始化操作的程序：這類程序通常應(yīng)該在初始化期間就顯示出GUI，然后更新或改變GUI。初始化過程不應(yīng)該在事件派發(fā)線程中進行；否則，重繪組件和事件派發(fā)會停止。盡管如此，在初始化之后，GUI的更新/改變還是應(yīng)該在事件派發(fā)線程中進行，理由是線程安全。
必須響應(yīng)非AWT事件來更新GUI的程序：例如，想象一個服務(wù)器程序從可能運行在其他機器上的程序得到請求。這些請求可能在任何時刻到達，并且會引起在一些可能未知的線程中對服務(wù)器的方法調(diào)用。這個方法調(diào)用怎樣更新GUI呢？在事件派發(fā)線程中執(zhí)行GUI更新代碼。
SwingUtilities類提供了兩個方法來幫助你在事件派發(fā)線程中執(zhí)行代碼：
invokeLater()：要求在事件派發(fā)線程中執(zhí)行某些代碼。這個方法會立即返回，不會等待代碼執(zhí)行完畢。
invokeAndWait()：行為與invokeLater()類似，除了這個方法會等待代碼執(zhí)行完畢。一般地，你可以用invokeLater()來代替這個方法。
下面是一些使用這幾個API的例子。請同時參閱《The Java Tutorial》中的“BINGO example”，尤其是以下幾個類：CardWindow、ControlPane、Player和OverallStatusPane。
使用invokeLater()方法
你可以從任何線程調(diào)用invokeLater()方法以請求事件派發(fā)線程運行特定代碼。你必須把要運行的代碼放到一個Runnable對象的 run()方法中，并將此Runnable對象設(shè)為invokeLater()的參數(shù)。invokeLater()方法會立即返回，不等待事件派發(fā)線程執(zhí)行指定代碼。這是一個使用invokeLater()方法的例子：
Runnable doWorkRunnable = new Runnable()
{
public void run()
{
doWork();
}
};
SwingUtilities.invokeLater(doWorkRunnable);
使用invokeAndWait()方法
invokeAndWait()方法和invokeLater()方法很相似，除了invokeAndWait()方法會等事件派發(fā)線程執(zhí)行了指定代碼才返回。在可能的情況下，你應(yīng)該盡量用invokeLater()來代替invokeAndWait()。如果你真的要使用 invokeAndWait()，請確保調(diào)用invokeAndWait()的線程不會在調(diào)用期間持有任何其他線程可能需要的鎖。
這是一個使用invokeAndWait()的例子：
void showHelloThereDialog() throws Exception
{
Runnable showModalDialog = new Runnable()
{
public void run()
{
JOptionPane.showMessageDialog( myMainFrame, "Hello There");
}
};
SwingUtilities.invokeAndWait (showModalDialog);
}
類似地，假設(shè)一個線程需要對GUI的狀態(tài)進行存取，比如文本域的內(nèi)容，它的代碼可能類似這樣：
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工作，線程是不必要的，比如對組件屬性的更新。
不管怎么說，有時候線程是必要的。下列情況是使用線程的一些典型情況：
執(zhí)行一項費時的任務(wù)而不必將事件派發(fā)線程鎖定。例子包括執(zhí)行大量計算的情況，會導致大量類被裝載的情況（如初始化），和為網(wǎng)絡(luò)或磁盤I/O而阻塞的情況。
重復地執(zhí)行一項操作，通常在兩次操作間間隔一個預(yù)定的時間周期。
要等待來自客戶的消息。
你可以使用兩個類來幫助你實現(xiàn)線程：
SwingWorker：創(chuàng)建一個后臺線程來執(zhí)行費時的操作。
Timer：創(chuàng)建一個線程來執(zhí)行或多次執(zhí)行某些代碼，在兩次執(zhí)行間間隔用戶定義的延遲。
使用SwingWorker類
SwingWorker類在SwingWorker.java中實現(xiàn)，這個類并不包含在Java的任何發(fā)行版中，所以你必須單獨下載它。
SwingWorker類做了所有實現(xiàn)一個后臺線程所需的骯臟工作。雖然許多程序都不需要后臺線程，后臺線程在執(zhí)行費時的操作時仍然是很有用的，它能提高程序的性能觀感。
SwingWorker´s get() method. Here´s an example of using SwingWorker:
要使用SwingWorker類，你首先要實現(xiàn)它的一個子類。在子類中，你必須實現(xiàn)construct()方法還包含你的長時間操作。當你實例化SwingWorker的子類時，SwingWorker創(chuàng)建一個線程但并不啟動它。你要調(diào)用你的SwingWorker對象的start()方法來啟動線程，然后start()方法會調(diào)用你的construct()方法。當你需要construct()方法返回的對象時，可以調(diào)用 SwingWorker類的get()方法。這是一個使用SwingWorker類的例子：
...// 在main方法中：
final SwingWorker worker = new SwingWorker() {
public Object construct() {
return new expensiveDialogComponent();
}
};
worker.start();
...
// 在動作事件處理方法中:
JOptionPane.showMessageDialog (f, worker.get());
當程序的main()方法調(diào)用start()方法，SwingWorker啟動一個新的線程來實例化ExpensiveDialogComponent。main()方法還構(gòu)造了由一個窗口和一個按鈕組成的GUI。
當用戶點擊按鈕，程序?qū)⒆枞?，如果必要，阻塞到ExpensiveDialogComponent創(chuàng)建完成。然后程序顯示一個包含ExpensiveDialogComponent的模式對話框。你可以在MyApplication.java找到整個程序。
使用Timer類
Timer類通過一個ActionListener來執(zhí)行或多次執(zhí)行一項操作。你創(chuàng)建定時器的時候可以指定操作執(zhí)行的頻率，并且你可以指定定時器的動作事件的監(jiān)聽者（action listener）。啟動定時器后，動作監(jiān)聽者的actionPerformed()方法會被（多次）調(diào)用來執(zhí)行操作。
定時器動作監(jiān)聽者（action listener）定義的actionPerformed()方法將在事件派發(fā)線程中調(diào)用。這意味著你不必在其中使用invokeLater()方法。
這是一個使用Timer類來實現(xiàn)動畫循環(huán)的例子：
public class AnimatorApplicationTimer
extends JFrame implements ActionListener {
...//在這里定義實例變量
Timer timer;
public AnimatorApplicationTimer(...) {
... // 創(chuàng)建一個定時器來
// 來調(diào)用此對象action handler。
timer = new Timer(delay, this);
timer.setInitialDelay(0);
timer.setCoalesce(true);
...
}
public void startAnimation() {
if (frozen) {
// 什么都不做。應(yīng)用戶要求
// 停止變換圖像。
} else {
// 啟動（或重啟動）動畫！
timer.start();
}
}
public void stopAnimation() {
// 停止動畫線程。
timer.stop();
}
public void actionPerformed (ActionEvent e)
{
// 進到下一幀動畫。
frameNumber++;
// 顯示。
repaint();
}
...
}
在一個線程中執(zhí)行所有的用戶界面代碼有這樣一些優(yōu)點：
組件開發(fā)者不必對線程編程有深入的理解：像ViewPoint和Trestle這類工具包中的所有組件都必須完全支持多線程訪問，使得擴展非常困難，尤其對不精通線程編程的開發(fā)者來說。最近的一些工具包如SubArctic和IFC，都采用和Swing類似的設(shè)計。
事件以可預(yù)知的次序派發(fā)：invokeLater()排隊的runnable對象從鼠標和鍵盤事件、定時器事件、繪制請求的同一個隊列派發(fā)。在一些組件完全支持多線程訪問的工具包中，組件的改變被變化無常的線程調(diào)度程序穿插到事件處理過程中。這使得全面測試變得困難甚至不可能。
更低的代價：嘗試小心鎖住臨界區(qū)的工具包要花費實足的時間和空間在鎖的管理上。每當工具包中調(diào)用某個可能在客戶代碼中實現(xiàn)的方法時（如 public類中的任何public和protected方法），工具包都要保存它的狀態(tài)并釋放所有鎖，以便客戶代碼能在必要時獲得鎖。當控制權(quán)交回到工具包，工具包又必須重新抓住它的鎖并恢復狀態(tài)。所有應(yīng)用程序都不得不負擔這一代價，即使大多數(shù)應(yīng)用程序并不需要對GUI的并發(fā)訪問。
這是的SubArctic Java Toolkit的作者對在工具包中支持多線程訪問的問題的描述：
我們的基本信條是，當設(shè)計和建造多線程應(yīng)用程序，尤其是那些包括GUI組件的應(yīng)用程序時，必須保證極端小心。線程的使用可能會很有欺騙性。在許多情況下，它們表現(xiàn)得能夠極好的簡化編成，使得設(shè)計“專注于單一任務(wù)的簡單自治實體”成為可能。在一些情況下它們的確簡化了設(shè)計和編碼。然而，在幾乎所有的情況下，它們都使得調(diào)試、測試和維護的困難大大增加甚至成為不可能。無論大多數(shù)程序員所受的訓練、他們的經(jīng)驗和實踐，還是我們用來幫助自己的工具，都不是能夠用來對付非決定論的。例如，全面測試（這總是困難的）在bug依賴于時間時是幾乎不可能的。尤其對于Java來說，一個程序要運行在許多不同類型的機器的操作系統(tǒng)平臺上，并且每個程序都必須在搶先和非搶先式調(diào)度下都能正常工作。
由于這些固有的困難，我們力勸你三思是否絕對有使用線程的必要。盡管如此，有些情況下使用線程是必要的（或者是被其他軟件包強加的），所以subArctic提供了一個線程安全的訪問機制。本章討論了這一機制和怎樣在一個獨立線程中安全地操作交互樹。
他們所說的線程安全機制非常類似于SwingUtilities類提供的invokeLater()和invokeAndWait()方法。
關(guān)于“Java開發(fā)中線程安全選擇與Swing怎么用”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。
重慶分公司
重慶分公司
