当前位置：首页 > news >正文

【C++多线程编程】线程安全与对象生命周期管理

news 文章来源：https://blog.csdn.net/gma999/article/details/141981041 2025/5/18 2:00:05

类的线程安全

实现线程安全

构造函数在多线程中的安全性

析构函数多线程环境的安全

智能指针实现多线程安全

shared_ptr 非完全线程安全

shared_ptr可能导致对象生命周期延长

const引用可以减少传递shared_ptr开销

shared_ptr 智能指针块模块的优点

析构所在线程问题分析

RAII的使用

enable_shared_from_this 使用场景分析

问题分析

enable_shared_from_this确保对象安全

weak_ptr 和 shared_ptr 结合 Bind的弱回调机制（重点解决方案）

弱回调机制的实现

类的线程安全

什么是class线程安全

多线程可以同时访问类的实例：线程安全的类允许多个线程同时读取或者修改类的状态，而不会引发数据不一致的问题
线程之间交互会不会影响类的正确行为：并发环境下线程的执行顺序不可控，操作系统可能会在任意时刻调用线程，在该环境下，很容易导致其他异常行为。如果一个类的线程是安全的，那么即使多线程交互，也不会出现数据竞争和资源争夺问题
无需额外的同步操作：如果一个类是线程的安全的，那么当调用这个类的时候就不需要使用锁、互斥量或者其他同步机制来确保其安全
例如std::string std::vector std::map等类都是线程不安全的，因为调用它们的时候需要使用锁机制

线程不安全会导致的问题

数据竞争：多个线程同时修改同一块内存区域，这样会导致数据不一致的情况
崩溃或者未定义的行为：在修改数据的时候会导致该种情况的发生

实现线程安全

构造函数在多线程中的安全性

构造函数在多线程环境下安全性

不要在构造函数中注册任何回调函数
构造函数执行的时候，对象还没有初始化完成，如果在构造函数中注册了回调函数，此时可能会被其他线程调用，这样就会导致该线程访问到了一个没有初始化完成的对象，从而会导致未定义行为或数据不一致的问题
不可以在构造函数中传递this指针给其他线程
同上，对象还没有初始化完成，就将自己的this指针给其他线程使用，是一种很不安全的行为
一定要确保构造函数完成后，对象已经创建，再将对象交给其他线程操作

解决方案

延迟泄漏this：将this指针的传递放在对象构建之后。在对象创建之后可以通过初始化函数或者工厂模式将this指针传递给其他对象或者线程，从而确保构造函数执行完毕后对象才会被外界访问
使用工厂函数：通过工厂函数来创建对象，在对象初始化完成后，在返回给调用者，这样就不用直接在构造函数中暴露了

错误事例参考

#include <iostream>class Observable;class Observer {
public:virtual void update() = 0;  // 纯虚函数，用于接收更新通知
};class Foo : public Observer {
public:// 错误：在构造函数中直接注册 `this`，会造成线程不安全Foo(Observable* s) {s->registerObserver(this);  // 将 `this` 立即注册到 `Observable`std::cout << "Foo 对象已构造并注册\n";}virtual void update() override {std::cout << "Foo 收到了更新通知\n";}private:int someData = 0;  // 假设这是一个重要的初始化数据
};class Observable {
public:void registerObserver(Observer* o) {observer_ = o;std::cout << "观察者已注册\n";}void notifyObservers() {if (observer_) {observer_->update();}}private:Observer* observer_ = nullptr;
};int main() {Observable observable;Foo* foo = new Foo(&observable);  // 在构造函数中注册 `this`observable.notifyObservers();  // 通知观察者，可能在对象未完全初始化时访问delete foo;return 0;
}

正确事例实现

延迟注册：事例中通过独立的observer()方法，将this注册到observable，确保注册发色会给你在对象构造完成后，避免未完全初始化的对象被访问

