为什么 C++ STL不是提供了一套线程安全的容器吗？
可能的重复：
有关 STL 线程安全和 STL 调试的问题
目前正在从事一个使用C++开发的项目。最近，我们正在考虑用一些 STL 等效项替换一些自定义的线程安全容器，以提高效率。
然而找了一段时间，发现STL中根本没有提供线程安全的容器，这让我颇感意外。有什么理由吗？
Possible Duplicate:
question about STL thread-safe and STL debugging
I'm currently being engaged in a project which is developed using C++. Recently we are considering replacing some self-defined thread-safe containers with some STL equivalents to gain some efficiency.
However, after looking for a while, I found that there is no a thread-safe container provided in STL at all, which surprises quite a lot. Is there any reason?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
可能是因为它实际上并没有那么有用（除了 @Luchian Grigore 在另一个答案中所说的）。即使单个容器操作是线程安全的，你仍然需要做很多工作来保证线程安全。例如，即使容器本身是线程安全的，这个简单的代码也包含竞争条件：
Probably because it wouldn't actually be all that useful (in addition to what @Luchian Grigore says in another answer). Even if individual container operations are thread-safe, you still need to do a lot of work to ensure thread safety. For instance, this simple code contains a race condition even if the container itself is thread-safe:
标准库容器确实提供了一些基本的线程安全性，对于标准库容器的设计者来说，性能是比安全性更重要的设计目标。
所有标准库容器保证：
来自同一容器的多个并发读取是安全的，但是
如果至少有一个编写器线程，则不存在线程安全性和安全性。不得有任何其他作者或读者。
标准库容器主要设计用于在单线程环境中高效工作，并且仅提供基本线程安全性是确保不需要并发访问的容器充分发挥性能的一种方法。
基本的线程安全性要求用户需要某种同步方法，通过使用互斥体或锁来避免竞争条件。锁定或其他形式的同步通常成本高昂，因此在不必要时需要避免。
此外，考虑到标准库容器公开的接口，如果预期用途是用于多线程环境，则容器的客户端或用户可以通过用锁获取和释放包装底层容器操作来轻松提供必要的锁定。
请注意，所有实现均符合 C++ 标准指定的以下要求：
17.6.3.10 共享对象和库 [res.on.objects]
Standard Library containers do provide some basic thread safety, Performance was a more important design goal for designers of the Standard Library containers than safety.
All Standard Library containers guarantee:
Multiple concurrent reads from the same container are safe but
If there is atleast one writer thread, then there is no thread safety & there shall not be any other writer or reader.
The Standard Library containers were primarily designed for working efficiently in Single threaded environments and providing only basic thread safety is a way to ensure full performance for containers that do not need concurrent access.
The basic thread safety needs that users need some sort of synchronization methods to avoid race conditions through use of using mutexes, or locks.Locking or other forms of synchronization are typically expensive and hence need to be avoided when not necessary.
Also, given the interfaces exposed by the Standard Library containers, It is easy for the client or user of the container to provide the necessary locking by wrapping the underlying container operations with a lock acquisition and release if intended use is for multi-threaded environments.
Note that All the implementations conform the following requirements specified by the C++ Standard:
17.6.3.10 Shared objects and the library [res.on.objects]
C++ STL 提供了几乎所有其他东西都提供的线程安全性：只要一个对象不在一个线程中访问，而另一个线程正在或可能正在修改它，您就可以安全地从多个线程使用 STL 容器。
The C++ STL provides the kind of thread-safety that pretty much everything else provides: You can safely use STL containers from multiple threads so long as an object isn't accessed in one thread while another thread is, or might be, modifying it.
因为线程安全是高度特定于平台和编译器的。
Because thread safety is highly platform and compiler specific.
用一句话来说——因为很难。
因为线程安全容器需要特定的设计 - 例如它们必须是持久数据结构。此类容器最容易在功能/垃圾收集/基于事件的环境中实现。而 C++ 则不然。
也就是说，实现这些仍然需要用户处理所有资源分配/解除分配。这违背了收藏的意义。
In a sentence - because it's hard.
Because thread-safe containers require specific design - e.g. they must be persistent data structures. Such containers are easiest to implement in functional / garbage collected / event-based environments. Which C++ is not.
That is to say, implementing these would still require the user to handle all resource allocation/deallocation. That kind of defeats the point of having a collection.