異步、多線程、任務(wù)、并行編程之一：選擇合適的多線程模型

異步、多線程、任務(wù)、并行編程之一：選擇合適的多線程模型

本篇概述：

@FCL4.0中已經(jīng)存在的線程模型，以及它們之間異同點(diǎn)；

@多線程編程模型的選擇。

1：異步、多線程、任務(wù)、并行的本質(zhì)

這四個(gè)概念對(duì)應(yīng)在CLR中的本質(zhì)，本質(zhì)都是多線程。

異步，簡(jiǎn)單的講就是BeginInvoke、EndInvoke模式，它在CLR內(nèi)部線程池進(jìn)行管理；

多線程，體現(xiàn)在C#中，可以由類(lèi)型Thread發(fā)起。也可以由ThreadPool發(fā)起。前者不受CLR線程池管理，后者則是。FCL團(tuán)隊(duì)為了各種編程模型的方便，還另外提供了BackgroundWorker和若干個(gè)Timer，基本上它們都是ThreadPool的加強(qiáng)，增加了一些和調(diào)用者線程的交互功能；

任務(wù)（Task），為FCL4.0新增的功能，在一個(gè)稱(chēng)之為任務(wù)并行庫(kù)（TPL）的地方，其實(shí)也就是System.Threading.Tasks命名空間下。任務(wù)并行庫(kù)名字取的很玄乎，其實(shí)它也是CLR線程池的加強(qiáng)。優(yōu)化了線程間的調(diào)度算法，增加了和調(diào)用者線程的交互功能；

并行（Parallel），為FCL4.0新增的功能，也屬于TPL。并行在后臺(tái)使用Task進(jìn)行管理，說(shuō)白了，因?yàn)門(mén)ask使用的線程池線程，所以Parallel自然使用的也是線程池線程進(jìn)行管理，它的本質(zhì)僅僅是進(jìn)一步簡(jiǎn)化了Task。在這里要增進(jìn)一個(gè)對(duì)于并行的理解。實(shí)際上，多線程天然就是并行的。及時(shí)不用任務(wù)并行庫(kù)，用Thread類(lèi)型新起兩個(gè)線程，CLR或者說(shuō)Windows系統(tǒng)也會(huì)將這兩個(gè)線程根據(jù)需要安排到兩個(gè)CPU上去執(zhí)行。所以，并不是因?yàn)槎嗔巳蝿?wù)并行庫(kù)，CLR才支持并行計(jì)算，任務(wù)并行庫(kù)只是提供了一組API，使我們能夠更好的操縱線程進(jìn)行并行開(kāi)發(fā)而已。

2：遺憾

Jeffrey Richter大叔說(shuō)，微軟提供了這么多線程模型，是遺憾的，因?yàn)檫@制造了混亂。很多開(kāi)發(fā)者都不知道該選用哪個(gè)類(lèi)型來(lái)編寫(xiě)自己的多線程代碼。我們對(duì)微軟總是又愛(ài)又恨，它總是不停的更新一些東西，逼迫我們不停的學(xué)習(xí)。但是也好，進(jìn)步導(dǎo)致它不會(huì)過(guò)早死掉，讓我們徹底失掉飯碗。

C#剛出來(lái)的被人笑，現(xiàn)在它的很多語(yǔ)法特性已經(jīng)比Java優(yōu)美。很多時(shí)候我們太擅長(zhǎng)于嘲笑，以致最后只能哭。順便說(shuō)一句，我依然是那么的喜歡JAVA，只是很久沒(méi)用它而已。

3：現(xiàn)在，該用什么來(lái)編寫(xiě)多線程

如果你在FRAMEWORK4.0下編寫(xiě)代碼，那么應(yīng)該按照這個(gè)優(yōu)先級(jí)來(lái)撰寫(xiě)多線程代碼：

優(yōu)先

次優(yōu)先

不得以

Parallel（含擴(kuò)展庫(kù)PLinq）

Task

ThreadPool（BackgroundWorker，Timer）

異步

Thread

這個(gè)表滿足了大部分情況下的一個(gè)優(yōu)先級(jí)指導(dǎo)，但在某些情況下會(huì)有例外。