#include <iostream>class Observable;class Observer {
public:virtual void update() = 0;  // 纯虚函数，用于接收更新通知
};class Foo : public Observer {
public:Foo() {// 在构造函数中仅初始化对象，不进行任何注册操作std::cout << "Foo 对象已构造\n";}// 观察者更新接口实现virtual void update() override {std::cout << "Foo 收到了更新通知\n";}// 提供一个专门的函数用于在构造后进行注册void observe(Observable* s);private:// 内部成员变量int someData = 0;
};class Observable {
public:void registerObserver(Observer* o) {observer_ = o;std::cout << "观察者已注册\n";}void notifyObservers() {if (observer_) {observer_->update();}}private:Observer* observer_ = nullptr;
};// Foo类的observe方法实现，确保注册操作在构造完成后进行
void Foo::observe(Observable* s) {s->registerObserver(this);  // 仅在对象构造后再注册
}int main() {Observable observable;Foo* foo = new Foo();  // 构造对象foo->observe(&observable);  // 构造完成后进行注册observable.notifyObservers();  // 通知观察者进行更新delete foo;return 0;
}

析构函数多线程环境的安全

多线程环境下的析构比单线程析构是更为复杂的，主要原因是因为其涉及到资源的竞争条件。如果在多线程环境下确保线程安全，析构函数必须小心处理对象的状态，同时与其他线程保持同步。

多线程环境下如何实现线程安全

避免多个线程同时读取或者写入共享状态：每个线程对共享资源的访问顺序应该是按照某种顺序执行，不可以让他们同时操作
成员函数的操作相互独立：函数的边界不应该发生重叠，也就是多个线程不应该同时访问同一块资源，每个成员函数的执行应该与其他函数隔离开，避免相互干扰

借助mutex无法解决问题事例

首先两个线程存在线程竞争：线程A在delete x之后，便将x设置成为的NULL，但是线程B在if(x)中检查了x，但是由于两个线程之间都没有同步，线程A销毁后，线程B仍然可能在销毁后访问的x，这样访问已经销毁对象，肯定会导致对应的错误
使用mutex无法解决问题原因分析：因为Mutex只可以保证函数内的互斥访问，但是不能控制线程之间的执行顺序，也就是说，销毁与执行的顺序是无法通过mutex来控制的

#include <iostream>
#include <thread>
#include <mutex>class Foo {
public:~Foo() {std::lock_guard<std::mutex> lock(mutex_);  // 互斥锁保护析构函数std::cout << "Foo 被销毁\n";}void update() {std::lock_guard<std::mutex> lock(mutex_);  // 互斥锁保护更新函数std::cout << "Foo 更新\n";}private:std::mutex mutex_;
};Foo* x = nullptr;  // 全局对象指针，多个线程共享void threadA() {delete x;      // 线程A销毁对象x = nullptr;   // 设置 x 为 NULL
}void threadB() {if (x) {       // 线程B检查 x 是否为NULLx->update();  // 如果 x 不为NULL，则调用 update()} else {std::cout << "x 是空指针\n";}
}int main() {x = new Foo();  // 初始化全局对象指针std::thread t1(threadA);  // 线程A销毁对象std::thread t2(threadB);  // 线程B调用 update()t1.join();t2.join();return 0;
}

mutex不仅不可以保证对象析构的线程安全，还有可能导致死锁问题

mutex作为类成员具有局限性
mutex可以保护对象中其他数据成员的读写，但是不能保护对象析构过程
由于mutex的生命周期与对象是关联的，也就是说对象如果销毁了，那么mutex也会被销毁，所以无法去为析构的时候提供保护
死锁
多个线程对多个对象进行操作的时候，如果锁的顺序不一致，这样就会导致死锁，例如线程A锁定对象a，线程B锁定对象b，双方互相等待对象释放锁的情况下，就会导致死锁

智能指针实现多线程安全

shared_ptr / weak_ptr联合使用保证其线程安全

引用计数的线程安全：因为两个指针都是采用原子操作的方式来维护引用计数的，因此可以保证多个线程同时增加或者的减少引用计数时的线程安全
访问控制：利用weak_ptr检查对象是否仍然存在，如果存在则将其提升为shared_ptr进行访问，从而确保对象在销毁前的安全访问

事例代码

通过shared_ptr 实现自动管理对象的生命周期，确保多线程对同一个对象的安全访问
使用weak_ptr避免延长对象的生命周期，与此同时使用lock()来提供安全的对象访问机制，防止访问到已经销毁的对象

#include <iostream>
#include <memory>
#include <thread>std::shared_ptr<int> globalPtr;  // 全局 shared_ptrvoid threadFunc() {std::shared_ptr<int> localPtr = globalPtr;  // 安全地共享对象if (localPtr) {std::cout << "Thread accessing: " << *localPtr << std::endl;}
}int main() {globalPtr = std::make_shared<int>(42);  // 初始化 shared_ptrstd::thread t1(threadFunc);std::thread t2(threadFunc);t1.join();t2.join();globalPtr.reset();  // 主线程释放对象，其他线程仍然安全使用return 0;
}

