STL容器的线程安全

众所周知，STL容器不是线程安全的。

对于vector，即使写方（生产者）是单线程写入，但是并发读的时候，由于潜在的内存重新申请和对象复制问题，会导致读方（消费者）的迭代器失效。实际表现也就是招致了core dump。另外一种情况，如果是多个写方，并发的push_back()，也会导致core dump。

解法一：

加锁是一种解决方案，但是加std::mutex互斥锁确实性能较差。对于多读少写的场景可以用读写锁（也叫共享独占锁），来缓解。C++17引入了std::shared_mutex 。更多锁的种类可以阅读下面这篇回答，但是本回答的目的自然不是自我重复再次介绍一次锁的使用，请继续阅读解法二！

解法二：

更多的时候，其实可以通过固定vector的大小，避免动态扩容（无push_back）来做到lock-free！即在开始并发读写之前（比如初始化）的时候，给vector设置好大小。

struct Data {
...
};
vector<Data> v;
v.resize(1000);

注意是resize，不是reserve！

可能大家平时用reserve()比较多，顾名思义，reserve就是预留内存。为的是避免内存重新申请以及容器内对象的拷贝。

说白了，reserve()是给push_back()准备的！而resize除了预留内存以外，还会调用容器元素的构造函数，不仅分配了N个对象的内存，还会构造N个对象。从这个层面上来说，resize()在时间效率上是比reserve()低的。但是在多线程的场景下，用resize再合适不过。你可以resize好N个对象，多线程不管是读还是写，都是通过容器的下标访问【operator[]】来访问元素，不要push_back新元素。所谓的『写操作』在这里不是插入新元素，而是修改旧元素。

如果N的最大个数是可以预期的就直接设置就好，如果没办法预期就再把vector搞成ring buffer（环形队列）来缓解压力。可以给元素类加上成员变量标记当前的读写状态、是否被消费等等。

当然，你会说，如果B，C，D，E，F这个5个线程是等价的，要不停消费vector中的元素，会造成重复消费不？当然会。你可以把 队列头的下标定义程原子变量（std::atomic），尽管原子变量也需要做线程同步，但是比一般的锁开销要小很多啦。如果你想连原子变量也不用，有没有办法呢？有啊。那就给B，C，D，E，F分配不同的消费队列啊。

比如当前有5个读线程，那么每个线程就消费下标模5之后的某个固定结果的下标。比如：

B消费：0、5、10、15、……
C消费：1、6、11、16、……
D消费：2、7、12、17、……
E消费：3、8、13、18、……
F消费：4、9、14、19、……

每个读线程各自维护自己当前消费的最新下标。这样做有啥问题没？也有，就是可能会导致不同的线程繁忙和等待的情况差异巨大：忙的忙死，闲的闲死。具体场景具体分析，总之，无论如何要控制住。不要让一个任务hang住整个线程。

关联容器的线程安全问题

vector是顺序容器，STL中还有一类关联容器其线程安全问题也不容小觑。比如map、unordered_map。我们可能会有这样一种场景：在并发环境下，收集一些Key-Value，存储在某一个公共的容器中。这里也谈一下不用锁的方案，当然做不到放之四海皆准。它有一些限制条件，只能看是否满足你的需要了。当有多个写线程对情况下，并发地插入 map/unordered_map都会引发core dump。对此，在某些场景下也可以避免加锁：如果全量的key有办法在并发之前就能拿到的，那么就对这个map，提前做一下insert。并发环境中如果只是修改value，而不是插入新key就不会core dump！不过如果你没办法保证多个写线程不会同时修改同一个key的value，那么可能存在value的覆盖。无法保证这点时，还是需要加锁。不过可以对key采取某种hash策略转成整型，然后进行分段加锁，减少一点锁冲突的概率，或者用一下CAS的策略。你还有什么好的思路，欢迎补充！