shared_ptr的引用计数是线程安全的，但其指向的对象并非线程安全。1. shared_ptr的引用计数操作（拷贝、赋值、销毁）是原子性的，确保多个线程可以安全地共享同一个shared_ptr实例；2. 但它不保证所管理对象的并发访问安全，多个线程同时读写该对象会导致数据竞争；3. 解决方案包括使用std::mutex保护共享对象的访问，确保每次操作都加锁；4. 使用不可变对象（immutable objects）并结合std::atomic实现高效读多写少场景；5. 在读远多于写的场景中，可采用std::shared_mutex提升并发性能；6. 实际应用中应根据读写频率和并发需求选择合适的同步机制，以保障线程安全。
shared_ptr本身（特指其内部的引用计数）是线程安全的，这意味着你可以在多个线程中安全地拷贝、赋值或销毁shared_ptr实例，而不会导致引用计数混乱。但它所指向的对象的读写，则完全不是线程安全的。换句话说，shared_ptr只管它自己的生命周期管理，不管你通过它访问的数据是否会被多个线程同时修改而引发问题。
解决方案
要正确地在多线程环境下读写shared_ptr所管理的共享对象，核心原则是：为共享对象的访问提供外部同步机制。这意味着，无论是读取还是写入，任何对shared_ptr所指向的实际数据的操作，都必须被互斥锁（如std::mutex）或其他并发原语保护起来。shared_ptr仅仅保证了其生命周期的管理是原子性的，但它无法替你管理它内部数据的并发访问问题。所以，如果你有一个shared_ptr，并且多个线程都可能通过这个shared_ptr去修改MyData的成员，那么你就需要确保这些修改操作是互斥的。
shared_ptr的引用计数操作真的是线程安全的吗？
说实话，这事儿挺容易让人犯迷糊的。是的，shared_ptr的引用计数操作，包括增加（比如你拷贝一个shared_ptr）和减少（比如一个shared_ptr离开作用域），是原子性的。这是C++标准库明确保证的。这意味着，当多个线程同时对同一个shared_ptr对象进行拷贝、赋值或析构时，其内部的引用计数器不会出现竞争条件，导致计数错误或内存泄漏/过早释放。你可以放心地在线程之间传递shared_ptr，或者在多个线程中持有同一个shared_ptr的副本，它的生命周期管理是稳健的。
但这里有个关键点，也是很多人会误解的地方：这种线程安全仅仅局限于shared_ptr自身的管理逻辑，也就是那个控制块里的引用计数。它并没有延伸到shared_ptr所指向的那个实际对象（T*）的内部状态。想象一下，shared_ptr就像一个门卫，它负责清点有多少人进入和离开了大楼，但它不负责管理大楼里的人在干什么，他们是否会打架。
为什么shared_ptr指向的对象在多线程环境下需要额外保护？
原因很简单，shared_ptr的设计初衷是解决对象的生命周期管理，而不是解决数据竞争。它确保了当最后一个shared_ptr实例被销毁时，它所指向的对象会被正确地释放。但如果多个线程同时尝试修改shared_ptr指向的同一个对象，比如一个std::vector，一个线程在push_back，另一个线程在clear，那么数据就会被破坏，这就是典型的数据竞争。
举个例子，你有一个shared_ptr<:map std::string>> myMapPtr;。如果线程A调用myMapPtr->insert({1, "a"});，同时线程B调用myMapPtr->erase(1);，甚至线程C调用myMapPtr->at(1);，这些操作都直接作用于std::map的内部状态。std::map本身并不是线程安全的容器。如果没有额外的同步机制，这些并发操作就会导致未定义行为，程序可能崩溃，也可能产生错误的结果。shared_ptr在此时完全无能为力，因为它只是一个智能指针，它并不知道也不关心你通过它访问的数据会被如何修改。它只是一个“拥有者”的概念，而不是一个“保护者”的概念。
保护共享对象的最佳实践有哪些？
既然shared_ptr不负责数据保护，那我们得自己动手。以下是一些行之有效的方法：
-
使用互斥锁（std::mutex）进行同步访问：
这是最常见、最直接也最推荐的方式。当你需要访问或修改shared_ptr指向的对象时，先获取一个锁，操作完成后再释放锁。
#include
#include
#include
#include
#include
#include
class SharedData {
public:
void addMessage(const std::string& msg) {
std::lock_guard lock(mtx_); // 锁定互斥量
messages_.push_back(msg);
std::cout << "Added: " << msg << std::endl;
}
void printMessages() {
std::lock_guard lock(mtx_); // 锁定互斥量
std::cout << "Current messages: ";
for (const auto& msg : messages_) {
std::cout << msg << " ";
}
std::cout << std::endl;
}
private:
std::vector messages_;
mutable std::mutex mtx_; // mutable 允许在 const 成员函数中修改
};
// 线程函数
void worker_thread(std::shared_ptr data_ptr, int id) {
for (int i = 0; i < 3; ++i) {
data_ptr->addMessage("Hello from thread " + std::to_string(id) + " msg " + std::to_string(i));
std::this_thread::sleep_for(std::chrono::milliseconds(10)); // 模拟工作
}
data_ptr->printMessages();
}
// int main() {
// auto shared_data = std::make_shared();
//
// std::vector threads;
// for (int i = 0; i < 3; ++i) {
// threads.emplace_back(worker_thread, shared_data, i);
// }
//
// for (auto& t : threads) {
// t.join();
// }
//
// shared_data->printMessages();
// return 0;
// }
这里，mtx_保护了messages_，确保任何时候只有一个线程能修改或读取messages_。
-
使用不可变对象（Immutable Objects）：
如果你的共享对象在创建后就不会再被修改，那么它就是天然线程安全的。这种情况下，多个线程可以同时读取它而无需任何锁。当需要“修改”时，实际上是创建一个新版本的对象，然后用std::atomic<:shared_ptr>>原子地替换掉旧的shared_ptr。这在读多写少的场景下非常高效。
#include
#include
#include
这里，std::atomic<:shared_ptr>>保证了global_config指针本身的原子替换，而ImmutableConfig内部是const的，因此读取时无需加锁。
-
使用读写锁（std::shared_mutex）：
如果你的共享对象读操作远多于写操作，std::mutex可能会导致性能瓶颈，因为它每次都完全互斥。std::shared_mutex（C++17引入）允许多个线程同时获取共享锁（用于读），但只允许一个线程获取独占锁（用于写）。
#include
#include
这能有效提升并发读取的性能。
选择哪种方式取决于你的具体场景：如果并发写入频繁，std::mutex通常是最好的选择；如果数据基本不变或更新频率很低但读取非常多，不可变对象和std::atomic<:shared_ptr>的组合会非常高效；如果读写比例差距明显，读写锁则是一个不错的平衡点。但无论如何，切记：shared_ptr不是万能药，它只管“有谁在用”，不管“在用什么”。
