如果你想異步地運(yùn)行函數(shù)doAsyncWork，你有兩個(gè)基本的選擇。你可以創(chuàng)建一個(gè)std::thread，用它來運(yùn)行doAsyncWork，這是基于線程（thread-based）的方法：

int?doAsyncWork();
std::thread?t(doAsyncWork);

或者你把doAsynWork傳遞給std::async，一個(gè)叫做基于任務(wù)（task-based）的策略：

auto?fut?=?std::async(doAsyncWork);????//?"fut"的意思是"future"

在這種調(diào)用中，傳遞給std::async的函數(shù)對象被認(rèn)為是一個(gè)任務(wù)（task）。

基于任務(wù)的方法通常優(yōu)于基于線程的對應(yīng)方法，我們看到基于任務(wù)的方法代碼量更少，這已經(jīng)是展示了一些原因了。在這里，doAsyncWork會(huì)返回一個(gè)值，我們有理由假定調(diào)用doAsyncWork的代碼對這個(gè)返回值有興趣。在基于線程的調(diào)用中，沒有直接的辦法獲取到它；而在基于任務(wù)的調(diào)用中，這很容易，因?yàn)閟td::asyn返回的future提供了一個(gè)函數(shù)get來獲取返回值。如果doAsyncWork函數(shù)發(fā)出了一個(gè)異常，get函數(shù)是很重要的，它能取到這個(gè)異常。在基于線程的方法中，如果doAsyncWork拋出了異常，程序就死亡了（借助std::terminate）。

基于線程編程和基于任務(wù)編程的一個(gè)更根本的區(qū)別是，基于任務(wù)編程表現(xiàn)出更高級別的抽象。它讓你擺脫線程管理的細(xì)節(jié)，這提醒我需要總結(jié)一下并發(fā)C++軟件里“線程”的三種含義：

硬件線程是實(shí)際執(zhí)行計(jì)算的線程?，F(xiàn)代機(jī)器體系結(jié)構(gòu)為每個(gè)CPU核心提供一個(gè)或多個(gè)硬件線程。軟件線程（又稱為操作系統(tǒng)線程或系統(tǒng)線程）是由操作系統(tǒng)管理和為硬件線程進(jìn)行調(diào)度的線程。軟件線程創(chuàng)建的數(shù)量通常會(huì)比硬件線程多，因?yàn)楫?dāng)一個(gè)軟件線程阻塞了（例如，I/O操作，等待鎖或者條件變量），運(yùn)行另一個(gè)非阻塞的線程能提供吞吐率。std::thread是C++進(jìn)程里的對象，實(shí)際上相當(dāng)于它內(nèi)部軟件線程的句柄。一些std::thread對象表示為“null”句柄，即不持有軟件線程，因?yàn)樗鼈兲幱谀J(rèn)構(gòu)造狀態(tài)（因此沒有函數(shù)需要執(zhí)行），它要么被move過了（那么接受移動(dòng)的那個(gè)std::thread對象將代替這個(gè)std::thread對象來處理線程），要么被detach了（std::thread對象和它內(nèi)部軟件線程的關(guān)聯(lián)被切斷了，即thread對象和軟件線程分離了）。

軟件線程是一種受限的資源，如果你想創(chuàng)建的線程數(shù)量多于系統(tǒng)提供的數(shù)量，會(huì)拋出std::system_error異常。就算你規(guī)定函數(shù)不能拋出異常，這個(gè)異常也會(huì)拋出。例如，就算你把doAsyncWork聲明為noexcept，

int?doAsyncWork?noexcept;???//?關(guān)于noexcept

這語句還是可能會(huì)拋出異常：

std::thread?t(doAsyncWork);??//?如果沒有可獲取的系統(tǒng)，就拋出異常

