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

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

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

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

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

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

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

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

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

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

這語句還是可能會拋出異常：

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

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

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

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

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

auto?fut?=?std::async(doAsyncWork);??//?線程管理的責任交給標準庫的實現(xiàn)者

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

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

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

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

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

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

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

總結(jié)

需要記住的3點：

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