C++实现轻量级观察者模式(RAII版) _ 结合std::function的回调管理【源码】

C++实现轻量级观察者模式(RAII版) _ 结合std::function的回调管理【源码】

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

为什么 std::function + RAII 是观察者注销最稳妥的组合

在C++里手动管理观察者的生命周期，就像走钢丝——稍有不慎，悬空回调（dangling callback）就会导致程序崩溃。问题的核心在于，std::function本身只是个可调用对象的包装器，它并不持有被调用对象的所有权。这就引出了一个关键的设计原则：订阅行为必须返回一个可析构的句柄，让析构动作等同于自动退订。这套机制，远比传统的“注册时传入裸指针，再手动调用unregister”要可靠得多。

想想看，一个典型的翻车现场是什么样？std::function捕获了this指针，可被观察的对象早就销毁了，观察者列表里却还躺着一个试图调用已释放内存的函数对象，崩溃只是时间问题。

要避免这种局面，有几个要点必须把握：

• 生命周期管理是前提：如果回调需要访问被观察对象的状态，那么必须使用std::shared_ptr或std::weak_ptr来管理其生命周期。
• 句柄必须封装：句柄类型绝不能是裸指针或引用。更推荐的做法是，用一个轻量级结构体去封装std::list<...>::iterator，或者使用原子计数器生成的唯一ID。
• 警惕迭代器失效：务必避免在回调执行过程中去修改观察者容器（比如一边遍历一边删除），否则迭代器失效会引发未定义行为。

最稳妥的组合是因RAII句柄在析构时自动退订，避免悬空回调；std::function需配合shared_ptr或weak_ptr管理被观察对象生命周期，防止use-after-free。

如何设计可自动注销的订阅句柄（RAII 核心）

所谓RAII句柄，其本质就是一个与作用域绑定的“退订令牌”。典型的实现思路是，让subscribe()函数返回一个ObserverHandle对象，而这个对象的析构函数，会默默地执行内部的unsubscribe()逻辑。

来看一个关键的结构示例：

立即学习“C++免费学习笔记（深入）”；

struct ObserverHandle {
    std::list>* list_ = nullptr;
    std::list>::iterator it_;

    ObserverHandle(std::list>& l,
                   std::list>::iterator i)
        : list_(&l), it_(i) {}

    ~ObserverHandle() {
        if (list_) list_->erase(it_);
    }

    ObserverHandle(const ObserverHandle&) = delete;
    ObserverHandle& operator=(const ObserverHandle&) = delete;
};

这里有两点需要特别注意：首先，list_存储的是原始指针，因为句柄并不拥有这个容器，它只是需要知道在哪里执行退订操作。其次，迭代器it_必须在构造时立即捕获并保存，延迟获取是行不通的。

std::function 回调捕获方式对生命周期的影响

回调能否安全执行，完全取决于其捕获方式是否与被观察者或观察者对象的生命周期同步。错误的捕获，直接通向use-after-free的深渊：

• [this]{ ... }：高危操作！如果this所指的对象先于观察者容器被销毁，那么触发回调就是未定义行为。
• [ptr = shared_from_this()]{ ... }：安全，但前提是被观察的类需要继承自std::enable_shared_from_this。
• [w = weak_ptr_to_observer]{ ... }：适用于观察者是独立对象的情况，在回调执行前先用w.lock()判断对象是否存活。
• 纯函数对象或静态函数：最为轻量，但代价是无法访问任何实例状态。

性能上也有个小提示：捕获std::shared_ptr会带来原子计数的开销。对于高频触发的事件，建议使用std::weak_ptr配合lock()判空，这样可以避免强引用导致的循环引用问题。

线程安全边界在哪？别指望 RAII 句柄自动解决并发问题

这是一个常见的误解：用了RAII句柄就等于线程安全。事实上，ObserverHandle自身的析构操作（操作它自己持有的迭代器和指针）可以是线程安全的，但观察者容器本身的读写操作，默认并不是线程安全的。

具体的加锁策略，需要根据使用场景来决定：

• 单线程环境：最简单，无需加锁，std::list配合RAII句柄完全足够。
• 多生产者/单消费者（例如主线程发布通知，工作线程订阅）：在向容器写入（订阅/退订）时需要加std::mutex锁；而在读取容器遍历通知时，可以尝试无锁，但必须确保遍历期间容器结构不被修改。
• 高频多线程通知：可以考虑使用std::vector>配合原子索引快照的策略，来彻底规避迭代器失效的问题。

最后，一个真正容易被忽略的细节是：即使使用了RAII句柄，如果两个线程同时调用subscribe()函数，你仍然需要保护容器的插入操作——因为句柄只负责管理“退订”的生命周期，它可管不了“注册”时的并发安全。