目录
[shared_ptr 非完全线程安全](#shared_ptr 非完全线程安全)
[shared_ptr 智能指针块模块的优点](#shared_ptr 智能指针块模块的优点)
[enable_shared_from_this 使用场景分析](#enable_shared_from_this 使用场景分析)
[weak_ptr 和 shared_ptr 结合 Bind的弱回调机制(重点解决方案)](#weak_ptr 和 shared_ptr 结合 Bind的弱回调机制(重点解决方案))
类的线程安全
什么是class线程安全
**多线程可以同时访问类的实例:**线程安全的类允许多个线程同时读取或者修改类的状态,而不会引发数据不一致的问题
**线程之间交互会不会影响类的正确行为:**并发环境下线程的执行顺序不可控,操作系统可能会在任意时刻调用线程,在该环境下,很容易导致其他异常行为。如果一个类的线程是安全的,那么即使多线程交互,也不会出现数据竞争和资源争夺问题
**无需额外的同步操作:**如果一个类是线程的安全的,那么当调用这个类的时候就不需要使用锁、互斥量或者其他同步机制来确保其安全
例如std::string std::vector std::map等类都是线程不安全的,因为调用它们的时候需要使用锁机制
线程不安全会导致的问题**数据竞争:**多个线程同时修改同一块内存区域,这样会导致数据不一致的情况
**崩溃或者未定义的行为:**在修改数据的时候会导致该种情况的发生
实现线程安全
构造函数在多线程中的安全性
构造函数在多线程环境下安全性
- 不要在构造函数中注册任何回调函数
- 构造函数执行的时候,对象还没有初始化完成,如果在构造函数中注册了回调函数,此时可能会被其他线程调用,这样就会导致该线程访问到了一个没有初始化完成的对象,从而会导致未定义行为或数据不一致的问题
- 不可以在构造函数中传递this指针给其他线程
- 同上,对象还没有初始化完成,就将自己的this指针给其他线程使用,是一种很不安全的行为
- 一定要确保构造函数完成后,对象已经创建,再将对象交给其他线程操作
解决方案
- **延迟泄漏this:**将this指针的传递放在对象构建之后。在对象创建之后可以通过初始化函数或者工厂模式将this指针传递给其他对象或者线程,从而确保构造函数执行完毕后对象才会被外界访问
- **使用工厂函数:**通过工厂函数来创建对象,在对象初始化完成后,在返回给调用者,这样就不用直接在构造函数中暴露了
错误事例参考
cpp
#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,确保注册发色会给你在对象构造完成后,避免未完全初始化的对象被访问
cpp
#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来控制的
cpp
#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 是否为NULL
x->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()来提供安全的对象访问机制,防止访问到已经销毁的对象
cpp
#include <iostream>
#include <memory>
#include <thread>
std::shared_ptr<int> globalPtr; // 全局 shared_ptr
void 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_ptr
std::thread t1(threadFunc);
std::thread t2(threadFunc);
t1.join();
t2.join();
globalPtr.reset(); // 主线程释放对象,其他线程仍然安全使用
return 0;
}
shared_ptr 非完全线程安全
不能完全保证线程安全原因分析
- **引用计数线程安全:**因为其引用计数是通过原子操作来实现的,也就是说多个线程可以安全的增减计数,不会竞争;同时只要还存在一个shared_ptr指向某个对象,该对象的内存就不会被释放
- **无法保证管理对象的线程安全:**多线程可以安全的访问同一个shared_ptr,但是这些线程访问和修改对象的时候可能会导致数据不一致问题,例如一个线程正在写入对象,另一个线程也正在读取或者写入的时候,此时就会产生数据竞争的情况
- 读写冲突问题
- 同时读取,此时通过计数是线程安全的
- 同时写入,除非对象在写的时候进行了加锁,否则是线程不安全的
- 读写冲突:一个读一个写,可能会导致最后数据不一致的问题
事例,通过互斥锁来保证多线程访问对象的安全性
cpp
#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才会被销毁
cpp
#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 引用的方式则不会增加计数,这样就减少了锁的开销
cpp
void onMessage(const std::string& msg) {
std::shared_ptr<Foo> pFoo(new Foo(msg)); // 创建 shared_ptr,持有 Foo 实例
if (validate(pFoo)) { // 通过 const 引用传递 shared_ptr
save(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,从而安全的访问对象
cpp
#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对象依然有效
调试内容+源码
cpp
#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_ptr
std::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";
// 调用析构回调,通知Manager
destructorCallback();
}
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,所以该对象不会被销毁。
代码事例理解
cpp
#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_ptr
std::shared_ptr<Manager> getSharedPtr() {
return shared_from_this();
}
void performTask() {
// 在成员函数内部获取 shared_ptr
auto 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_ptr
manager1->performTask();
std::cout << "Reference Count after performTask: " << manager1.use_count() << "\n"; // 引用计数为 1,因为没有新增外部持有者
// Step 3: 在外部再获取一个 shared_ptr
std::shared_ptr<Manager> manager2 = manager1->getSharedPtr();
std::cout << "Reference Count after getSharedPtr: " << manager1.use_count() << "\n"; // 引用计数为 2
// Step 4: 销毁 manager1
manager1.reset();
std::cout << "Reference Count after resetting manager1: " << manager2.use_count() << "\n"; // 引用计数为 1
// Step 5: 销毁 manager2
manager2.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
cpp
#include <iostream>
#include <memory>
#include <vector>
// 前置声明 Manager 类
class Manager;
// Worker 类负责执行任务,并在任务完成时通知 Manager
class Worker {
public:
// 构造函数中传入 Manager 的 weak_ptr
Worker(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";
// 模拟任务完成后通知 Manager
notifyManager();
}
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弱化对象的引用,如果对象还存在则执行回调,如果对象不存在在不执行回调,从而保证系统的稳定性和安全性