3.1：為什么 Parallel和Task優(yōu)先級(jí)一樣，而不是優(yōu)于Task？

Parallel雖然在后臺(tái)使用Task進(jìn)行管理，并且它所謂簡(jiǎn)化了對(duì)于Task的操作，但是它有一個(gè)重要的特征區(qū)別與Task：Parallel會(huì)阻滯調(diào)用者線程。查看Paralle的成員，有For、ForEach、Invoke方法，它甚至都沒(méi)提供一個(gè)BeginInvoke方法，也很好的暗示了這一點(diǎn)。不過(guò)雖然是同步的執(zhí)行的，Parallel還是會(huì)把多個(gè)任務(wù)分配到多個(gè)CPU上去。

Task被用的最多的是Start方法，它不會(huì)阻滯主線程。雖然Task也提供了同步的啟動(dòng)線程的方法RunSynchronously，但一般用的不多。

3.2：何時(shí)用異步，何時(shí)用線程或線程池

這需要從“IO操作的DMA（Direct Memory Access）模式”講起。通過(guò)DMA的數(shù)據(jù)交換幾乎可以不損耗CPU的資源。在硬件部分，硬盤(pán)、網(wǎng)卡、聲卡、顯卡等都有DMA功能。可以簡(jiǎn)單的認(rèn)為，當(dāng)我們的工作線程需要操作I/O資源的時(shí)候（如讀取一個(gè)大文件、讀取一個(gè)網(wǎng)頁(yè)、讀取Socke包等），我們就需要用異步去做這些事情。異步模式只會(huì)在工作開(kāi)始以及工作結(jié)束的時(shí)候占用CLR線程池，其它時(shí)候由硬盤(pán)、網(wǎng)卡等硬件設(shè)備來(lái)處理具體的工作，這就不會(huì)過(guò)多占用到CPU空間和時(shí)間損耗。

概括而言：

計(jì)算密集型工作，直接采用線程；

IO密集型工作，采用異步機(jī)制；

當(dāng)我們不清楚什么工作是I/O密集型的，一個(gè)不是很恰當(dāng)?shù)闹笇?dǎo)就是：查看FCL類(lèi)型成員，如果成員提供了類(lèi)似BeginDosomething方法的，則優(yōu)先使用它，而不是新起一個(gè)線程或丟到線程池。

3.3：線程池的優(yōu)勢(shì)

新起線程，會(huì)帶來(lái)很大的開(kāi)銷(xiāo)，這些開(kāi)銷(xiāo)主要集中在：分配線程內(nèi)核對(duì)象、線程環(huán)境塊、用戶(hù)模式棧、內(nèi)核模式棧所需要的內(nèi)存空間，加載的DLL的DLLMain方法，并傳遞連接標(biāo)志，以及線程上下文切換。由于線程如此昂貴，所以對(duì)于普通的開(kāi)發(fā)要求來(lái)說(shuō)，線程池就是一個(gè)很好的選擇。線程池替開(kāi)發(fā)人員管理工作線程，當(dāng)一項(xiàng)工作完畢的時(shí)候，CLR不會(huì)銷(xiāo)毀這個(gè)線程，而是會(huì)保留這個(gè)線程一段時(shí)間，看是否有別的工作需要這個(gè)線程。至于何時(shí)銷(xiāo)毀或新起線程，由CLR決定。

3.4：何時(shí)用Thread

以上的各種線程模型，它們最終都是Thread。 那么什么時(shí)候需要Thread直接出場(chǎng)呢？

最重要的使用Thread的理由是，我們需要控制線程的優(yōu)先級(jí)。Thread之上的線程模型都不支持優(yōu)先級(jí)設(shè)置。設(shè)置一個(gè)線程的高優(yōu)先級(jí)可以使它獲得更多的CPU時(shí)間；

再者，可以控制線程為前臺(tái)線程。當(dāng)然，由Thread新起的線程默認(rèn)就是前臺(tái)線程。前臺(tái)線程不隨著調(diào)用者線程的中斷而中斷，這使得我們可以用Thread來(lái)進(jìn)行一些關(guān)鍵性的操作。

任務(wù)調(diào)度

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶(hù)投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。