商城首页欢迎来到中国正版软件门户

您的位置:首页 >C++高性能观察者模式实现方法

C++高性能观察者模式实现方法

  发布于2026-03-17 阅读(0)

扫一扫,手机访问

C++如何实现高性能的观察者模式?(事件驱动架构设计)

std::function + std::vector 存回调,别手写链表

性能瓶颈常出在通知阶段的遍历开销和内存碎片上。手写双向链表看似“可控”,实际带来指针跳转、缓存不友好、删除时迭代器失效等问题。现代 C++ 更推荐用连续内存容器存 std::function 对象。

实操建议:

  • std::vector 存观察者,插入/通知都是 O(1) 平摊复杂度
  • 避免在通知循环中增删观察者——先收集待移除的索引,通知完再批量擦除
  • 如果事件类型固定且数量少,可考虑 std::array 预分配,省去动态扩容判断
  • 注意 std::function 的构造开销:捕获大对象或绑定复杂逻辑时,考虑用 std::shared_ptr 包一层再传入,避免拷贝

std::shared_ptr 管理观察者生命周期,别裸指针 + weak_ptr 检查

裸指针观察者容易悬空,而每轮通知前都调 lock() 再判空,会把热点路径拖慢 20%+(实测 clang 15 / x86-64)。更轻量的做法是让观察者自己管理生命周期,发布者只持 std::shared_ptr

实操建议:

  • 观察者类继承自 std::enable_shared_from_this,注册时传 shared_from_this()
  • 发布者容器存 std::shared_ptr,通知时直接调用成员函数
  • 观察者析构时自动从发布者容器中移除(需配合 RAII 句柄或 on_destroy 回调)
  • 若观察者不能改继承关系(如第三方类),再退回到 weak_ptr,但务必把 lock() 移到注册/注销路径,而非通知路径

事件通知不加锁?看场景:单线程高频用无锁,跨线程必须分离通道

90% 的误以为“观察者模式必须线程安全”,结果给每个 notify()std::mutex,吞掉 3~5 倍吞吐。真实情况是:线程模型决定同步策略,不是模式本身决定。

实操建议:

  • 纯单线程(如游戏主循环、嵌入式状态机):完全去掉锁,std::vector 读写都在同一线程,安全且最快
  • 生产者多线程、消费者单线程(如 IO 事件收进队列,主线程统一 dispatch):用 std::queue + std::mutex 收集事件,通知仍在单线程执行
  • 真需要多线程并发通知:为每个线程准备独立的观察者容器副本,用 thread_localstd::unordered_map 分离,避免争用
  • 切忌在 std::function 回调里做耗时操作——这会让整个通知卡住,应转成异步投递

std::move 传事件对象,但别 move 所有东西

事件对象如果含大字段(如 std::vector 日志内容),按值传参会触发深拷贝;但盲目所有参数都 std::move,可能破坏 const 正确性或导致多次 move 后访问未定义行为。

实操建议:

  • 事件结构体标记 [[nodiscard]],并禁用拷贝构造,强制移动语义
  • 通知函数签名用 void notify(Event&& e),内部用 std::move(e) 转发给各回调
  • 如果某个观察者只需读取部分字段(如只关心 e.type),提供 const 引用重载:void notify(const Event& e),避免无谓移动
  • 切记:move 后的 e 在 notify 函数内不可再访问——常见坑是 move 后还打印日志或校验字段

最易被忽略的是事件对象的内存布局和对齐。如果事件里混用 booldoublestd::string,缓存行浪费比你预想的严重。高频路径上,优先用 POD 结构 + 手动 padding,别依赖编译器优化。

本文转载于:互联网 如有侵犯,请联系zhengruancom@outlook.com删除。
免责声明:正软商城发布此文仅为传递信息,不代表正软商城认同其观点或证实其描述。

热门关注