即使在圖形用戶界面占統治地位的今天,控制臺輸出仍舊在Java程序中占有重要地位。控制臺不僅是Java程序默認的堆棧跟蹤和錯誤信息輸出窗口,而且還 是一種實用的調試工具(特別是對習慣于使用println()的人來說)。然而,控制臺窗口有著許多局限。例如在Windows 9x平臺上,DOS控制臺只能容納50行輸出。如果Java程序一次性向控制臺輸出大量內容,要查看這些內容就很困難了。
對于使用javaw這個啟動程序的開發者來說,控制臺窗口尤其寶貴。因為用javaw啟動java程序時,根本不會有控制臺窗口出現。如果程序遇到了問題 并拋出異常,根本無法查看Java運行時環境寫入到System.out或System.err的調用堆棧跟蹤信息。為了捕獲堆棧信息,一些人采取了用 try/catch()塊封裝main()的方式,但這種方式不一定總是有效,在Java運行時的某些時刻,一些描述性錯誤信息會在拋出異常之前被寫入 System.out和System.err;除非能夠監測這兩個控制臺流,否則這些信息就無法看到。
因此,有些時候檢查Java運行時環境(或第三方程序)寫入到控制臺流的數據并采取合適的操作是十分必要的。本文討論的主題之一就是創建這樣一個輸入流, 從這個輸入流中可以讀入以前寫入Java控制臺流(或任何其他程序的輸出流)的數據。我們可以想象寫入到輸出流的數據立即以輸入的形式“回流”到了 Java程序。
本文的目標是設計一個基于Swing的文本窗口顯示控制臺輸出。在此期間,我們還將討論一些和Java管道流(PipedInputStream和 PipedOutputStream)有關的重要注意事項。圖一顯示了用來截取和顯示控制臺文本輸出的Java程序,用戶界面的核心是一個 JTextArea。最后,我們還要創建一個能夠捕獲和顯示其他程序(可以是非Java的程序)控制臺輸出的簡單程序。
圖一:多線程的控制臺輸出截取程序

要在文本框中顯示控制臺輸出,我們必須用某種方法“截取”控制臺流。換句話說,我們要有一種高效地讀取寫入到System.out和System.err 所有內容的方法。如果你熟悉Java的管道流PipedInputStream和PipedOutputStream,就會相信我們已經擁有最有效的工 具。
寫入到PipedOutputStream輸出流的數據可以從對應的PipedInputStream輸入流讀取。Java的管道流極大地方便了我們截取控制臺輸出。Listing 1顯示了一種非常簡單的截取控制臺輸出方案。
【Listing 1:用管道流截取控制臺輸出】 |
可以看到,這里的代碼極其簡單。我們只是建立了一個PipedInputStream,把它設置為所有寫入控制臺流的數據的最終目的地。所有寫入到控制臺 流的數據都被轉到PipedOutputStream,這樣,從相應的PipedInputStream讀取就可以迅速地截獲所有寫入控制臺流的數據。接 下來的事情似乎只剩下在Swing JTextArea中顯示從pipedIS流讀取的數據,得到一個能夠在文本框中顯示控制臺輸出的程序。遺憾的是,在使用Java管道流時有一些重要的注 意事項。只有認真對待所有這些注意事項才能保證Listing 1的代碼穩定地運行。下面我們來看第一個注意事項。
1.1 注意事項一
PipedInputStream運用的是一個1024字節固定大小的循環緩沖區。寫入PipedOutputStream的數據實際上保存到對應的
PipedInputStream的內部緩沖區。從PipedInputStream執行讀操作時,讀取的數據實際上來自這個內部緩沖區。如果對應的
PipedInputStream輸入緩沖區已滿,任何企圖寫入PipedOutputStream的線程都將被阻塞。而且這個寫操作線程將一直阻塞,直
至出現讀取PipedInputStream的操作從緩沖區刪除數據。
這意味著,向PipedOutputStream寫數據的線程不應該是負責從對應PipedInputStream讀取數據的唯一線程。從圖二可以清楚地 看出這里的問題所在:假設線程t是負責從PipedInputStream讀取數據的唯一線程;另外,假定t企圖在一次對 PipedOutputStream的write()方法的調用中向對應的PipedOutputStream寫入2000字節的數據。在t線程阻塞之 前,它最多能夠寫入1024字節的數據(PipedInputStream內部緩沖區的大小)。然而,一旦t被阻塞,讀取 PipedInputStream的操作就再也不會出現,因為t是唯一讀取PipedInputStream的線程。這樣,t線程已經完全被阻塞,同時, 所有其他試圖向PipedOutputStream寫入數據的線程也將遇到同樣的情形。
圖二:管道流工作過程

