內容: 如果我是國王：關于解決 Java 編程語言線程問題的建議Allen Holub自由撰稿人 內容： task(任務) 的概念 synchronized 關鍵字 wait 和 notify 方法 修定 thread 類 線程間的協作 讀寫鎖 部分創建的對象 volatile 關鍵字 訪問的問題 后臺程序的突然結束 重新引入 stop、suspend 和 resume 被阻斷的 I/O threadGroup 類 總結 參考資料 作者簡介 Allen Holub 指出，Java 編程語言的線程模型可能是此語言中最薄弱的部分。它完全不適合實際復雜程序的要求，而且也完全不是面向對象的。本文建議對 Java 語言進行重大修改和補充，以解決這些問題。Java 語言的線程模型是此語言的一個最難另人滿意的部分。盡管 Java 語言本身就支持線程編程是件好事，但是它對線程的語法和類包的支持太少，只能適用于極小型的應用環境。關于 Java 線程編程的大多數書籍都長篇累牘地指出了 Java 線程模型的缺陷，并提供了解決這些問題的急救包(Band-Aid/邦迪創可貼)類庫。我稱這些類為急救包，是因為它們所能解決的問題本應是由 Java 語言本身語法所包含的。從長遠來看，以語法而不是類庫方法，將能產生更高效的代碼。這是因為編譯器和 Java 虛擬器 (JVM) 能一同優化程序代碼，而這些優化對于類庫中的代碼是很難或無法實現的。在我的《Taming Java Threads》（請參閱參考資料）書中以及本文中，我進一步建議對 Java 編程語言本身進行一些修改，以使得它能夠真正解決這些線程編程的問題。本文和我這本書的主要區別是，我在撰寫本文時進行了更多的思考, 所以對書中的提議加以了提高。這些建議只是嘗試性的 -- 只是我個人對這些問題的想法，而且實現這些想法需要進行大量的工作以及同行們的評價。但這是畢竟是一個開端，我有意為解決這些問題成立一個專門的工作組，如果您感興趣，請發 e-mail 到 threading@holub.com。一旦我真正著手進行，我就會給您發通知。這里提出的建議是非常大膽的。有些人建議對 Java 語言規范 (JLS)（請參閱參考資料）進行細微和少量的修改以解決當前模糊的 JVM 行為，但是我卻想對其進行更為徹底的改進。在實際草稿中，我的許多建議包括為此語言引入新的關鍵字。雖然通常要求不要突破一個語言的現有代碼是正確的，但是如果該語言的并不是要保持不變以至于過時的話，它就必須能引入新的關鍵字。為了使引入的關鍵字與現有的標識符不產生沖突，經過細心考慮，我將使用一個 ($) 字符，而這個字符在現有的標識符中是非法的。(例如，使用 $task， 而不是 task)。此時需要編譯器的命令行開關提供支持，能使用這些關鍵字的變體，而不是忽略這個美元符號。task（任務）的概念 Java 線程模型的根本問題是它完全不是面向對象的。面向對象 (OO) 設計人員根本不按線程角度考慮問題；他們考慮的是同步信息異步信息（同步信息被立即處理 -- 直到信息處理完成才返回消息句柄；異步信息收到后將在后臺處理一段時間-- 而早在信息處理結束前就返回消息句柄）。Java 編程語言中的 Toolkit.getImage() 方法就是異步信息的一個好例子。getImage() 的消息句柄將被立即返回，而不必等到整個圖像被后臺線程取回。這是面向對象 (OO) 的處理方法。但是，如前所述，Java 的線程模型是非面向對象的。一個 Java 編程語言線程實際上只是一個 run() 過程，它調用了其它的過程。在這里就根本沒有對象、異步或同步信息以及其它概念。對于此問題，在我的書中深入討論過的一個解決方法是，使用一個 Active_object。 active 對象是可以接收異步請求的對象，它在接收到請求后的一段時間內以后臺方式得以處理。在 Java 編程語言中，一個請求可被封裝在一個對象中。例如，你可以把一個通過 Runnable接口實現的實例傳送給此 active 對象，該接口的 run() 方法封裝了需要完成的工作。該 runnable 對象被此 active 對象排入到隊列中，當輪到它執行時，active 對象使用一個后臺線程來執行它。在一個 active 對象上運行的異步信息實際上是同步的，因為它們被一個單一的服務線程按順序從隊列中取出并執行。因此，使用一個 active 對象以一種更為過程化的模型可以消除大多數的同步問題。在某種意義上，Java 編程語言的整個 Swing/AWT 子系統是一個 active 對象。向一個 Swing 隊列傳送一條訊息的唯一安全的途徑是，調用一個類似 SwingUtilities.invokeLater() 的方法，這樣就在 Swing 事件隊列上發送了一個 runnable 對象，當輪到它執行時， Swing 事件處理線程將會處理它。那么我的第一個建議是，向 Java 編程語言中加入一個 task（任務）的概念，從而將active 對象集成到語言中。( task的概念是從 Intel 的 RMX 操作系統和 Ada 編程語言借鑒過來的。大多數實時操作系統都支持類似的概念。）一個任務有一個內置的 active 對象分發程序，并自動管理那些處理異步信息的全部機制。定義一個任務和定義一個類基本相同，不同的只是需要在任務的方法前加一個 asynchronous 修飾符來指示 active 對象的分配程序在后臺處理這些方法。請參考我的書中第九章的基于類方法，再看以下的 file_io 類，它使用了在《Taming Java Threads》中所討論的 Active_object 類來實現異步寫操作： interface Exception_handler { void handle_exception( Throwable e ); } class File_io_task { Active_object dispatcher = new Active_object(); final OutputStream file; final Exception_handler handler; File_io_task( String file_name, Exception_handler handler ) throws IOException { file = new FileOutputStream( file_name ); this.handler = handler; } public void write( final byte[] bytes ) { // The following call asks the active-object dispatcher // to enqueue the Runnable object on its request // queue. A thread associated with the active object // dequeues the runnable objects and executes them // one at a time. dispatcher.dispatch ( new Runnable() { public void run() { try { byte[] copy new byte[ bytes.length ]; System.arrayCopy( bytes, 0, copy, 0, bytes.length ); file.write( copy ); } catch( Throwable problem ) { handler.handle_exception( problem ); } } } ); } } 所有的寫請求都用一個 dispatch() 過程調用被放在 active-object 的輸入隊列中排隊。在后臺處理這些異步信息時出現的任何異常 (exception) 都由 Exception_handler 對象處理，此 Exception_handler 對象被傳送到 File_io_task 的構造函數中。您要寫內容到文件時，代碼如下： File_io_task io = new File_io_task ( 'foo.txt' new Exception_handler { public void handle( Throwable e ){ e.printStackTrace();} } ); //... io.write( some_bytes ); 這種基于類的處理方法，其主要問題是太復雜了 -- 對于一個這樣簡單的操作，代碼太雜了。向 Java 語言引入 $task 和 $asynchronous 關鍵字后，就可以按下面這樣重寫以前的代碼： $task File_io $error{ $.printStackTrace(); } { OutputStream file; File_io( String file_name ) throws IOException { file = new FileOutputStream( file_name ); } asynchronous public write( byte[] bytes ) { file.write( bytes ); } } 注意，異步方法并沒有指定返回值，因為其句柄將被立即返回，而不用等到請求的操作處理完成后。所以，此時沒有合理的返回值。對于派生出的模型， $task 關鍵字和 class 一樣同效：$task 可以實現接口、繼承類和繼承的其它任務。標有 asynchronous 關鍵字的方法由$task 在后臺處理。其它的方法將同步運行，就像在類中一樣。$task 關鍵字可以用一個可選的 $error 從句修飾 (如上所示)， 它表明對任何無法被異步方法本身捕捉的異常將有一個缺省的處理程序。我使用 $ 來代表被拋出的異常對象。如果沒有指定 $error 從句，就將打印出一個合理的出錯信息（很可能是堆棧跟蹤信息）。注意，為確保線程安全，異步方法的參數必須是不變 (immutable) 的。運行時系統應通過相關語義來保證這種不變性（簡單的復制通常是不夠的）。所有的 task 對象必須支持一些偽信息 (pseudo-message)，例如： some_task.close() 在此調用后發送的任何異步信息都產生一個 TaskClosedException。但是，在 active 對象隊列上等候的消息仍能被提供。 some_task.join() 調用程序被阻斷，直到此任務關閉、而且所有未完成的請求都被處理完畢。 除了常用的修飾符（public 等)，task 關鍵字還應接受一個 $pooled(n) 修飾符，它導致 task 使用一個線程池，而不是使用單個線程來運行異步請求。n 指定了所需線程池的大小；必要時，此線程池可以增加，但是當不再需要線程時，它應該縮到原來的大小。偽域 (pseudo-field) $pool_size 返回在 $pooled(n) 中指定的原始 n 參數值。在《Taming Java Threads》的第八章中，我給出了一個服務器端的 socket 處理程序，作為線程池的例子。它是關于使用線程池的任務的一個好例子。其基本思路是產生一個獨立對象，它的任務是監控一個服務器端的 socket。每當一個客戶機連接到服務器時，服務器端的對象會從池中抓取一個預先創建的睡眠線程，并把此線程設置為服務于客戶端連接。socket 服務器會產出一個額外的客戶服務線程，但是當連接關閉時，這些額外的線程將被刪除。實現 socket 服務器的推薦語法如下： public $pooled(10) $task Client_handler { PrintWriter log = new PrintWriter( System.out ); public asynchronous void handle( Socket connection_to_the_client ) { log.println('writing'); // client-handling code goes here. Every call to // handle() is executed on its own thread, but 10 // threads are pre-created for this purpose. Additional // threads are created on an as-needed basis, but are // discarded when handle() returns. } } $task Socket_server { ServerSocket server; Client_handler client_handlers = new Client_handler(); public Socket_server( int port_number ) { server = new ServerSocket(port_number); } public $asynchronous listen(Client_handler client) { // This method is executed on its own thread. while( true ) { client_handlers.handle( server.accept() ); } } } //... Socket_server = new Socket_server( the_port_number ); server.listen() Socket_server 對象使用一個獨立的后臺線程處理異步的 listen() 請求，它封裝 socket 的“接受循環。當每個客戶端連接時，listen() 請求一個 Client_handler 通過調用 handle() 來處理請求。每個 handle() 請求在它們自己的線程中執行（因為這是一個 $pooled 任務)。注意，每個傳送到 $pooled $task 的異步消息實際上都使用它們自己的線程來處理。典型情況下，由于一個 $pooled $task 用于實現一個自主操作；所以對于解決與訪問狀態變量有關的潛在的同步問題，最好的解決方法是在 $asynchronous 方法中使用 this 是指向的對象的一個獨有副本。這就是說，當向一個 $pooled $task 發送一個異步請求時，將執行一個 clone() 操作，并且此方法的 this 指針會指向此克隆對象。線程之間的通信可通過對 static 區的同步訪問實現。改進 synchronized 雖然在多數情況下， $task 消除了同步操作的要求，但是不是所有的多線程系統都用任務來實現。所以，還需要改進現有的線程模塊。 synchronized 關鍵字有下列缺點：無法指定一個超時值。 無法中斷一個正在等待請求鎖的線程。 無法安全地請求多個鎖 。(多個鎖只能以依次序獲得。) 解決這些問題的辦法是：擴展 synchronized 的語法，使它支持多個參數和能接受一個超時說明（在下面的括弧中指定）。下面是我希望的語法： synchronized(x && y && z) 獲得 x、y 和 z 對象的鎖。 synchronized(x || y || z) 獲得 x、y 或 z 對象的鎖。 synchronized( (x && y ) || z) 對于前面代碼的一些擴展。 synchronized(...)[1000] 設置 1 秒超時以獲得一個鎖。 synchronized[1000] f(){...} 在進入 f() 函數時獲得 this 的鎖，但可有 1 秒超時。 TimeoutException 是 RuntimeException 派生類，它在等待超時后即被拋出。超時是需要的，但還不足以使代碼強壯。您還需要具備從外部中止請求鎖等待的能力。所以，當向一個等待鎖的線程傳送一個 interrupt() 方法后，此方法應拋出一個 SynchronizationException 對象，并中斷等待的線程。這個異常應是 RuntimeException 的一個派生類，這樣不必特別處理它。對 synchronized 語法這些推薦的更改方法的主要問題是，它們需要在二進制代碼級上修改。而目前這些代碼使用進入監控(enter-monitor)和退出監控(exit-monitor)指令來實現 synchronized。而這些指令沒有參數，所以需要擴展二進制代碼的定義以支持多個鎖定請求。但是這種修改不會比在 Java 2 中修改 Java 虛擬機的更輕松，但它是向下兼容現存的 Java 代碼。另一個可解決的問題是最常見的死鎖情況，在這種情況下，兩個線程都在等待對方完成某個操作。設想下面的一個例子（假設的）：class Broken{ Object lock1 = new Object(); Object lock2 = new Object(); void a() { synchronized( lock1 ) { synchronized( lock2 ) { // do something } } } void b() { synchronized( lock2 ) { synchronized( lock1 ) { // do something } } } 設想一個線程調用 a()，但在獲得　lock1之后在獲得 lock2 之前被剝奪運行權。第二個線程進入運行，調用 b()，獲得了 lock2，但是由于第一個線程占用 lock1，所以它無法獲得 lock1，所以它隨后處于等待狀態。此時第一個線程被喚醒，它試圖獲得 lock2，但是由于被第二個線程占據，所以無法獲得。此時出現死鎖。下面的 synchronize-on-multiple-objects 的語法可解決這個問題： //... void a() { synchronized( lock1 && lock2 ) { } } void b() { synchronized( lock2 && lock3 ) { } } 編譯器(或虛擬機)會重新排列請求鎖的順序，使 lock1 總是被首先獲得，這就消除了死鎖。但是，這種方法對多線程不一定總成功，所以得提供一些方法來自動打破死鎖。一個簡單的辦法就是在等待第二個鎖時常釋放已獲得的鎖。這就是說，應采取如下的等待方式，而不是永遠等待： while( true ) { try { synchronized( some_lock )[10] { // do the work here. break; } } catch( TimeoutException e ) { continue; } } 如果等待鎖的每個程序使用不同的超時值，就可打破死鎖而其中一個線程就可運行。我建議用以下的語法來取代前面的代碼： synchronized( some_lock )[] { // do the work here. } synchronized 語句將永遠等待，但是它時常會放棄已獲得的鎖以打破潛在的死鎖可能。在理想情況下，每個重復等待的超時值比前一個相差一隨機值。改進 wait() 和 notify() wait()/notify() 系統也有一些問題：無法檢測 wait() 是正常返回還是因超時返回。 無法使用傳統條件變量來實現處于一個“信號(signaled)狀態。 太容易發生嵌套的監控(monitor)鎖定。 超時檢測問題可以通過重新定義 wait() 使它返回一個 boolean 變量 (而不是 void ) 來解決。一個 true 返回值指示一個正常返回，而 false 指示因超時返回。基于狀態的條件變量的概念是很重要的。如果此變量被設置成 false 狀態，那么等待的線程將要被阻斷，直到此變量進入 true 狀態；任何等待 true 的條件變量的等待線程會被自動釋放。(在這種情況下，wait() 調用不會發生阻斷。)。通過如下擴展 notify() 的語法，可以支持這個功能： notify(); 釋放所有等待的線程，而不改變其下面的條件變量的狀態。 notify(true); 把條件變量的狀態設置為 true 并釋放任何等待的進程。其后對于 wait() 的調用不會發生阻斷。 notify(false); 把條件變量的狀態設置為 false (其后對于 wait() 的調用會發生阻斷)。 嵌套監控鎖定問題非常麻煩，我并沒有簡單的解決辦法。嵌套監控鎖定是一種死鎖形式，當某個鎖的占有線程在掛起其自身之前不釋放鎖時，會發生這種嵌套監控封鎖。下面是此問題的一個例子（還是假設的），但是實際的例子是非常多的：class Stack{ LinkedList list = new LinkedList(); public synchronized void push(Object x) { synchronized(list) { list.addLast( x ); notify(); } } public synchronized Object pop() { synchronized(list) { if( list.size()