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

目录

类的线程安全

实现线程安全 

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

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

智能指针实现多线程安全

 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 是否为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()来提供安全的对象访问机制，防止访问到已经销毁的对象  

#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，但是这些线程访问和修改对象的时候可能会导致数据不一致问题，例如一个线程正在写入对象，另一个线程也正在读取或者写入的时候，此时就会产生数据竞争的情况
• 读写冲突问题
  • 同时读取，此时通过计数是线程安全的
  • 同时写入，除非对象在写的时候进行了加锁，否则是线程不安全的
  • 读写冲突：一个读一个写，可能会导致最后数据不一致的问题

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

#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_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，从而安全的访问对象

#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_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，所以该对象不会被销毁。

代码事例理解 

#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

 

 

 

#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弱化对象的引用，如果对象还存在则执行回调，如果对象不存在在不执行回调，从而保证系统的稳定性和安全性