後台線程的突然結束
當所有的非後台線程終止後後台線程都被突然結束當後台線程創建了一些全局資源（例如一個數據庫連接或一個臨時文件）而後台線程結束時這些資源沒有被關閉或刪除就會導致問題
對於這個問題我建議制定規則使 Java 虛擬機在下列情況下不關閉應用程序有任何非後台線程正在運行或者 有任何後台線程正在執行一個 synchronized 方法或 synchronized 代碼塊
後台線程在它執行完synchronized 塊或 synchronized 方法後可被立即關閉
重新引入stop（） suspend（） 和 resume（） 關鍵字
由於實用原因這也許不可行但是我希望不要廢除stop（） （在 Thread 和 ThreadGroup 中）但是我會改變 stop（） 的語義使得調用它時不會破壞已有代碼但是關於 stop（） 的問題請記住當線程終止後 stop（） 將釋放所有鎖這樣可能潛在地使正在此對象上工作的線程進入一種不穩定（局部修改）的狀態由於停止的線程已釋放它在此對象上的所有鎖所以這些對象無法再被訪問
對於這個問題可以重新定義stop（） 的行為使線程只有在不占有任何鎖時才立即終止如果它占據著鎖我建議在此線程釋放最後一個鎖後才終止它可以使用一個和拋出異常相似的機制來實現此行為被停止線程應設置一個標志並且當退出所有同步塊時立即測試此標志如果設置了此標志就拋出一個隱式的異常但是此異常應不再能被捕捉並且當線程結束時不會產生任何輸出注意微軟的 NT 操作系統不能很好地處理一個外部指示的突然停止（abrupt）（它不把 stop 消息通知動態連接庫所以可能導致系統級的資源漏洞）這就是我建議使用類似異常的方法簡單地導致 run（） 返回的原因
與這種和異常類似的處理方法帶來的實際問題是你必需在每個synchronized 塊後都插入代碼來測試stopped標志並且這種附加的代碼會降低系統性能並增加代碼長度我想到的另外一個辦法是使 stop（） 實現一個延遲的（lazy）停止在這種情況下在下次調用 wait（） 或 yield（） 時才終止我還想向 Thread 中加入一個 isStopped（） 和 stopped（） 方法（此時 Thread 將像 isInterrupted（） 和 interrupted（） 一樣工作但是會檢測 stoprequested的狀態）這種方法不向第一種那樣通用但是可行並且不會產生過載
應把suspend（） 和 resume（） 方法放回到 Java 編程語言中它們是很有用的我不想被當成是幼兒園的小孩由於它們可能產生潛在的危險（當被掛起時一個線程可以占據一個鎖）而去掉它們是沒有道理的請讓我自己來決定是否使用它們如果接收的線程正占據著鎖Sun 公司應該把它們作為調用 suspend（） 的一個運行時間異常處理（runtime exception）或者更好的方法是延遲實際的掛起過程直到線程釋放所有的鎖
被阻斷的 I/O 應正確工作
應該能打斷任何被阻斷的操作而不是只讓它們wait（） 和 sleep（） 我在 Taming Java Threads 的第二章中的 socket 部分討論了此問題但是現在對於一個被阻斷的 socket 上的 I/O 操作打斷它的唯一辦法是關閉這個 socket而沒有辦法打斷一個被阻斷的文件 I/O 操作例如一旦開始一個讀請求並且進入阻斷狀態後除非到它實際讀出一些東西否則線程一直出於阻斷狀態既使關掉文件句柄也不能打斷讀操作
還有程序應支持 I/O 操作的超時所有可能出現阻斷操作的對象（例如 InputStream 對象）也都應支持這種方法
這和 Socket 類的setSoTimeout（time） 方法是等價的同樣地應該支持把超時作為參數傳遞到阻斷的調用
ThreadGroup類
ThreadGroup應該實現 Thread 中能夠改變線程狀態的所有方法我特別想讓它實現 join（） 方法這樣我就可等待組中的所有線程的終止
總結
以上是我的建議就像我在標題中所說的那樣如果我是國王我希望這些改變（或其它等同的方法）最終能被引入 Java 語言中我確實認為 Java 語言是一種偉大的編程語言但是我也認為 Java 的線程模型設計得還不夠完善這是一件很可惜的事情但是Java 編程語言正在演變所以還有可提高的前景
[] [] [] [] [] [] []
From:http://tw.wingwit.com/Article/program/Java/gj/201311/27689.html