這并不意味著在一次write()調用中不能寫入多于1024字節的數據。但應當保證,在寫入數據的同時,有另一個線程從PipedInputStream讀取數據。
Listing 2示范了這個問題。這個程序用一個線程交替地讀取PipedInputStream和寫入PipedOutputStream。每次調用write()向 PipedInputStream的緩沖區寫入20字節,每次調用read()只從緩沖區讀取并刪除10個字節。內部緩沖區最終會被寫滿,導致寫操作阻 塞。由于我們用同一個線程執行讀、寫操作,一旦寫操作被阻塞,就不能再從PipedInputStream讀取數據。
【Listing 2:用同一個線程執行讀/寫操作導致線程阻塞】 |
只 要把讀/寫操作分開到不同的線程,Listing 2的問題就可以輕松地解決。Listing 3是Listing 2經過修改后的版本,它在一個單獨的線程中執行寫入PipedOutputStream的操作(和讀取線程不同的線程)。為證明一次寫入的數據可以超過 1024字節,我們讓寫操作線程每次調用PipedOutputStream的write()方法時寫入2000字節。那么,在 startWriterThread()方法中創建的線程是否會阻塞呢?按照Java運行時線程調度機制,它當然會阻塞。寫操作在阻塞之前實際上最多只能 寫入1024字節的有效載荷(即PipedInputStream緩沖區的大小)。但這并不會成為問題,因為主線程(main)很快就會從 PipedInputStream的循環緩沖區讀取數據,空出緩沖區空間。最終,寫操作線程會從上一次中止的地方重新開始,寫入2000字節有效載荷中的 剩余部分。
【Listing 3:把讀/寫操作分開到不同的線程】 |
也許我們不能說這個問題是Java管道流設計上的缺陷,但在應用管道流時,它是一個必須密切注意的問題。下面我們來看看第二個更重要(更危險的)問題。
1.2 注意事項二
從PipedInputStream讀取數據時,如果符合下面三個條件,就會出現IOException異常:
- 試圖從PipedInputStream讀取數據,
- PipedInputStream的緩沖區為“空”(即不存在可讀取的數據),
- 最后一個向PipedOutputStream寫數據的線程不再活動(通過Thread.isAlive()檢測)。
這是一個很微妙的時刻,同時也是一個極其重要的時刻。假定有一個線程w向PipedOutputStream寫入數據;另一個線程r從對應的 PipedInputStream讀取數據。下面一系列的事件將導致r線程在試圖讀取PipedInputStream時遇到IOException異 常:
- w向PipedOutputStream寫入數據。
- w結束(w.isAlive()返回false)。
- r從PipedInputStream讀取w寫入的數據,清空PipedInputStream的緩沖區。
- r試圖再次從PipedInputStream讀取數據。這時PipedInputStream的緩沖區已經為空,而且w已經結束,從而導致在讀操作執行時出現IOException異常。
構 造一個程序示范這個問題并不困難,只需從Listing 3的startWriterThread()方法中,刪除while(true)條件。這個改動阻止了執行寫操作的方法循環執行,使得執行寫操作的方法在 一次寫入操作之后就結束運行。如前所述,此時主線程試圖讀取PipedInputStraem時,就會遇到一個IOException異常。
這是一種比較少見的情況,而且不存在直接修正它的方法。請不要通過從管道流派生子類的方法修正該問題――在這里使用繼承是完全不合適的。而且,如果Sun以后改變了管道流的實現方法,現在所作的修改將不再有效。
最后一個問題和第二個問題很相似,不同之處在于,它在讀線程(而不是寫線程)結束時產生IOException異常。
1.3 注意事項三
如果一個寫操作在PipedOutputStream上執行,同時最近從對應PipedInputStream讀取的線程已經不再活動(通過
Thread.isAlive()檢測),則寫操作將拋出一個IOException異常。假定有兩個線程w和r,w向
PipedOutputStream寫入數據,而r則從對應的PipedInputStream讀取。下面一系列的事件將導致w線程在試圖寫入
PipedOutputStream時遇到IOException異常:
- 寫操作線程w已經創建,但r線程還不存在。
- w向PipedOutputStream寫入數據。
- 讀線程r被創建,并從PipedInputStream讀取數據。
- r線程結束。
- w企圖向PipedOutputStream寫入數據,發現r已經結束,拋出IOException異常。
實際上,這個問題不象第二個問題那樣棘手。和多個讀線程/單個寫線程的情況相比,也許在應用中有一個讀線程(作為響應請求的服務器)和多個寫線程(發出請求)的情況更為常見。
1.4 解決問題
要防止管道流前兩個局限所帶來的問題,方法之一是用一個ByteArrayOutputStream作為代理或替代PipedOutputStream。
Listing
4顯示了一個LoopedStreams類,它用一個ByteArrayOutputStream提供和Java管道流類似的功能,但不會出現死鎖和
IOException異常。這個類的內部仍舊使用管道流,但隔離了本文介紹的前兩個問題。我們先來看看這個類的公用方法(參見圖3)。構造函數很簡單,
它連接管道流,然后調用startByteArrayReaderThread()方法(稍后再討論該方法)。getOutputStream()方法返
回一個OutputStream(具體地說,是一個ByteArrayOutputStream)用以替代PipedOutputStream。寫入該
OutputStream的數據最終將在getInputStream()方法返回的流中作為輸入出現。和使用PipedOutputStream的情形
不同,向ByteArrayOutputStream寫入數據的線程的激活、寫數據、結束不會帶來負面效果。
圖三:ByteArrayOutputStream原理

