Swing任務在Swing線程中執(zhí)行
Swing任務在Swing線程中執(zhí)行
界面顯示了一個null，因為顯示代碼在查找代碼完成前被處理了。這是因為一旦新的線程啟動了，代碼塊繼續(xù)執(zhí)行，而不是等待線程執(zhí)行完畢。這是那些奇怪的并發(fā)代碼塊中的一個，下面將把它編寫到一個方法中使其能夠真正執(zhí)行。
在 SwingUtilities類中有兩個方法可以幫助我們解決這些問題：invokerLater()和invokeAndWait()。每一個方法都以一個Runnable作為參數(shù)，并在Swing線程中執(zhí)行它。invokeAndWait（）方法阻塞直到Runnnable執(zhí)行完畢；invokeLater()異步地執(zhí)行Runnable。invokeAndWait()一般不贊成使用，因為它可能導致嚴重的線程死鎖，對你的應用造成嚴重的破壞。所以，讓我們把它放置一邊，使用invokeLater()方法。
要修正最后一個變量變量scooping和執(zhí)行順序的問題，我們必須將文本區(qū)域的getText()和setText()方法調(diào)用移入一個Runnable，只有在查詢結果返回后再執(zhí)行它，并且使Swing任務在Swing線程中執(zhí)行。我們可以這樣作，創(chuàng)建一個匿名Runnable傳遞給invokeLater()，包括在新線程的Runnable后的文本區(qū)域操作。這保證了 Swing代碼不會在查找結束之前執(zhí)行。下面是修正后的代碼：
- privatevoidsearchButton_actionPerformed(){
- outputTA.setText("Searchingfor:"+
- searchTF.getText());
- finalString[][]results=newString[1][1];
- newThread(){
- publicvoidrun(){
- //getresults.
- results[0]=lookup(searchTF.getText());
- //sendrunnabletotheSwingthread
- //therunnableisqueuedafterthe
- //resultsarereturned
- SwingUtilities.invokeLater(
- newRunnable(){
- publicvoidrun(){
- //Nowwe'reintheSwingthread
- outputTA.setText("");
- for(inti=0;
- i<results[0].length;
- i++){
- Stringresult=results[0][i];
- outputTA.setText(
- outputTA.getText()+
- ''+result);
- }
- }
- }
- );
- }
- }.start();
- }
這可以工作，但是這樣做令人非常頭痛。我們不得不對通過匿名線程執(zhí)行的順序，我們還不得不處理困難的scooping問題。問題并不少見，并且，這只是一個非常簡單的例子，我們已經(jīng)遇到了作用域，變量傳遞，和執(zhí)行順序等一系列問題。相像一個更復雜的問題，包含了幾層嵌套，共享的引用和指定的執(zhí)行順序。這種方法很快就失控了。
問題
我們在企圖強制通過異步模型進行同步執(zhí)行－－企圖將一個方形的螺栓放到一個圓形的空中。只有我們嘗試這樣做，我們就會不斷地遭遇這些問題。從我的經(jīng)驗，可以告訴你這些代碼很難閱讀，很難維護，并且易于出錯。
這看起來是一個常見的問題，所以一定有標準的方式來解決，對嗎？出現(xiàn)了一些框架用于管理Swing的復雜性，所以讓我們來快速預覽一下它們可以做什么。
一個可以得到的解決方案是Foxtrot，一個由Biorn Steedom寫的框架，可以在SourceForge上獲取。它使用一個叫做Worker的對象來控制非Swing任務在非 Swing線程中的執(zhí)行，阻塞直到非Swing任務執(zhí)行完畢。它簡化了Swing線程，允許你編寫同步代碼，并在Swing線程和非Swing線程直接切換。下面是來自它的站點的一個例子：
- publicvoidactionPerformed(ActionEvente)
- {
- button.setText("Sleeping...");
- Stringtext=null;
- try
- {
- text=(String)Worker.post(newTask()
- {
- publicObjectrun()throwsException
- {
- Thread.sleep(10000);
- return"Slept!";
- }
- });
- }
- catch(Exceptionx)...
- button.setText(text);
- somethingElse();
- }
注意它是如何解決上面的那些問題的。我們能夠非常容易地在Swing線程中傳入傳出變量。并且，代碼塊看起來也很正確－－先編寫的先執(zhí)行。但是仍然有一些問題障礙阻止使用從準同步異步解決方案。Foxtrot中的一個問題是異常管理。使用Foxtrot，每次調(diào)用Worker必須捕獲Exception。這是將執(zhí)行代理給Worker來解決同步對異步問題的一個產(chǎn)物。
同樣以非常相似的方式，我此前也創(chuàng)建了一個框架，我稱它為鏈接運行引擎（Chained Runnable Engine） ，同樣也遭受來自類似同步對異步問題的困擾。使用這個框架，你將創(chuàng)建一個將被引擎執(zhí)行的Runnable的集合。每一個Runnable都有一個指示器告訴引擎是否應該在Swing線程或者另外的線程中執(zhí)行。引擎也保證Runnable以正確的順序執(zhí)行。所以Runnable #2將不會放入隊列直到Runnable #1執(zhí)行完畢。并且，它支持變量以HashMap的形式從Runnable到Runnable傳遞。
表面上，它看起來解決了我們的主要問題。但是當你深入進去后，同樣的問題又冒出來了。本質上，我們并沒有改變上面描述的任何東西－－我們只是將復雜性隱藏在引擎的后面。因為指數(shù)級增長的Runnable而使代碼編寫將變得非常枯燥，也很復雜，并且這些Runnable常常相互耦合。Runnable之間的非類型的HashMap變量傳遞變得難于管理。問題的列表還有很多。
在編寫這個框架之后，我意識到這需要一個完全不同的解決方案。這讓我重新審視了問題，看別人是怎么解決類似的問題的，并深入的研究了Swing的源代碼。
【編輯推薦】
