一、線程概述

線程是程序運行的基本執(zhí)行單元。當(dāng)操作系統(tǒng)(不包括單線程的操作系統(tǒng)，如微軟早期的DOS)在執(zhí)行一個程序時，會在系統(tǒng)中建立一個進程，而在這個進程中，必須至少建立一個線程（這個線程被稱為主線程）來作為這個程序運行的入口點。因此，在操作系統(tǒng)中運行的任何程序都至少有一個主線程。
進程和線程是現(xiàn)代操作系統(tǒng)中兩個必不可少的運行模型。在操作系統(tǒng)中可以有多個進程，這些進程包括系統(tǒng)進程（由操作系統(tǒng)內(nèi)部建立的進程）和用戶進程（由用戶程序建立的進程）；一個進程中可以有一個或多個線程。進程和進程之間不共享內(nèi)存，也就是說系統(tǒng)中的進程是在各自獨立的內(nèi)存空間中運行的。而一個進程中的線可以共享系統(tǒng)分派給這個進程的內(nèi)存空間。
線程不僅可以共享進程的內(nèi)存，而且還擁有一個屬于自己的內(nèi)存空間，這段內(nèi)存空間也叫做線程棧, 是在建立線程時由系統(tǒng)分配的，主要用來保存線程內(nèi)部所使用的數(shù)據(jù)，如線程執(zhí)行函數(shù)中所定義的變量。
注意：任何一個線程在建立時都會執(zhí)行一個函數(shù)，這個函數(shù)叫做線程執(zhí)行函數(shù)。也可以將這個函數(shù)看做線程的入口點（類似于程序中的main函數(shù)）。無論使用什么語言或技術(shù)來建立線程，都必須執(zhí)行這個函數(shù)（這個函數(shù)的表現(xiàn)形式可能不一樣，但都會有一個這樣的函數(shù)）。如在Windows中用于建立線程的API函數(shù)CreateThread的第三個參數(shù)就是這個執(zhí)行函數(shù)的指針。
在操作系統(tǒng)將進程分成多個線程后，這些線程可以在操作系統(tǒng)的管理下并發(fā)執(zhí)行，從而大大提高了程序的運行效率。雖然線程的執(zhí)行從宏觀上看是多個線程同時執(zhí)行，但實際上這只是操作系統(tǒng)的障眼法。由于一塊CPU同時只能執(zhí)行一條指令，因此，在擁有一塊CPU的計算機上不可能同時執(zhí)行兩個任務(wù)。而操作系統(tǒng)為了能提高程序的運行效率，在一個線程空閑時會撤下這個線程，并且會讓其他的線程來執(zhí)行，這種方式叫做線程調(diào)度。我們之所以從表面上看是多個線程同時執(zhí)行，是因為不同線程之間切換的時間非常短，而且在一般情況下切換非常頻繁。假設(shè)我們有線程A和B。在運行時，可能是A執(zhí)行了1毫秒后，切換到B后，B又執(zhí)行了1毫秒，然后又切換到了A，A又執(zhí)行1毫秒。由于1毫秒的時間對于普通人來說是很難感知的，因此，從表面看上去就象A和B同時執(zhí)行一樣，但實際上A和B是交替執(zhí)行的。

二、線程給我們帶來的好處

如果能合理地使用線程，將會減少開發(fā)和維護成本，甚至可以改善復(fù)雜應(yīng)用程序的性能。如在GUI應(yīng)用程序中，還以通過線程的異步特性來更好地處理事件；在應(yīng)用服務(wù)器程序中可以通過建立多個線程來處理客戶端的請求。線程甚至還可以簡化虛擬機的實現(xiàn)，如Java虛擬機(JVM)的垃圾回收器（garbage collector）通常運行在一個或多個線程中。因此，使用線程將會從以下五個方面來改善我們的應(yīng)用程序：

1. 充分利用CPU資源
現(xiàn)在世界上大多數(shù)計算機只有一塊CPU。因此，充分利用CPU資源顯得尤為重要。當(dāng)執(zhí)行單線程程序時，由于在程序發(fā)生阻塞時CPU可能會處于空閑狀態(tài)。這將造成大量的計算資源的浪費。而在程序中使用多線程可以在某一個線程處于休眠或阻塞時，而CPU又恰好處于空閑狀態(tài)時來運行其他的線程。這樣CPU就很難有空閑的時候。因此，CPU資源就得到了充分地利用。

2.   簡化編程模型
如果程序只完成一項任務(wù)，那只要寫一個單線程的程序，并且按著執(zhí)行這個任務(wù)的步驟編寫代碼即可。但要完成多項任務(wù)，如果還使用單線程的話，那就得在在程序中判斷每項任務(wù)是否應(yīng)該執(zhí)行以及什么時候執(zhí)行。如顯示一個時鐘的時、分、秒三個指針。使用單線程就得在循環(huán)中逐一判斷這三個指針的轉(zhuǎn)動時間和角度。如果使用三個線程分另來處理這三個指針的顯示，那么對于每個線程來說就是指行一個單獨的任務(wù)。這樣有助于開發(fā)人員對程序的理解和維護。

