眾所周知，STL容器不是線程安全的。對(duì)于vector，即使寫(xiě)方（生產(chǎn)者）是單線程寫(xiě)入，但是并發(fā)讀的時(shí)候，由于潛在的內(nèi)存重新申請(qǐng)和對(duì)象復(fù)制問(wèn)題，會(huì)導(dǎo)致讀方（消費(fèi)者）的迭代器失效。實(shí)際表現(xiàn)也就是招致了core dump。另外一種情況，如果是多個(gè)寫(xiě)方，并發(fā)的push_back()，也會(huì)導(dǎo)致core dump。

解法一

加鎖是一種解決方案，比如互斥鎖std::mutex。但是加std::mutex確實(shí)性能較差。對(duì)于多讀少寫(xiě)的場(chǎng)景可以用讀寫(xiě)鎖（也叫共享獨(dú)占鎖）來(lái)緩解。比如C 17引入了std::shared_mutex 。更多鎖的種類可以閱讀之前寫(xiě)的這篇文章：

如何理解互斥鎖、條件變量、讀寫(xiě)鎖以及自旋鎖？

當(dāng)然本文的目的自然不是自我重復(fù)再次介紹一次鎖的使用，請(qǐng)繼續(xù)閱讀解法二！

解法二

更多的時(shí)候，其實(shí)可以通過(guò)固定vector的大小，避免動(dòng)態(tài)擴(kuò)容（無(wú)push_back）來(lái)做到lock-free！

即在開(kāi)始并發(fā)讀寫(xiě)之前（比如初始化）的時(shí)候，給vector設(shè)置好大小。

struct?Data?{
...
};
vector?v;
v.resize(1000);
注意是resize()，不是reserve()！

可能大家平時(shí)用reserve()比較多，顧名思義，reserve就是預(yù)留內(nèi)存。為的是避免內(nèi)存重新申請(qǐng)以及容器內(nèi)對(duì)象的拷貝。說(shuō)白了，reserve()是給push_back()準(zhǔn)備的！

而resize除了預(yù)留內(nèi)存以外，還會(huì)調(diào)用容器元素的構(gòu)造函數(shù)，不僅分配了N個(gè)對(duì)象的內(nèi)存，還會(huì)構(gòu)造N個(gè)對(duì)象。從這個(gè)層面上來(lái)說(shuō)，resize()在時(shí)間效率上是比reserve()低的。但是在多線程的場(chǎng)景下，用resize再合適不過(guò)。

你可以resize好N個(gè)對(duì)象，多線程不管是讀還是寫(xiě)，都是通過(guò)容器的下標(biāo)訪問(wèn)operator[]來(lái)訪問(wèn)元素，不要push_back()新元素。所謂的『寫(xiě)操作』在這里不是插入新元素，而是修改舊元素。

如果N的最大個(gè)數(shù)是可以預(yù)期的就直接設(shè)置就好，如果沒(méi)辦法預(yù)期就再把vector搞成ring buffer（環(huán)形隊(duì)列）來(lái)緩解壓力。

可以給元素類加上成員變量標(biāo)記當(dāng)前的讀寫(xiě)狀態(tài)、是否被消費(fèi)等等。

當(dāng)然，你會(huì)說(shuō)，如果B，C，D，E，F(xiàn)這個(gè)5個(gè)線程是等價(jià)的，要不停消費(fèi)vector中的元素，會(huì)造成重復(fù)消費(fèi)不？

當(dāng)然會(huì)。你可以把隊(duì)列頭的下標(biāo)定義成原子變量（std::atomic），盡管原子變量也需要做線程同步，但是比一般的鎖開(kāi)銷要小很多啦。

如果你想連原子變量也不用，有沒(méi)有辦法呢？有啊。那就給B，C，D，E，F(xiàn)分配不同的消費(fèi)隊(duì)列啊。比如當(dāng)前有5個(gè)讀線程，那么每個(gè)線程就消費(fèi)下標(biāo)對(duì)5取模之后的某個(gè)固定結(jié)果的下標(biāo)。比如：

• B消費(fèi)：0、5、10、15、……
• C消費(fèi)：1、6、11、16、……
• D消費(fèi)：2、7、12、17、……
• E消費(fèi)：3、8、13、18、……
• F消費(fèi)：4、9、14、19、……

每個(gè)讀線程各自維護(hù)自己當(dāng)前消費(fèi)的最新下標(biāo)。

這樣做有啥問(wèn)題沒(méi)？也有，就是可能會(huì)導(dǎo)致不同的線程繁忙和等待的情況差異巨大：忙的忙死，閑的閑死。具體場(chǎng)景具體分析，總之，無(wú)論如何要控制住。不要讓一個(gè)任務(wù)hang住整個(gè)線程。