【Listing 4:防止管道流應用中出現的常見問題】 |
startByteArrayReaderThread()方法是整個類真正的關鍵所在。這個方法的目標很簡單,就是創建一個定期地檢查 ByteArrayOutputStream緩沖區的線程。緩沖區中找到的所有數據都被提取到一個byte數組,然后寫入到 PipedOutputStream。由于PipedOutputStream對應的PipedInputStream由getInputStream ()返回,從該輸入流讀取數據的線程都將讀取到原先發送給ByteArrayOutputStream的數據。前面提到,LoopedStreams類解 決了管道流存在的前二個問題,我們來看看這是如何實現的。
ByteArrayOutputStream具有根據需要擴展其內部緩沖區的能力。由于存在“完全緩沖”,線程向getOutputStream()返回 的流寫入數據時不會被阻塞。因而,第一個問題不會再給我們帶來麻煩。另外還要順便說一句,ByteArrayOutputStream的緩沖區永遠不會縮 減。例如,假設在能夠提取數據之前,有一塊500 K的數據被寫入到流,緩沖區將永遠保持至少500 K的容量。如果這個類有一個方法能夠在數據被提取之后修正緩沖區的大小,它就會更完善。
第二個問題得以解決的原因在于,實際上任何時候只有一個線程向PipedOutputStream寫入數據,這個線程就是由 startByteArrayReaderThread()創建的線程。由于這個線程完全由LoopedStreams類控制,我們不必擔心它會產生 IOException異常。
LoopedStreams類還有一些細節值得提及。首先,我們可以看到byteArrayOS和pipedIS實際上分別是 ByteArrayOutputStream和PipedInputStream的派生類的實例,也即在它們的close()方法中加入了特殊的行為。如 果一個LoopedStreams對象的用戶關閉了輸入或輸出流,在startByteArrayReaderThread()中創建的線程必須關閉。覆 蓋后的close()方法把keepRunning標記設置成false以關閉線程。另外,請注意startByteArrayReaderThread ()中的同步塊。要確保在toByteArray()調用和reset()調用之間ByteArrayOutputStream緩沖區不被寫入流的線程修 改,這是必不可少的。由于ByteArrayOutputStream的write()方法的所有版本都在該流上同步,我們保證了 ByteArrayOutputStream的內部緩沖區不被意外地修改。
注意LoopedStreams類并不涉及管道流的第三個問題。該類的getInputStream()方法返回PipedInputStream。如果 一個線程從該流讀取,一段時間后終止,下次數據從ByteArrayOutputStream緩沖區傳輸到PipedOutputStream時就會出現 IOException異常。
![]() ![]() |
![]()
|
Listing 5的ConsoleTextArea類擴展Swing JTextArea捕獲控制臺輸出。不要對這個類有這么多代碼感到驚訝,必須指出的是,ConsoleTextArea類有超過50%的代碼用來進行測試。
【Listing 5:截獲Java控制臺輸出】 |
main()方法創建了一個JFrame,JFrame包含一個ConsoleTextArea的實例。這些代碼并沒有什么特別之處。Frame顯示出來 之后,main()方法啟動一系列的寫操作線程,寫操作線程向控制臺流輸出大量信息。ConsoleTextArea捕獲并顯示這些信息,如圖一所示。
ConsoleTextArea提供了兩個構造函數。沒有參數的構造函數用來捕獲和顯示所有寫入到控制臺流的數據,有一個InputStream[]參數 的構造函數轉發所有從各個數組元素讀取的數據到JTextArea。稍后將有一個例子顯示這個構造函數的用處。首先我們來看看沒有參數的 ConsoleTextArea構造函數。這個函數首先創建一個LoopedStreams對象;然后請求Java運行時環境把控制臺輸出轉發到 LoopedStreams提供的OutputStream;最后,構造函數調用startConsoleReaderThread(),創建一個不斷地 把文本行追加到JTextArea的線程。注意,把文本追加到JTextArea之后,程序小心地保證了插入點的正確位置。
一 般來說,Swing部件的更新不應該在AWT事件分派線程(AWT Event Dispatch Thread,AEDT)之外進行。對于本例來說,這意味著所有把文本追加到JTextArea的操作應該在AEDT中進行,而不是在 startConsoleReaderThread()方法創建的線程中進行。然而,事實上在Swing中向JTextArea追加文本是一個線程安全的 操作。讀取一行文本之后,我們只需調用JText.append()就可以把文本追加到JTextArea的末尾。
![]() ![]() |
![]()
|
在JTextArea中捕獲Java程序自己的控制臺輸出是一回事,去捕獲其他程序(甚至包括一些非Java程序)的控制臺數據又是另一回事。ConsoleTextArea提供了捕獲其他應用的輸出時需要的基礎功能,Listing 6的AppOutputCapture利用ConsoleTextArea,截取其他應用的輸出信息然后顯示在ConsoleTextArea中。
【Listing 6:截獲其他程序的控制臺輸出】 |
AppOutputCapture的工作過程如下:首先利用Runtime.exec()方法啟動指定程序的一個新進程。啟動新進程之后,從結果 Process對象得到它的控制臺流。之后,把這些控制臺流傳入ConsoleTextArea(InputStream[])構造函數(這就是帶參數 ConsoleTextArea構造函數的用處)。使用AppOutputCapture時,在命令行上指定待截取其輸出的程序名字。例如,如果在 Windows 2000下執行javaw.exe AppOutputCapture ping.exe www.yahoo.com,則結果如圖四所示。
圖四:截取其他程序的控制臺輸出

使用AppOutputCapture時應該注意,被截取輸出的應用程序最初輸出的一些文本可能無法截取。因為在調用Runtime.exec()和 ConsoleTextArea初始化完成之間存在一小段時間差。在這個時間差內,應用程序輸出的文本會丟失。當AppOutputCapture窗口被 關閉,process.destory()調用試圖關閉Java程序開始時創建的進程。測試結果顯示出,destroy()方法不一定總是有效(至少在 Windows 98上是這樣的)。似乎當待關閉的進程啟動了額外的進程時,則那些進程不會被關閉。此外,在這種情況下AppOutputCapture程序看起來未能正 常結束。但在Windows NT下,一切正常。如果用JDK v1.1.x運行AppOutputCapture,關閉窗口時會出現一個NullPointerException。這是一個JDK的Bug,JDK 1.2.x和JDK 1.3.x下就不會出現問題。