shared_ptr在多线程环境下的核心要点是：1. shared_ptr的引用计数操作是原子且线程安全的，确保其生命周期管理不会出错；2. 但它所指向的对象内部数据并非线程安全，若对象状态在多线程中被并发修改，需额外同步机制如mutex保护；3. 可使用std::atomic<shared_ptr<t>>实现shared_ptr实例本身的原子替换，但这不解决对象内部数据的竞争问题；4. 推荐策略包括封装同步逻辑、设计不可变对象、避免从this创建shared_ptr、谨慎使用裸指针和weak_ptr，并优先减少共享可变状态。
在多线程环境下使用 shared_ptr，核心要点是：shared_ptr 本身对引用计数的增减操作是原子且线程安全的，但这不意味着它所指向的那个对象内部的数据访问也是线程安全的。如果你要修改 shared_ptr 管理的对象，或者这个对象内部的状态会在多线程中被访问，那么你仍然需要额外的同步机制来保护这个对象。
理解 shared_ptr 在多线程中的行为，关键在于区分“管理 shared_ptr 自身的生命周期”和“管理 shared_ptr 所指向的数据”。shared_ptr 的控制块（包含引用计数和弱引用计数）的操作，如复制、赋值、销毁等，都是由 C++ 标准库保证原子性的。这意味着在多个线程同时对同一个 shared_ptr 实例进行拷贝或销毁时，引用计数不会出现竞争条件，从而避免了双重释放或提前释放的问题。
然而，这种原子性仅限于 shared_ptr 的内部管理机制。它所指向的实际数据（T类型的对象）的读写操作，如果发生在多个线程之间，并且其中至少有一个是写入操作，那么这就构成了数据竞争。为了保护这些共享数据，你需要显式地引入同步原语，比如 std::mutex、读写锁，或者设计不可变（immutable）的数据结构。
对于 shared_ptr 实例本身的原子替换，即在一个共享变量中原子地更新 shared_ptr 指向另一个对象，可以使用 std::atomic<std::shared_ptr<T>>。但这只解决了指针本身替换的原子性，不解决被指向对象内部数据的线程安全问题。
shared_ptr的引用计数是线程安全的吗？深入理解其内部机制是的，shared_ptr 的引用计数操作是线程安全的。这是 C++ 标准库为 shared_ptr 设计时就明确规定的行为。当我们复制一个 shared_ptr（例如通过拷贝构造函数或赋值操作符），或者一个 shared_ptr 离开作用域被销毁时，其内部的引用计数会相应地原子增加或减少。
具体来说，标准库的实现通常会利用底层平台的原子指令（如 fetch_add、fetch_sub 或等效的锁指令）来操作引用计数。这确保了即使多个线程同时对同一个 shared_ptr 进行操作，引用计数器也能保持正确的值，从而避免了因计数错误导致的内存泄漏（引用计数永远不为零）或提前释放（引用计数过早归零导致多个 shared_ptr 访问已释放内存）。
我个人觉得，这里有个非常容易被误解的地方：很多人会因为“引用计数线程安全”就直接推断出“整个 shared_ptr 及其指向的对象都是线程安全的”，这绝对是个大坑。引用计数的安全仅仅是保证了 shared_ptr 自身的生命周期管理不出错，和它指向的那个 T 类型的对象的内部状态完全是两码事。你可以想象成 shared_ptr 是个保险箱，它自己开关锁是安全的，但保险箱里的钱（你的数据）会不会被偷走，取决于你有没有给钱再加把锁。
shared_ptr指向的数据？既然 shared_ptr 无法自动保护它所指向的对象，那么当多个线程需要访问或修改这个共享对象时，我们就需要主动介入。这通常是多线程编程中最核心也是最容易出错的部分。
保护 shared_ptr 指向的数据，有几种常用的策略：
使用互斥锁（std::mutex）进行同步： 这是最直接、最常见的做法。你可以在 shared_ptr 所管理的对象内部封装一个 std::mutex，或者在外部创建一个 std::mutex 来保护对该对象的访问。
内部封装： 推荐这种方式，因为它将数据和其保护机制紧密绑定在一起，形成一个“线程安全对象”。
#include <iostream>
#include <memory>
#include <mutex>
#include <string>
#include <vector>
#include <thread>
#include <chrono>
class SharedResource {
public:
SharedResource(const std::string& name) : name_(name), value_(0) {
std::cout << "Resource " << name_ << " created." << std::endl;
}
~SharedResource() {
std::cout << "Resource " << name_ << " destroyed." << std::endl;
}
void incrementValue() {
std::lock_guard<std::mutex> lock(mtx_); // 锁定互斥量
value_++;
std::cout << name_ << ": Value incremented to " << value_ << std::endl;
}
int getValue() const {
std::lock_guard<std::mutex> lock(mtx_); // 读操作也需要保护，防止读到脏数据
return value_;
}
private:
std::string name_;
int value_;
mutable std::mutex mtx_; // mutable 允许在 const 成员函数中修改
};
// 示例用法：
// std::shared_ptr<SharedResource> res = std::make_shared<SharedResource>("MyData");
// std::thread t1([&]{ for(int i=0; i<5; ++i) res->incrementValue(); });
// std::thread t2([&]{ for(int i=0; i<5; ++i) res->incrementValue(); });
// t1.join();
// t2.join();
// std::cout << "Final value: " << res->getValue() << std::endl;这种方式让 SharedResource 对象本身就是线程安全的，无论它是否被 shared_ptr 管理，其内部操作都能保证同步。
设计不可变（Immutable）对象： 如果你所共享的对象在创建后就不会再被修改，那么它就是天然线程安全的。shared_ptr 非常适合用来共享这样的不可变数据。这是并发编程中一种非常强大的模式，因为它完全消除了数据竞争的可能性。
#include <iostream>
#include <memory>
#include <string>
#include <vector>
#include <thread>
class ImmutableConfig {
public:
ImmutableConfig(int version, const std::string& data) : version_(version), data_(data) {}
int getVersion() const { return version_; }
const std::string& getData() const { return data_; }
// 没有修改成员变量的方法，因此是不可变的
private:
int version_;
std::string data_;
};
// 示例用法：
// std::shared_ptr<const ImmutableConfig> config = std::make_shared<ImmutableConfig>(1, "Initial Settings");
// std::thread t1([&]{ std::cout << "Thread 1 config version: " << config->getVersion() << std::endl; });
// std::thread t2([&]{ std::cout << "Thread 2 config data: " << config->getData() << std::endl; });
// t1.join();
// t2.join();在这种情况下，shared_ptr<const T> 是一个很好的选择，它明确表示你无法通过这个指针修改对象。
使用 std::atomic<std::shared_ptr<T>>： 这不是用来保护 shared_ptr 指向的数据，而是用来原子地替换 shared_ptr 本身。如果你有一个 shared_ptr 变量，并且希望在多线程中原子地改变它所指向的对象（比如，更新一个全局配置指针），那么 std::atomic<std::shared_ptr<T>> 就派上用场了。
#include <iostream>
#include <memory>
#include <atomic>
#include <thread>
#include <chrono>
class MyObject {
public:
MyObject(int id) : id_(id) { std::cout << "MyObject " << id_ << " created." << std::endl; }
~MyObject() { std::cout << "MyObject " << id_ << " destroyed." << std::endl; }
int getId() const { return id_; }
private:
int id_;
};
std::atomic<std::shared_ptr<MyObject>> global_object_ptr;
void reader_thread() {
for (int i = 0; i < 3; ++i) {
std::shared_ptr<MyObject> current_obj = global_object_ptr.load(); // 原子加载
if (current_obj) {
std::cout << "Reader: Current object ID is " << current_obj->getId() << std::endl;
} else {
std::cout << "Reader: No object available." << std::endl;
}
std::this_thread::sleep_for(std::chrono::milliseconds(50));
}
}
void writer_thread() {
for (int i = 0; i < 2; ++i) {
std::this_thread::sleep_for(std::chrono::milliseconds(100));
std::shared_ptr<MyObject> new_obj = std::make_shared<MyObject>(i + 100);
global_object_ptr.store(new_obj); // 原子存储
std::cout << "Writer: Updated object to ID " << new_obj->getId() << std::endl;
}
}
// 示例用法：
// global_object_ptr.store(std::make_shared<MyObject>(0)); // 初始值
// std::thread t_reader(reader_thread);
// std::thread t_writer(writer_thread);
// t_reader.join();
// t_writer.join();这里需要强调的是，std::atomic<std::shared_ptr<T>> 保证的是 global_object_ptr 这个变量本身的读写原子性，即保证在多线程环境下，对 global_object_ptr 进行 load() 或 store() 操作时，不会出现撕裂（torn reads/writes）。但是，一旦你通过 load() 获得了 std::shared_ptr<MyObject> 的副本 current_obj，那么对 current_obj 所指向的 MyObject 内部的任何修改，仍然需要 MyObject 自身来保证线程安全。
shared_ptr多线程陷阱与最佳实践在多线程中使用 shared_ptr，有些坑是新手很容易踩的，甚至经验丰富的开发者也可能一时疏忽。
陷阱：误认为 shared_ptr 赋予了对象线程安全。
这大概是最常见也最危险的误解了。我前面反复强调，shared_ptr 提供的线程安全仅限于其内部的引用计数操作。它不提供对所管理对象的任何同步保证。如果你有一个 shared_ptr<Foo>，并且 Foo 对象内部有成员变量会被多个线程同时读写，你必须为 Foo 的成员变量访问添加锁。
陷阱：从 this 创建 shared_ptr。
在一个类成员函数内部，如果你想获取当前对象的 shared_ptr，绝不能直接 std::shared_ptr<MyClass>(this)。这会导致创建出第二个独立的控制块，当这两个 shared_ptr 都认为自己是最后一个持有者时，就会发生双重释放（double free）的灾难。
最佳实践： 继承 std::enable_shared_from_this<T>。
#include <memory>
#include <iostream>
class MyClass : public std::enable_shared_from_this<MyClass> {
public:
std::shared_ptr<MyClass> getSharedPtr() {
return shared_from_this(); // 正确获取指向自身的 shared_ptr
}
};
// std::shared_ptr<MyClass> obj = std::make_shared<MyClass>();
// std::shared_ptr<MyClass> another_obj_ptr = obj->getSharedPtr(); // 安全记住，shared_from_this() 只有在对象已经被 shared_ptr 管理后才能安全调用。
陷阱：在 shared_ptr 生命周期之外使用其内部的裸指针。
如果你从 shared_ptr 中获取一个裸指针（例如 shared_ptr.get()），然后 shared_ptr 实例本身被销毁了（比如它是一个局部变量，函数返回了），那么它所指向的对象就会被释放。此时你手里的裸指针就成了悬空指针。在多线程环境下，这更是难以追踪的 bug。
最佳实践： 尽量直接使用 shared_ptr 实例本身，而不是频繁地 get() 裸指针。如果确实需要裸指针，确保其生命周期不会超过 shared_ptr 所管理对象的生命周期。
陷阱：weak_ptr 的误用导致竞态。weak_ptr 常常用来解决 shared_ptr 的循环引用问题。你可以从 weak_ptr 尝试 lock() 得到一个 shared_ptr。如果对象已经被销毁，lock() 会返回一个空的 shared_ptr。在多线程中，你可能会先检查 weak_ptr.expired()，然后尝试 lock()。但 expired() 和 lock() 之间可能存在竞态，对象可能在你检查完 expired() 之后但在 lock() 之前被销毁。
最佳实践： 总是直接尝试 lock() weak_ptr，并检查返回的 shared_ptr 是否为空。
std::shared_ptr<MyObject> obj_ptr = weak_obj_ptr.lock(); // 尝试锁定
if (obj_ptr) {
// 对象仍然存在，可以安全使用 obj_ptr
obj_ptr->doSomething();
} else {
// 对象已销毁
std::cout << "Object already expired." << std::endl;
}最佳实践：封装同步逻辑。
如果你的对象需要在多线程中被修改，最优雅的方式是让对象自己负责其内部数据的同步。这意味着在对象的成员函数中加入 std::mutex 或其他同步机制，而不是让外部代码来管理锁。这使得对象的使用者无需关心其内部的线程安全细节。
最佳实践：优先使用不可变数据。
如果业务逻辑允许，设计不可变的对象。一旦创建，其内部状态永不改变。这样，你就可以在多线程中自由地共享 shared_ptr<const T>，完全无需担心数据竞争。这大大简化了并发编程的复杂性。
最佳实践：最小化共享的可变状态。
这是并发编程的黄金法则。你共享的可变状态越少，你需要处理的同步问题就越少。shared_ptr 固然方便，但它也意味着你正在共享所有权。在设计系统时，多考虑如何减少这种共享的可变性。
总的来说，shared_ptr 是一个强大的工具，但它并非万能的银弹。在多线程环境中，你需要清晰地理解它所提供的保障和未提供的保障，并在此基础上，结合适当的同步机制和设计模式，才能写出健壮、高效的并发程序。
以上就是多线程环境下如何使用shared_ptr 原子操作与线程安全保证的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
广告
收藏
收藏
收藏
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
692