vector是順序容器，STL中還有一類關(guān)聯(lián)容器其線程安全問(wèn)題也不容小覷。比如map、unordered_map。

我們可能會(huì)有這樣一種場(chǎng)景：在并發(fā)環(huán)境下，收集一些Key-Value，存儲(chǔ)在某一個(gè)公共的容器中。這里也談一下不用鎖的方案，當(dāng)然做不到放之四海皆準(zhǔn)。它有一些限制條件，只能看是否滿足你的需要了。

當(dāng)有多個(gè)寫(xiě)線程對(duì)情況下，并發(fā)地插入 map/unordered_map都會(huì)引發(fā)core dump。對(duì)此，在某些場(chǎng)景下也可以避免加鎖：如果全量的key有辦法在并發(fā)之前就能拿到的，那么就對(duì)這個(gè)map，提前做一下insert。

并發(fā)環(huán)境中如果只是修改value，而不是插入新key就不會(huì)core dump！不過(guò)如果你沒(méi)辦法保證多個(gè)寫(xiě)線程不會(huì)同時(shí)修改同一個(gè)key的value，那么可能存在value的覆蓋。

無(wú)法保證這點(diǎn)時(shí)，還是需要加鎖。不過(guò)可以對(duì)key采取某種hash策略轉(zhuǎn)成整型，然后進(jìn)行分段加鎖，減少一點(diǎn)鎖沖突的概率，或者用一下CAS的策略。

另外對(duì)于unordered_map，在單寫(xiě)多讀的多線程場(chǎng)景下，會(huì)不會(huì)有問(wèn)題呢？也可能有。gcc 4.7.2的unordered_map實(shí)現(xiàn)曾被爆出有這個(gè)問(wèn)題。原因的新插入的元素，觸發(fā)了rehash，讓其他線程在unordered_map中查找的過(guò)程之中，出現(xiàn)了core dump。見(jiàn)：

https://stackoverflow.com/questions/16353334/segv-in-gccs-stdunordered-map

我不確定clang以及后續(xù)的gcc版本是否還有此問(wèn)題。應(yīng)該在不添加任何額外同步代碼的情況下，無(wú)法解決。

容器并發(fā)前初始化與偽共享的爭(zhēng)議

本文內(nèi)容曾經(jīng)在知乎上寫(xiě)過(guò)，有網(wǎng)友評(píng)論：解法二會(huì)有false sharing（偽共享）的問(wèn)題。

這里簡(jiǎn)單回應(yīng)一下，談?wù)搨喂蚕?，要考慮具體的場(chǎng)景。的確某些時(shí)候偽共享會(huì)帶來(lái)性能損失，但是要和并行化帶來(lái)的性能提升來(lái)比較，孰高孰低。如果并行提升的性能足夠多，是足以彌補(bǔ)這點(diǎn)偽共享的損失的。

比如我要進(jìn)行遠(yuǎn)程IO，我有N個(gè)key要查詢r(jià)edis，把他們的結(jié)果存儲(chǔ)到一個(gè)vector中，這個(gè)vector的寫(xiě)入操作在IO的異步回調(diào)函數(shù)中。在不加任何額外處理的情況下，極大概率會(huì)導(dǎo)致vector的core dump。

而如果vector初始化一下，則無(wú)需在回調(diào)函數(shù)中加鎖，就能保證安全。這時(shí)候并行IO本身帶來(lái)的性能提升，遠(yuǎn)遠(yuǎn)大于可能的偽共享帶來(lái)?yè)p失。

這里為什么說(shuō)可能呢？因?yàn)閭喂蚕淼挠|發(fā)沒(méi)你想象的這么簡(jiǎn)單。如何成功模擬出一次偽共享帶來(lái)性能損失的例子？你可以寫(xiě)程序自測(cè)一下，并不容易……甚至你改一下優(yōu)化級(jí)別，改成O2，測(cè)試表現(xiàn)都很不一樣。

一般網(wǎng)絡(luò)上談?wù)搨喂蚕頃r(shí)所舉的例子，并不是一個(gè)vector中多個(gè)元素之間并行讀寫(xiě)觸發(fā)了偽共享。而是vector的元素類型是一個(gè)對(duì)象，對(duì)象中有2個(gè)數(shù)據(jù)字段a和b，在多線程分別更新同一個(gè)元素的a和b字段的時(shí)候，導(dǎo)致了偽共享。

比如一個(gè)線程更新vector中每個(gè)元素的a字段，另外一個(gè)線程更新vector中每個(gè)元素的b字段。

Anyway，偽共享的議題比較復(fù)雜，歡迎留意評(píng)論！

- EOF -