平時開發(fā)過程中大家可能都接觸過多線程開發(fā),其實多線程還是有很多門道的,這里貼出我的一點點看法,拋磚引玉一波。
1 使用標(biāo)準(zhǔn)庫中的并行算法:C 標(biāo)準(zhǔn)庫中有大量算法,在C 17后,有60多個算法支持并行執(zhí)行,可設(shè)置ExecutionPolicy策略。盡量使用這些并行算法,沒必要自己寫個多線程相關(guān)算法。
2 可更多使用C 11的std::thread,而不是pthread,推薦std::thread沒啥別的性能方面的原因,只是因為使用起來很方便。
● std::thread配合lambda表達式創(chuàng)建個線程運行,很方便!
● thread對象直接join或者detach,很方便!
●使用thread再配合mutex的std::unique_lock和std::lock_guard使用,很方便!
● 使用thread再配合條件變量使用,很方便!
● 使用std::this_thread::sleep_for(xxx)休眠某段時間,很方便!
3 在使用std::thread時,確保在生命周期結(jié)束前,std::thread對象不是可結(jié)合的,即確保對象調(diào)用了join()或者detach()。否者程序會crash,為什么會這樣?源碼之下,了無秘密,這是std::thread的析構(gòu)函數(shù),一看便知:
~thread(){ if (joinable()) std::terminate();}
C 20的std::jthread就解決了這個問題,jthread在析構(gòu)函數(shù)中會自動join()。其實不使用C 20,我們也可以自己封裝一個std::thread的wrapper,來解決這種問題。4 使用sleep(xxx)永遠解決不了任何時序相關(guān)的bug,一定要使用條件變量來保證時序。
5 不要迷信多線程,我們要明確知道,為什么要使用多線程,是為了更高的性能?還是為了不阻塞當(dāng)前線程?還是有其他考慮?想清楚利弊,最好能綜合做出評估后再決定。
6 最好的同步就是沒有同步:盡可能使用更合理的方式設(shè)計線程,讓所有的線程在使用共享數(shù)據(jù)時只讀不寫,或者只寫入其他線程不會讀取的部分,或者確保數(shù)據(jù)的所有權(quán)是單線程模式,同一時刻只會有一個線程在訪問這塊數(shù)據(jù),那么多線程編碼就會簡單很多,不會有任何數(shù)據(jù)競爭,也不會出現(xiàn)死鎖等問題。
7 先考慮原子類型再考慮鎖:通過原子類型或原子操作更方便編寫沒有數(shù)據(jù)競爭和死鎖的代碼,因為他們能自動處理同步問題。如果不能使用原子類型或原子操作,那再考慮使用互斥鎖來保護臨界區(qū)。(看到過有大佬不推薦原子操作的,但是沒說為啥,這是有什么顧慮嗎?大家可以留言聊一聊。)
8 先確保解決了同步問題,再考慮優(yōu)化:典型的就是普通互斥鎖和讀寫鎖的問題,很多人上來就使用讀寫鎖,追求更高的性能,除非讀操作比寫操作頻繁的多,否則讀寫鎖并不會提高多少性能,我看見過很多使用讀寫鎖導(dǎo)致出現(xiàn)同步問題的案例。所以,開始寫代碼時還是消停的使用普通鎖吧,真正需要優(yōu)化時再考慮使用其他手段。
9 使用RAII鎖對象:使用lock_guard、unique_lock、shared_lock或scoped_lock等RAII類來管理鎖,這樣可以確保一定會釋放鎖。降低出現(xiàn)死鎖的風(fēng)險,但我們也要了解,如果真的出現(xiàn)了死鎖,我們要如何定位?再出個思考題:我們都知道加鎖的順序不一致可能會導(dǎo)致死鎖,如果釋放鎖的順序不一致會導(dǎo)致死鎖嗎?
10 盡快釋放鎖:當(dāng)需要通過鎖保護共享數(shù)據(jù)時,務(wù)必盡快釋放鎖,盡可能縮小鎖控制的粒度,明確哪些數(shù)據(jù)需要加鎖,哪些根本就不需要,不要無腦加鎖。因為當(dāng)一個線程持有一個鎖時,會使得其他線程阻塞等待這個鎖,這可能會降低程序的性能。
11 使用線程池:動態(tài)頻繁的創(chuàng)建和銷毀大量的線程會導(dǎo)致性能下降。這種情況下,最好使用線程池來重用已有的線程,我之前寫過如何擼一個線程池的文章,大家可以去看看。
12 如果真的需要共享數(shù)據(jù),盡量使用通信方式,而非共享內(nèi)存方式??墒褂藐犃?,通信隊列如果需要可考慮使用阻塞隊列,而不是while(!queue.empty()) { xxx }。
13 做好日志記錄:使用多線程程序很容易出現(xiàn)各種問題,而且問題還不穩(wěn)定復(fù)現(xiàn),復(fù)現(xiàn)的時機多數(shù)時候還不一樣,一定要做好日志記錄,確保出現(xiàn)問題時有據(jù)可查,可快速分析出問題所在。