3.   簡化異步事件的處理
當(dāng)一個服務(wù)器應(yīng)用程序在接收不同的客戶端連接時最簡單地處理方法就是為每一個客戶端連接建立一個線程。然后監(jiān)聽線程仍然負(fù)責(zé)監(jiān)聽來自客戶端的請求。如果這種應(yīng)用程序采用單線程來處理，當(dāng)監(jiān)聽線程接收到一個客戶端請求后，開始讀取客戶端發(fā)來的數(shù)據(jù)，在讀完數(shù)據(jù)后，read方法處于阻塞狀態(tài)，也就是說，這個線程將無法再監(jiān)聽客戶端請求了。而要想在單線程中處理多個客戶端請求，就必須使用非阻塞的Socket連接和異步I/O。但使用異步I/O方式比使用同步I/O更難以控制，也更容易出錯。因此，使用多線程和同步I/O可以更容易地處理類似于多請求的異步事件。

4.   使GUI更有效率
使用單線程來處理GUI事件時，必須使用循環(huán)來對隨時可能發(fā)生的GUI事件進行掃描，在循環(huán)內(nèi)部除了掃描GUI事件外，還得來執(zhí)行其他的程序代碼。如果這些代碼太長，那么GUI事件就會被“凍結(jié)”，直到這些代碼被執(zhí)行完為止。
在現(xiàn)代的GUI框架（如SWING、AWT和SWT）中都使用了一個單獨的事件分派線程（event dispatch thread，EDT）來對GUI事件進行掃描。當(dāng)我們按下一個按鈕時，按鈕的單擊事件函數(shù)會在這個事件分派線程中被調(diào)用。由于EDT的任務(wù)只是對GUI事件進行掃描，因此，這種方式對事件的反映是非?？斓摹?/P>

5.   節(jié)約成本
提高程序的執(zhí)行效率一般有三種方法：
（1）增加計算機的CPU個數(shù)。
（2）為一個程序啟動多個進程
（3）在程序中使用多進程。
第一種方法是最容易做到的，但同時也是最昂貴的。這種方法不需要修改程序，從理論上說，任何程序都可以使用這種方法來提高執(zhí)行效率。第二種方法雖然不用購買新的硬件，但這種方式不容易共享數(shù)據(jù)，如果這個程序要完成的任務(wù)需要必須要共享數(shù)據(jù)的話，這種方式就不太方便，而且啟動多個線程會消耗大量的系統(tǒng)資源。第三種方法恰好彌補了第一種方法的缺點，而又繼承了它們的優(yōu)點。也就是說，既不需要購買CPU，也不會因為啟太多的線程而占用大量的系統(tǒng)資源（在默認(rèn)情況下，一個線程所占的內(nèi)存空間要遠比一個進程所占的內(nèi)存空間小得多），并且多線程可以模擬多塊CPU的運行方式，因此，使用多線程是提高程序執(zhí)行效率的最廉價的方式。

三、Java的線程模型
由于Java是純面向?qū)ο笳Z言，因此，Java的線程模型也是面向?qū)ο蟮摹ava通過Thread類將線程所必須的功能都封裝了起來。要想建立一個線程，必須要有一個線程執(zhí)行函數(shù)，這個線程執(zhí)行函數(shù)對應(yīng)Thread類的run方法。Thread類還有一個start方法，這個方法負(fù)責(zé)建立線程，相當(dāng)于調(diào)用Windows的建立線程函數(shù)CreateThread。當(dāng)調(diào)用start方法后，如果線程建立成功，并自動調(diào)用Thread類的run方法。因此，任何繼承Thread的Java類都可以通過Thread類的start方法來建立線程。如果想運行自己的線程執(zhí)行函數(shù)，那就要覆蓋Thread類的run方法。
在Java的線程模型中除了Thread類，還有一個標(biāo)識某個Java類是否可作為線程類的接口Runnable，這個接口只有一個抽象方法run，也就是Java線程模型的線程執(zhí)行函數(shù)。因此，一個線程類的唯一標(biāo)準(zhǔn)就是這個類是否實現(xiàn)了Runnable接口的run方法，也就是說，擁有線程執(zhí)行函數(shù)的類就是線程類。
從上面可以看出，在Java中建立線程有兩種方法，一種是繼承Thread類，另一種是實現(xiàn)Runnable接口，并通過Thread和實現(xiàn)Runnable的類來建立線程，其實這兩種方法從本質(zhì)上說是一種方法，即都是通過Thread類來建立線程，并運行run方法的。但它們的大區(qū)別是通過繼承Thread類來建立線程，雖然在實現(xiàn)起來更容易，但由于Java不支持多繼承，因此，這個線程類如果繼承了Thread，就不能再繼承其他的類了，因此，Java線程模型提供了通過實現(xiàn)Runnable接口的方法來建立線程，這樣線程類可以在必要的時候繼承和業(yè)務(wù)有關(guān)的類，而不是Thread類。

最新評論