shared_ptr 非完全线程安全

不能完全保证线程安全原因分析

引用计数线程安全：因为其引用计数是通过原子操作来实现的，也就是说多个线程可以安全的增减计数，不会竞争；同时只要还存在一个shared_ptr指向某个对象，该对象的内存就不会被释放
无法保证管理对象的线程安全：多线程可以安全的访问同一个shared_ptr，但是这些线程访问和修改对象的时候可能会导致数据不一致问题，例如一个线程正在写入对象，另一个线程也正在读取或者写入的时候，此时就会产生数据竞争的情况
读写冲突问题
同时读取，此时通过计数是线程安全的
同时写入，除非对象在写的时候进行了加锁，否则是线程不安全的
读写冲突：一个读一个写，可能会导致最后数据不一致的问题

事例，通过互斥锁来保证多线程访问对象的安全性

#include <iostream>
#include <memory>
#include <thread>
#include <mutex>std::shared_ptr<int> globalPtr;
std::mutex mtx;void readSharedPtr() {std::lock_guard<std::mutex> lock(mtx);if (globalPtr) {std::cout << "Reading: " << *globalPtr << std::endl;}
}void writeSharedPtr(int value) {std::lock_guard<std::mutex> lock(mtx);if (globalPtr) {*globalPtr = value;std::cout << "Writing: " << value << std::endl;}
}int main() {globalPtr = std::make_shared<int>(42);std::thread t1(readSharedPtr);std::thread t2(writeSharedPtr, 100);t1.join();t2.join();return 0;
}

shared_ptr可能导致对象生命周期延长

shared_ptr是引用计数的智能指针，引用计数决定的对象的生命周期，但是使用过程中如果有一个指向该对象的指针没有析构，这样就会导致该对象永远不会被释放。

shared_ptr与回调函数

观察者设计模式中，如果通过shared_ptr来管理管理者对象，同时将这些对象放入vector容器中，此时如果不能够正确管理这些观察者对象，就可能会导致对象无法被释放
也就是说，如果没有手动的调用unregistyer()来将其从容器中移除shared_ptr，这些对象就会始终存放在容器中，引用计数是始终不会归零的，这样一来，对象的析构函数也就不会被调用，从而引发内存泄漏

boost::bind与shared_ptr导致问题

利用bind进行回调的时候，bind此时会持有一个shared_ptr的副本，所以会使得对象的引用计数增加，这也就意味着，只要回调函数仍然存在，该对象的引用计数也就永远不会归零，对象的生命周期也就会被无限延长
例如，如果将一个shared_ptr绑定的一个函数中，该指针的副本会一直存在，直到该函数销毁为止

事例理解

将oberver1绑定到function中，这样就导致了observer1的生命周期延长
即使移除了它，但还是不会立即销毁，只有等到function销毁的时候，observer1才会被销毁