寫得好的軟件必須想個(gè)辦法解決這個(gè)可能性，但如何解決呢？一個(gè)辦法是在當(dāng)前線程運(yùn)行doAsyncWork，但這會(huì)導(dǎo)致負(fù)載不均衡的問題，而且，如果當(dāng)前線程是個(gè)GUI線程，會(huì)導(dǎo)致響應(yīng)時(shí)間變長。另一個(gè)方法是等待某些已存在的軟件線程完成工作，然后再嘗試創(chuàng)建一個(gè)新的std::thread對象，但是有可能發(fā)生這種事情：已存在的線程在等待doAsyncWork的處理（例如，doAsyncWorkd的返回值，或者通知條件變量）。

即使你創(chuàng)建的線程數(shù)量沒超過系統(tǒng)限制，你還是會(huì)有oversubscription（過載）的問題——當(dāng)就緒狀態(tài)（即非阻塞）的軟件線程多于硬件線程的時(shí)候。此時(shí)，調(diào)度線程（通常是操作系統(tǒng)的一部分）會(huì)為軟件線程分配CPU時(shí)間片，一個(gè)線程的時(shí)間片用完，就運(yùn)行另一個(gè)線程，這其中發(fā)生了上下文切換。這種上下文切換會(huì)增加系統(tǒng)的線程管理開銷。這種情況下，（1）CPU緩存會(huì)持有那個(gè)軟件線程（即，它們會(huì)存儲對于那軟件線程有用的一些數(shù)據(jù)和一些指令），而（2）CPU核心上“新”運(yùn)行的軟件線程“污染”了CPU緩存上“舊的”線程數(shù)據(jù)（它曾經(jīng)在該CPU核心運(yùn)行過，且可能再次調(diào)度到該CPU核心運(yùn)行）。

避免oversubscription是很困難的，因?yàn)檐浖到y(tǒng)和硬件線程的最佳比例是取決于軟件線程多久需要執(zhí)行一次，而這是會(huì)動(dòng)態(tài)改變的，例如，當(dāng)一個(gè)線程從IO消耗型轉(zhuǎn)換為CPU消耗型時(shí)。這最佳比例也取決于上下文切換的開銷和軟件線程使用CPU緩存的效率。再進(jìn)一步說，硬件線程的數(shù)量和CPU緩存的細(xì)節(jié)（例如，緩存多大和多快）是取決于機(jī)器的體系結(jié)構(gòu)，所以即使你在一個(gè)平臺上讓你的應(yīng)用避免了oversubscription（保持硬件繁忙工作），也不能保證在另一種機(jī)器上你的方案能工作得好。

如果你把這些問題扔給某個(gè)人去做，你的生活就很愜意啦，然后使用std::async就能顯式地做這件事：

auto?fut?=?std::async(doAsyncWork);??//?線程管理的責(zé)任交給標(biāo)準(zhǔn)庫的實(shí)現(xiàn)者

這個(gè)調(diào)用把線程管理的責(zé)任轉(zhuǎn)交給C++標(biāo)準(zhǔn)庫的實(shí)現(xiàn)者。例如，得到線程數(shù)超標(biāo)異常的可能性顯著減少，因?yàn)檫@個(gè)調(diào)用可能從不產(chǎn)生這個(gè)異常?！八窃鯓幼龅降哪?？”你可能好奇，“如果我申請多于系統(tǒng)提供的線程數(shù)，使用std::thread和使用std::async有區(qū)別嗎？”答案是有區(qū)別，因?yàn)楫?dāng)用默認(rèn)啟動(dòng)策略（default launch policy）調(diào)用std::async時(shí)，不能保證它會(huì)創(chuàng)建一個(gè)新的軟件線程。而且，它允許調(diào)度器把指定函數(shù)（本例中的doAsyncWork）運(yùn)行在——請求doAsyncWork結(jié)果的線程中（例如，那個(gè)線程調(diào)用了get或者對fut使用wait?），如果系統(tǒng)oversubsrcibed或線程數(shù)耗盡時(shí)，合理的調(diào)度器可以利用這個(gè)優(yōu)勢。

