为何C++标准库本身不具备线程安全性？

你的观察没错——C++类本身确实不具备默认线程安全性，成员函数没有原子性保障，需要手动用互斥锁保护临界区。至于标准库不自动做这件事，核心原因可以归结为以下几点：

• 不必要的开销违反零成本原则
  C++的设计核心之一是「不支付你不需要的代价」。很多程序完全是单线程的，或者类实例只会在单个线程中被访问，这时候自动加锁带来的开销（哪怕是看起来很小的锁状态检查、潜在的上下文切换风险）都是纯浪费。比如高频调用的工具类，每次成员函数调用都加解锁，累积起来的性能损耗会非常明显。

• 粗粒度锁会限制并发效率
  如果给每个类自动加一个全局互斥锁，所有成员函数都共享这把锁，会导致完全没必要的阻塞。比如一个类有两个完全独立的成员变量a和b，线程1读写a、线程2读写b的时候，自动锁会让它们互相等待，但实际上这两个操作根本不会产生竞态。用户本来可以用两把细粒度锁分别保护，自动加锁反而把并发度给锁死了。

• 锁语义的匹配问题
  不同的成员函数需要的锁类型不一样：只读函数可以用共享锁（允许多个线程同时读），读写函数才需要独占锁。自动加独占锁会浪费读操作的并发能力。另外，很多业务逻辑需要跨多个成员函数的原子性——比如先调用get()再调用set()，如果每个函数单独加锁，两次调用之间锁会释放，中间可能被其他线程修改，反而破坏了操作的原子性，这时候用户必须自己在外部加锁，自动加锁反而会误导人。

• 兼容性与历史包袱
  C++最初的设计没有考虑多线程，后来才逐步加入线程支持。如果突然给所有类默认加锁，会破坏大量旧代码的行为——有些旧代码依赖于非线程安全的操作逻辑，自动加锁后可能出现性能下降、甚至逻辑错误（比如原本依赖于单线程下的执行顺序，加锁后被打乱）。

• 互斥锁不是线程安全的银弹
  自动加锁解决不了所有线程安全问题：比如死锁（两个类互相调用对方的成员函数，自动锁会导致死锁）、优先级反转，甚至会让用户忽略这些潜在风险，调试起来更困难。而且有些场景需要条件变量、原子变量等更复杂的同步机制，自动加锁覆盖不了这些需求。

内容的提问来源于stack exchange，提问作者zalanshah64