#define BOOST_BIND_GLOBAL_PLACEHOLDERS 
#include <iostream>
#include <vector>
#include <memory>
#include <boost/bind.hpp>
#include <boost/function.hpp>class Observer {
public:Observer(int id) : id_(id) {std::cout << "Observer " << id_ << " created." << std::endl;}~Observer() {std::cout << "Observer " << id_ << " destroyed." << std::endl;}void onNotify() {std::cout << "Observer " << id_ << " notified." << std::endl;}private:int id_;
};class Subject {
public:void registerObserver(std::shared_ptr<Observer> obs) {observers_.push_back(obs);  // 使用 shared_ptr 存储观察者}void unregisterObserver(std::shared_ptr<Observer> obs) {observers_.erase(std::remove(observers_.begin(), observers_.end(), obs), observers_.end());}void notifyAll() {for (auto& obs : observers_) {if (obs) {obs->onNotify();}}}private:std::vector<std::shared_ptr<Observer>> observers_;
};void delayedCallback(boost::function<void()> func) {std::cout << "Callback will be called after delay..." << std::endl;func();  // 延迟回调调用
}int main() {Subject subject;// 创建两个观察者并注册std::shared_ptr<Observer> observer1(new Observer(1));std::shared_ptr<Observer> observer2(new Observer(2));subject.registerObserver(observer1);subject.registerObserver(observer2);// 这里的 boost::bind 使 shared_ptr 的引用计数增加boost::function<void()> func = boost::bind(&Observer::onNotify, observer1);// 执行延迟回调delayedCallback(func);// 移除观察者subject.unregisterObserver(observer1);subject.unregisterObserver(observer2);// 通知所有观察者subject.notifyAll();// 注意：observer1 的引用计数不会为 0，因为 boost::function 持有了它的 shared_ptr 副本return 0;
}

const引用可以减少传递shared_ptr开销

const引用减少开销的原因

如果直接拷贝会增加引用计数，也就是说shared_ptr的引用计数会增加
使用const 引用的方式则不会增加计数，这样就减少了锁的开销

void onMessage(const std::string& msg) {std::shared_ptr<Foo> pFoo(new Foo(msg));  // 创建 shared_ptr，持有 Foo 实例if (validate(pFoo)) {  // 通过 const 引用传递 shared_ptrsave(pFoo);        // 通过 const 引用传递 shared_ptr}
}

shared_ptr 智能指针块模块的优点

优点

减少析构函数调用次数：因为使用shared_ptr可以自动管理对象的生命周期，不需要用户调用析构函数，所以就减少的开销
shared_ptr可以指向任意类型的对象
能够管理复杂对象的生命周期
二进制兼容性：即使对象大小改变，旧的客户端代码依然可以兼容新版本的动态库

析构所在线程问题分析

在多线程环境下，最后拥有对象的线程不一定是初始线程，所以需要该处对最后析构线程进行分析。

析构线程不一定是初始化线程：资源释放的时机是在shared_ptr离开作用域的时候发生，也就是说在shared_ptr的析构函数会自动调用该对象的析构函数，但是这个析构动作发生的线程不一定是创建该对象的线程，因为对象的生命周期跨越了多个线程
析构发生在最后持有shared_ptr的线程：加入最后执行析构的是主线程，那么后续行为的执行，需要等待主线程执行完析构，此时就会影响性能，因为对一个对象的析构是一种十分耗时的行为
主线程析构问题解决思路：设计一些线程专门负责去析构对象，实现的话可以通过一个队列，将需要析构的对象都放入队列中，这样就不会影响主线程执行

RAII的使用

涉及到资源管理必然不可以绕开RAII，RAII的核心思想就是在对象构建的时候同时获取资源，并在对象销毁的时候同时释放资源。

避免手动释放资源：程序中如何频繁的使用new，那么就要频繁的使用delete去手动释放资源，仅仅依靠自己手动释放资源，是很容易出错的。所以要采用RAII通过自动化管理资源来减少这种错误，例如在程序中多使用shared_ptr，在其超出作用域时候自动释放其管理资源
RAII管理共享资源：shared_ptr通过应用计数来确保对象的生命周期，确保没有任何shared_ptr持有对象的时候才释放资源。该种方式在多线程下十分适用，多线程中使用shared_ptr来共享对象，不需要手动管理对象的释放。
避免循环引用：在使用RAII管理资源的时候，最重要的是需要避免循环引用的情况，循环引用也就是会让引用计数永远不为零，最终引发内存泄漏。在该情况下，可以通过weak_ptr来打破循环引用，因为weak_ptr是不会影响计数的，其类似于一个不拥有对象的观察者，通过weak_ptr.lock()提升为weak_ptr，从而安全的访问对象

#include <iostream>
#include <memory>
#include <thread>
#include <chrono>
#include <queue>
#include <mutex>
#include <condition_variable>// 资源类，构造时分配资源，析构时释放资源
class Resource {
public:Resource() {std::cout << "资源已获取\n";}~Resource() {std::cout << "资源已释放\n";}
};// 模拟处理资源的函数
void processResource(std::shared_ptr<Resource> res) {std::this_thread::sleep_for(std::chrono::seconds(1)); // 模拟处理延迟std::cout << "正在处理资源\n";
}// 阻塞队列类，用于在线程间传递资源
template <typename T>
class BlockingQueue {
public:// 向队列中添加资源void push(T item) {std::lock_guard<std::mutex> lock(mtx);queue.push(item);cond.notify_one(); // 唤醒等待的线程}// 从队列中取出资源T pop() {std::unique_lock<std::mutex> lock(mtx);cond.wait(lock, [this]() { return !queue.empty(); }); // 等待直到队列非空T item = queue.front();queue.pop();return item;}private:std::queue<T> queue;std::mutex mtx;std::condition_variable cond;
};// 专用线程，处理资源的析构
void workerThread(BlockingQueue<std::shared_ptr<Resource>>& queue) {while (true) {auto res = queue.pop(); // 从队列中获取资源processResource(res);   // 处理资源// 资源会在这里自动析构}
}int main() {// 创建阻塞队列和专用线程BlockingQueue<std::shared_ptr<Resource>> queue;std::thread worker(workerThread, std::ref(queue));// 主线程分配资源并将其传递给专用线程{auto res = std::make_shared<Resource>(); // 使用shared_ptr分配资源queue.push(res); // 将资源传递给队列，worker线程将接管资源}worker.join(); // 等待专用线程结束return 0;
}

enable_shared_from_this 使用场景分析

问题分析

当使用智能指针来管理对象的生命周期，智能指针会自动管理对象资源的分配和释放，从而避免内存泄漏。但是在某些情况下，智能指针所管理的对象需要在其成员函数内存获取一个指向自身的shared_ptr。在这种情况下如果直接使用this指针操作，可能会导致严重的生命周期管理的问题，尤其在回调函数以及多线程环境下，该问题会更明显，结合下面的事例详细理解。

要点解释说明

Manner类：通过继承enable_shared_this，允许在Message类中获取自身shared_ptr指针，同时通过deleteResource()方法，模拟删除资源的操作
Resource类：该类持有一个指向Manner的指针，在资源创建的时候，就将销毁资源的函数绑定为析构时的回到函数。资源被销毁的时候，这个回调函数会自动被调用
生命周期管理：通过shared_ptr 确保Manner的生命周期延长（重点理解）
也就是在Resource的析构函数中，通过使用manager的shared_ptr调用Manner的deleteResource()方法，从而保证在回调执行的时候，Manner对象依然有效

调试内容+源码

#include <iostream>
#include <memory>
#include <functional>class Manager : public std::enable_shared_from_this<Manager> {
public:// 模拟删除资源的函数void deleteResource() {std::cout << "Manager: Deleting resource\n";}// 返回当前对象的shared_ptrstd::shared_ptr<Manager> getSharedManager() {return shared_from_this();}
};class Resource {
public:Resource(std::shared_ptr<Manager> mgr) : manager(mgr) {std::cout << "Resource Created\n";// 绑定析构时的回调函数，调用Manager的deleteResource函数destructorCallback = std::bind(&Manager::deleteResource, manager);}~Resource() {std::cout << "Resource Destroyed\n";// 调用析构回调，通知ManagerdestructorCallback();}private:std::shared_ptr<Manager> manager;std::function<void()> destructorCallback;
};int main() {// 创建一个Manager对象并使用shared_ptr管理其生命周期std::shared_ptr<Manager> manager = std::make_shared<Manager>();{// 创建Resource对象，并将Manager传递给它std::shared_ptr<Resource> resource = std::make_shared<Resource>(manager);} // Resource在此作用域结束时被销毁，其析构函数被调用std::cout << "End of main\n";return 0;
}

enable_shared_from_this确保对象安全

解决上述问题，则是通过C++中提供的一个enable_shared_from_this机制来实现，其是一个模版基类，允许类的实例从其成员函数中安全的获取shared_ptr执行自身，最终实现该对象的生命周期始终是由shared_ptr来控制的。

工作原理分析

继承enable_shared_from_this：其是一个模版类，提供了一个shared_from_this()方法，允许类的成员函数获取一个指向该类对象的shared_ptr，只要当该对象被shared_ptr管理的时候，shared_from_this（）才是有效的
确保生命周期延长（重点）：当对象通过shared_ptr进行管理的时候，调用shared_from_this（）可以确保即使所有其他地方持有shared_Ptr对象都被销毁，当前对象也仍然有效。这也就是说，成员函数或者回调函数使用该对象的时候，程序可以确保该对象不会在使用的时候销毁.
注意：其他地方的shared_ptr对象销毁的时候，指针引用计数不会变成0的，因为本对象中通过shared_from_this创建了一个新的shared_ptr，所以该对象不会被销毁。

代码事例理解

#include <iostream>
#include <memory>class Manager : public std::enable_shared_from_this<Manager> {
public:Manager() {std::cout << "Manager Created\n";}~Manager() {std::cout << "Manager Destroyed\n";}// 返回自身的 shared_ptrstd::shared_ptr<Manager> getSharedPtr() {return shared_from_this();}void performTask() {// 在成员函数内部获取 shared_ptrauto sharedManager = shared_from_this();std::cout << "Performing task with shared_ptr\n";// 在这里 shared_ptr 的引用计数不会变成 0，因为还有其他地方持有它}
};int main() {// Step 1: 创建一个 shared_ptr 管理 Manager 对象std::shared_ptr<Manager> manager1 = std::make_shared<Manager>();std::cout << "Reference Count after creation: " << manager1.use_count() << "\n"; // 引用计数为 1// Step 2: 调用成员函数，获取 shared_ptrmanager1->performTask();std::cout << "Reference Count after performTask: " << manager1.use_count() << "\n"; // 引用计数为 1，因为没有新增外部持有者// Step 3: 在外部再获取一个 shared_ptrstd::shared_ptr<Manager> manager2 = manager1->getSharedPtr();std::cout << "Reference Count after getSharedPtr: " << manager1.use_count() << "\n"; // 引用计数为 2// Step 4: 销毁 manager1manager1.reset(); std::cout << "Reference Count after resetting manager1: " << manager2.use_count() << "\n"; // 引用计数为 1// Step 5: 销毁 manager2manager2.reset();std::cout << "All shared_ptrs destroyed\n";return 0;
}

weak_ptr 和 shared_ptr 结合 Bind的弱回调机制（重点解决方案）

弱回调机制的实现

实现机制分析

将shared_ptr绑定到bind和function中的时候，其会延长绑定对象的生命周期，也就是说只有绑定的function对象销毁的时候，该指针才会销毁。通过该种方式保证了对象在回调的时候是安全，但是相应的会导致对象生命周期会比预期的更长
弱回调的核心思想：避免对象的生命周期过度延长，希望当对象存在的时候，可以正常的执行回调函数；如果对象销毁了，则不再执行回调
避免强引用带来的生命周期延长问题，则是通过weak_ptr

具体实现

weak_ptr
不参与引用计数，主要就是用来打破shared_ptr的循环引用问题
当worker完成任务后，通过weak_ptr::lock（）检查Manner是否还存在，同时根据结果来决定是否通知Manner
生命周期管理：利用weak_ptr::lock（）检查Manner是否还存在，如果对象被销毁，则lock（）则返回空指针，从而避免对已经销毁对象的访问

事例代码执行流程分析

Manner类
通过继承enable_shared_from_this，让worker对象可以获取shared_ptr<Manner>，并在执行任务完成后通知后通知Manner

#include <iostream>
#include <memory>
#include <vector>// 前置声明 Manager 类
class Manager;// Worker 类负责执行任务，并在任务完成时通知 Manager
class Worker {
public:// 构造函数中传入 Manager 的 weak_ptrWorker(std::weak_ptr<Manager> manager);~Worker();// 执行任务void doWork();private:// 使用 weak_ptr 避免循环引用std::weak_ptr<Manager> manager_;// 通知 Manager 任务已完成void notifyManager();
};// Manager 类负责管理 Worker
class Manager : public std::enable_shared_from_this<Manager> {
public:Manager() {std::cout << "Manager Created\n";}~Manager() {std::cout << "Manager Destroyed\n";}// 注册 worker 完成任务的回调函数void registerWorker() {auto worker = std::make_shared<Worker>(shared_from_this());workers_.push_back(worker);worker->doWork();}void onTaskComplete() {std::cout << "Manager received task completion notification\n";}private:std::vector<std::shared_ptr<Worker>> workers_;
};// 完整定义 Worker 类的方法
Worker::Worker(std::weak_ptr<Manager> manager): manager_(manager) {std::cout << "Worker Created\n";
}Worker::~Worker() {std::cout << "Worker Destroyed\n";
}void Worker::doWork() {std::cout << "Worker is working...\n";// 模拟任务完成后通知 ManagernotifyManager();
}void Worker::notifyManager() {if (auto manager = manager_.lock()) {// manager 有效时通知manager->onTaskComplete();} else {// 如果 Manager 已销毁，通知失败std::cout << "Manager is no longer available\n";}
}int main() {{// 创建一个 Manager 对象并用 shared_ptr 管理auto manager = std::make_shared<Manager>();// 注册 Worker 并执行任务manager->registerWorker();std::cout << "Manager still exists\n";}// 当 Manager 销毁后，Worker 再次尝试访问 Manager 将失败std::cout << "End of main\n";return 0;
}

总结

weak_ptr 和 shared_ptr 与 bind相结合实现弱回调机制，解决对象相互引用导致的生命周期问题
weak_ptr弱化对象的引用，如果对象还存在则执行回调，如果对象不存在在不执行回调，从而保证系统的稳定性和安全性

类的线程安全

实现线程安全

构造函数在多线程中的安全性

析构函数多线程环境的安全

智能指针实现多线程安全

shared_ptr 非完全线程安全

shared_ptr可能导致对象生命周期延长

const引用可以减少传递shared_ptr开销

shared_ptr 智能指针块模块的优点

析构所在线程问题分析

RAII的使用

enable_shared_from_this 使用场景分析

问题分析

enable_shared_from_this确保对象安全

weak_ptr 和 shared_ptr 结合 Bind的弱回调机制（重点解决方案）

弱回调机制的实现

相关文章：