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> 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 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 printMessages();// return 0;// }
这里，mtx_保护了messages_，确保任何时候只有一个线程能修改或读取messages_。
使用不可变对象（Immutable Objects）：如果你的共享对象在创建后就不会再被修改，那么它就是天然线程安全的。这种情况下，多个线程可以同时读取它而无需任何锁。当需要“修改”时，实际上是创建一个新版本的对象，然后用std::atomic>原子地替换掉旧的shared_ptr。这在读多写少的场景下非常高效。
#include #include #include
这里，std::atomic>保证了global_config指针本身的原子替换，而ImmutableConfig内部是const的，因此读取时无需加锁。
使用读写锁（std::shared_mutex）：如果你的共享对象读操作远多于写操作，std::mutex可能会导致性能瓶颈，因为它每次都完全互斥。std::shared_mutex（C++17引入）允许多个线程同时获取共享锁（用于读），但只允许一个线程获取独占锁（用于写）。
#include #include
这能有效提升并发读取的性能。
选择哪种方式取决于你的具体场景：如果并发写入频繁，std::mutex通常是最好的选择；如果数据基本不变或更新频率很低但读取非常多，不可变对象和std::atomic的组合会非常高效；如果读写比例差距明显，读写锁则是一个不错的平衡点。但无论如何，切记：shared_ptr不是万能药，它只管“有谁在用”，不管“在用什么”。
以上就是shared_ptr的线程安全性如何 多线程读写共享对象的正确方式的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1467651.html
微信扫一扫 
支付宝扫一扫 
