在Java語言產生前 傳統的程序設計語言的程序同壹時刻只能單任務操作 效率非常低 例如程序往往在接收數據輸入時發生阻塞 只有等到程序獲得數據後才能繼續運行 隨著Internet的迅猛發展 這種狀況越來越不能讓人們忍受 如果網絡接收數據阻塞 後臺程序就處於等待狀態而不繼續任何操作 而這種阻塞是經常會碰到的 此時CPU資源被白白的閑置起來 如果在後臺程序中能夠同時處理多個任務 該多好啊！應Internet技術而生的Java語言解決了這個問題 多線程程序是Java語言的壹個很重要的特點 在壹個Java程序中 我們可以同時並行運行多個相對獨立的線程 例如 我們如果創建壹個線程來進行數據輸入輸出 而創建另壹個線程在後臺進行其它的數據處理 如果輸入輸出線程在接收數據時阻塞 而處理數據的線程仍然在運行 多線程程序設計大大提高了程序執行效率和處理能力
線程的創建
我們知道Java是面向對象的程序語言 用Java進行程序設計就是設計和使用類 Java為我們提供了線程類Thread來創建線程 創建線程與創建普通的類的對象的操作是壹樣的 而線程就是Thread類或其子類的實例對象 下面是壹個創建啟動壹個線程的語句
Thread thread =new Thread(); file://聲明壹個對象實例 即創建壹個線程
Thread run(); file://用Thread類中的run()方法啟動線程
從這個例子 我們可以通過Thread（）構造方法創建壹個線程 並啟動該線程 事實上 啟動線程 也就是啟動線程的run（）方法 而Thread類中的run（）方法沒有任何操作語句 所以這個線程沒有任何操作 要使線程實現預定功能 必須定義自己的run（）方法 Java中通常有兩種方式定義run（）方法
通過定義壹個Thread類的子類 在該子類中重寫run（）方法 Thread子類的實例對象就是壹個線程 顯然 該線程有我們自己設計的線程體run（）方法 啟動線程就啟動了子類中重寫的run（）方法
通過Runnable接口 在該接口中定義run（）方法的接口 所謂接口跟類非常類似 主要用來實現特殊功能 如復雜關系的多重繼承功能 在此 我們定義壹個實現Runnable（） 接口的類 在該類中定義自己的run（）方法 然後以該類的實例對象為參數調用Thread類的構造方法來創建壹個線程
線程被實際創建後處於待命狀態 激活（啟動）線程就是啟動線程的run（）方法 這是通過調用線程的start（）方法來實現的
下面壹個例子實踐了如何通過上述兩種方法創建線程並啟動它們
// 通過Thread類的子類創建的線程 class thread extends Thread { file://自定義線程的run()方法 public void run() { System out println( Thread is running… ); } } file://通過Runnable接口創建的另外壹個線程 class thread implements Runnable { file://自定義線程的run()方法 public void run() { System out println( Thread is running… ); } } file://程序的主類 class Multi_Thread file://聲明主類 { plubic static void mail(String args[]) file://聲明主方法 { thread threadone=new thread (); file://用Thread類的子類創建線程 Thread threado=new Thread(new thread ()); file://用Runnable接口類的對象創建線程 threadone start(); threado start(); file://strat()方法啟動線程 } }
運行該程序就可以看出 線程threadone和threado交替占用CPU 處於並行運行狀態 可以看出 啟動線程的run()方法是通過調用線程的start()方法來實現的(見上例中主類) 調用start()方法啟動線程的run()方法不同於壹般的調用方法 調用壹般方法時 必須等到壹般方法執行完畢才能夠返回start()方法 而啟動線程的run()方法後 start()告訴系統該線程準備就緒可以啟動run()方法後 就返回start()方法執行調用start()方法語句下面的語句 這時run()方法可能還在運行 這樣 線程的啟動和運行並行進行 實現了多任務操作
線程的優先級
對於多線程程序 每個線程的重要程度是不盡相同 如多個線程在等待獲得CPU時間時 往往我們需要優先級高的線程優先搶占到CPU時間得以執行 又如多個線程交替執行時 優先級決定了級別高的線程得到CPU的次數多壹些且時間多長壹些 這樣 高優先級的線程處理的任務效率就高壹些
Java中線程的優先級從低到高以整數 ~ 表示 ***分為 級 設置優先級是通過調用線程對象的setPriority()方法 如上例中 設置優先級的語句為
thread threadone=new thread (); file://用Thread類的子類創建線程
Thread threado=new Thread(new thread ()); file://用Runnable接口類的對象創建線程
threadone setPriority( ); file://設置threadone的優先級
threado setPriority( ); file://設置threado的優先級
threadone start(); threado start(); file://strat()方法啟動線程
這樣 線程threadone將會優先於線程threado執行 並將占有更多的CPU時間 該例中 優先級設置放在線程啟動前 也可以在啟動後進行設置 以滿足不同的優先級需求
線程的（同步）控制
壹個Java程序的多線程之間可以***享數據 當線程以異步方式訪問***享數據時 有時候是不安全的或者不和邏輯的 比如 同壹時刻壹個線程在讀取數據 另外壹個線程在處理數據 當處理數據的線程沒有等到讀取數據的線程讀取完畢就去處理數據 必然得到錯誤的處理結果 這和我們前面提到的讀取數據和處理數據並行多任務並不矛盾 這兒指的是處理數據的線程不能處理當前還沒有讀取結束的數據 但是可以處理其它的數據
如果我們采用多線程同步控制機制 等到第壹個線程讀取完數據 第二個線程才能處理該數據 就會避免錯誤 可見 線程同步是多線程編程的壹個相當重要的技術
在講線程的同步控制前我們需要交代如下概念
用Java關鍵字synchonized同步對***享數據操作的方法
在壹個對象中 用synchonized聲明的方法為同步方法 Java中有壹個同步模型 監視器 負責管理線程對對象中的同步方法的訪問 它的原理是 賦予該對象唯壹壹把 鑰匙 當多個線程進入對象 只有取得該對象鑰匙的線程才可以訪問同步方法 其它線程在該對象中等待 直到該線程用wait（）方法放棄這把鑰匙 其它等待的線程搶占該鑰匙 搶占到鑰匙的線程後才可得以執行 而沒有取得鑰匙的線程仍被阻塞在該對象中等待
file://聲明同步的壹種方式 將方法聲明同步
class store {public synchonized void store_in(){… }public synchonized void store_out(){ … }}
? 利用wait（） notify（）及notifyAll（）方法發送消息實現線程間的相互聯系
Java程序中多個線程通過消息來實現互動聯系的 這幾種方法實現了線程間的消息發送 例如定義壹個對象的synchonized 方法 同壹時刻只能夠有壹個線程訪問該對象中的同步方法 其它線程被阻塞 通常可以用notify（）或notifyAll（）方法喚醒其它壹個或所有線程 而使用wait（）方法來使該線程處於阻塞狀態 等待其它的線程用notify（）喚醒
壹個實際的例子就是生產和銷售 生產單元將產品生產出來放在倉庫中 銷售單元則從倉庫中提走產品 在這個過程中 銷售單元必須在倉庫中有產品時才能提貨 如果倉庫中沒有產品 則銷售單元必須等待
程序中 假如我們定義壹個倉庫類store 該類的實例對象就相當於倉庫 在store類中定義兩個成員方法 store_in（） 用來模擬產品制造者往倉庫中添加產品 strore_out（）方法則用來模擬銷售者從倉庫中取走產品 然後定義兩個線程類 customer類 其中的run（）方法通過調用倉庫類中的store_out（）從倉庫中取走產品 模擬銷售者 另外壹個線程類producer中的run（）方法通過調用倉庫類中的store_in（）方法向倉庫添加產品 模擬產品制造者 在主類中創建並啟動線程 實現向倉庫中添加產品或取走產品
如果倉庫類中的store_in（） 和store_out（）方法不聲明同步 這就是個壹般的多線程 我們知道 壹個程序中的多線程是交替執行的 運行也是無序的 這樣 就可能存在這樣的問題
倉庫中沒有產品了 銷售者還在不斷光顧 而且還不停的在 取 產品 這在現實中是不可思義的 在程序中就表現為負值 如果將倉庫類中的stroe_in（）和store_out（）方法聲明同步 如上例所示 就控制了同壹時刻只能有壹個線程訪問倉庫對象中的同步方法 即壹個生產類線程訪問被聲明為同步的store_in（）方法時 其它線程將不能夠訪問對象中的store_out（）同步方法 當然也不能訪問store_in（）方法 必須等到該線程調用wait（）方法放棄鑰匙 其它線程才有機會訪問同步方法
lishixinzhi/Article/program/Java/gj/201311/27301