如果你想用“在需要函數(shù)結(jié)果的線程上運(yùn)行該函數(shù)”來欺騙自己，我提起過這會(huì)導(dǎo)致負(fù)載均衡的問題，這問題不會(huì)消失，只是由std::async和調(diào)度器來面對它們，而不是你。但是，當(dāng)涉及到負(fù)載均衡問題時(shí)，調(diào)度器比你更加了解當(dāng)前機(jī)器發(fā)生了什么，因?yàn)樗芾硭羞M(jìn)程的線程，而不是只是你的代碼運(yùn)行于的進(jìn)程和線程。

使用std::async，GUI線程的響應(yīng)性也是有問題的，因?yàn)檎{(diào)度器沒有辦法知道哪個(gè)線程具有嚴(yán)格的響應(yīng)性要求。在這種情況下，你可以把std::lanuch::async啟動(dòng)策略傳遞給std::async，它那可以保證你想要運(yùn)行的函數(shù)馬上會(huì)在另一個(gè)線程中執(zhí)行。

最先進(jìn)的線程調(diào)度器使用了系統(tǒng)范圍的線程池來避免oversubscription，而且調(diào)度器通過工作竊?。╳orkstealing）算法來提高了硬件核心的負(fù)載均衡能力。C++標(biāo)準(zhǔn)庫沒有要求線程池或者工作竊取算法，而且，實(shí)話說，C++11并發(fā)技術(shù)的一些實(shí)現(xiàn)細(xì)節(jié)讓我們很難利用到它們。但是，一些供應(yīng)商會(huì)在它們的標(biāo)準(zhǔn)庫實(shí)現(xiàn)中利用這種技術(shù)，所以我們有理由期待C++并發(fā)庫會(huì)繼續(xù)進(jìn)步。如果你使用基于任務(wù)的方法進(jìn)行編程，當(dāng)它以后變智能了，你會(huì)自動(dòng)獲取到好處。另一方面，如果你直接使用std::thread進(jìn)行編程，你要承擔(dān)著處理線程耗盡、oversubscription、負(fù)載均衡的壓力，更不用提你在程序中對這些問題的處理方案能否應(yīng)用在同一臺機(jī)器的另一個(gè)進(jìn)程上。

比起基于線程編程，基于任務(wù)的設(shè)計(jì)能分擔(dān)你的線程管理之痛，而且它提供了一種很自然的方式，讓你檢查異步執(zhí)行函數(shù)的結(jié)果（即，返回值或異常）。但是，有幾種情況直接使用std::thread更適合，它們包括

你需要使用特定平臺內(nèi)部線程實(shí)現(xiàn)的API。C++并發(fā)API通常是使用特定平臺的低級API實(shí)現(xiàn)的，通常使用pthread或Window’s Thread。它們提供的API比C++提供的要多（例如，C++沒有線程優(yōu)先級的概念）。為了獲取內(nèi)部線程實(shí)現(xiàn)的API，std::thread對象有一個(gè)native_handle成員函數(shù)，而std::future（即std::async返回的類型）沒有類似的東西。你需要且能夠優(yōu)化你應(yīng)用中的線程。你需要在C++并發(fā)API之上實(shí)現(xiàn)線程技術(shù)。例如，實(shí)現(xiàn)一個(gè)C++不提供的線程池。

不過，這些都是不常見的情況。大多數(shù)時(shí)候，你應(yīng)該選擇基于任務(wù)的設(shè)計(jì)，來代替線程。

總結(jié)

需要記住的3點(diǎn)：

std::thread的API沒有提供直接獲取異步運(yùn)行函數(shù)返回值的方法，而且，如果這些函數(shù)拋出異常，程序會(huì)被終止?；诰€程編程需要手動(dòng)地管理：線程耗盡、oversubscription、負(fù)載均衡、適配新平臺。借助默認(rèn)發(fā)射策略的std::async，進(jìn)行基于任務(wù)編程可以解決上面提到的大部分問題。