[[415228]]

本文轉(zhuǎn)載自微信公眾號(hào)「程序喵大人」，作者程序喵大人。轉(zhuǎn)載本文請(qǐng)聯(lián)系程序喵大人公眾號(hào)。

平時(shí)開(kāi)發(fā)過(guò)程中大家可能都接觸過(guò)多線程開(kāi)發(fā)，其實(shí)多線程還是有很多門(mén)道的，這里貼出我的一點(diǎn)點(diǎn)看法，拋磚引玉一波。

1 使用標(biāo)準(zhǔn)庫(kù)中的并行算法：C++標(biāo)準(zhǔn)庫(kù)中有大量算法，在C++17后，有60多個(gè)算法支持并行執(zhí)行，可設(shè)置ExecutionPolicy策略。盡量使用這些并行算法，沒(méi)必要自己寫(xiě)個(gè)多線程相關(guān)算法。

2 可更多使用C++11的std::thread，而不是pthread，推薦std::thread沒(méi)啥別的性能方面的原因，只是因?yàn)槭褂闷饋?lái)很方便。

• std::thread配合lambda表達(dá)式創(chuàng)建個(gè)線程運(yùn)行，很方便!
• thread對(duì)象直接join或者detach，很方便!
• 使用thread再配合mutex的std::unique_lock和std::lock_guard使用，很方便!
• 使用thread再配合條件變量使用，很方便!
• 使用std::this_thread::sleep_for(xxx)休眠某段時(shí)間，很方便!

3 在使用std::thread時(shí)，確保在生命周期結(jié)束前，std::thread對(duì)象不是可結(jié)合的，即確保對(duì)象調(diào)用了join()或者detach()。否者程序會(huì)crash，為什么會(huì)這樣?源碼之下，了無(wú)秘密，這是std::thread的析構(gòu)函數(shù)，一看便知：

~thread() 
{ 
    if (joinable()) 
    std::terminate(); 
} 

C++20的std::jthread就解決了這個(gè)問(wèn)題，jthread在析構(gòu)函數(shù)中會(huì)自動(dòng)join()。其實(shí)不使用C++20，我們也可以自己封裝一個(gè)std::thread的wrapper，來(lái)解決這種問(wèn)題。

4 使用sleep(xxx)永遠(yuǎn)解決不了任何時(shí)序相關(guān)的bug，一定要使用條件變量來(lái)保證時(shí)序。

5 不要迷信多線程，我們要明確知道，為什么要使用多線程，是為了更高的性能?還是為了不阻塞當(dāng)前線程?還是有其他考慮?想清楚利弊，最好能綜合做出評(píng)估后再?zèng)Q定。

6 最好的同步就是沒(méi)有同步：盡可能使用更合理的方式設(shè)計(jì)線程，讓所有的線程在使用共享數(shù)據(jù)時(shí)只讀不寫(xiě)，或者只寫(xiě)入其他線程不會(huì)讀取的部分，或者確保數(shù)據(jù)的所有權(quán)是單線程模式，同一時(shí)刻只會(huì)有一個(gè)線程在訪問(wèn)這塊數(shù)據(jù)，那么多線程編碼就會(huì)簡(jiǎn)單很多，不會(huì)有任何數(shù)據(jù)競(jìng)爭(zhēng)，也不會(huì)出現(xiàn)死鎖等問(wèn)題。

7 先考慮原子類(lèi)型再考慮鎖：通過(guò)原子類(lèi)型或原子操作更方便編寫(xiě)沒(méi)有數(shù)據(jù)競(jìng)爭(zhēng)和死鎖的代碼，因?yàn)樗麄兡茏詣?dòng)處理同步問(wèn)題。如果不能使用原子類(lèi)型或原子操作，那再考慮使用互斥鎖來(lái)保護(hù)臨界區(qū)。(看到過(guò)有大佬不推薦原子操作的，但是沒(méi)說(shuō)為啥，這是有什么顧慮嗎?大家可以留言聊一聊。)

8 先確保解決了同步問(wèn)題，再考慮優(yōu)化：典型的就是普通互斥鎖和讀寫(xiě)鎖的問(wèn)題，很多人上來(lái)就使用讀寫(xiě)鎖，追求更高的性能，除非讀操作比寫(xiě)操作頻繁的多，否則讀寫(xiě)鎖并不會(huì)提高多少性能，我看見(jiàn)過(guò)很多使用讀寫(xiě)鎖導(dǎo)致出現(xiàn)同步問(wèn)題的案例。所以，開(kāi)始寫(xiě)代碼時(shí)還是消停的使用普通鎖吧，真正需要優(yōu)化時(shí)再考慮使用其他手段。

9 使用RAII鎖對(duì)象：使用lock_guard、unique_lock、shared_lock或scoped_lock等RAII類(lèi)來(lái)管理鎖，這樣可以確保一定會(huì)釋放鎖。降低出現(xiàn)死鎖的風(fēng)險(xiǎn)，但我們也要了解，如果真的出現(xiàn)了死鎖，我們要如何定位?再出個(gè)思考題：我們都知道加鎖的順序不一致可能會(huì)導(dǎo)致死鎖，如果釋放鎖的順序不一致會(huì)導(dǎo)致死鎖嗎?

10 盡快釋放鎖：當(dāng)需要通過(guò)鎖保護(hù)共享數(shù)據(jù)時(shí)，務(wù)必盡快釋放鎖，盡可能縮小鎖控制的粒度，明確哪些數(shù)據(jù)需要加鎖，哪些根本就不需要，不要無(wú)腦加鎖。因?yàn)楫?dāng)一個(gè)線程持有一個(gè)鎖時(shí)，會(huì)使得其他線程阻塞等待這個(gè)鎖，這可能會(huì)降低程序的性能。

11 使用線程池：動(dòng)態(tài)頻繁的創(chuàng)建和銷(xiāo)毀大量的線程會(huì)導(dǎo)致性能下降。這種情況下，最好使用線程池來(lái)重用已有的線程，我之前寫(xiě)過(guò)如何擼一個(gè)線程池的文章，大家可以去看看。

12 如果真的需要共享數(shù)據(jù)，盡量使用通信方式，而非共享內(nèi)存方式?？墒褂藐?duì)列，通信隊(duì)列如果需要可考慮使用阻塞隊(duì)列，而不是while(!queue.empty()) { xxx }。 

13 做好日志記錄：使用多線程程序很容易出現(xiàn)各種問(wèn)題，而且問(wèn)題還不穩(wěn)定復(fù)現(xiàn)，復(fù)現(xiàn)的時(shí)機(jī)多數(shù)時(shí)候還不一樣，一定要做好日志記錄，確保出現(xiàn)問(wèn)題時(shí)有據(jù)可查，可快速分析出問(wèn)題所在。