C++实现简单的发布订阅模式 _ 事件中心与监听器管理【源码】

C++实现简单的发布订阅模式：事件中心与监听器管理【源码】

如何用 std::function 和 std::map 管理事件监听器

事件监听器的管理，核心在于建立事件名与对应处理逻辑之间的映射。直接用裸函数指针？显然不够灵活。更通用的做法是采用 std::function 来统一封装各类可调用对象。这里有个关键细节：注册监听器时，必须生成一个唯一的ID。为什么？因为只有这样，后续才能精准、安全地移除特定的监听器，而不会误伤无辜。

实践中，有几个常见的坑需要避开。比如，用一个全局的 std::vector 存放所有监听器，不区分事件类型。结果是，每次发布事件都得遍历整个列表，性能低下，而且清理特定事件的监听器也变得异常麻烦。再比如，在 std::function 的lambda表达式中捕获了局部变量的引用，一旦该变量生命周期结束，再触发事件就会引发令人头疼的 std::bad_function_call。

• 容器选择：推荐使用 std::map>>。事件名作为键，对应的值是一个监听器列表，每个监听器最好附带其唯一ID和具体的执行闭包。
• 注册与注销：注册函数应返回一个 size_t 类型的ID。注销时，根据事件名和这个ID去精准定位并移除（使用 erase）。尽量避免在遍历过程中使用 remove_if 后再 resize，这很容易导致迭代器失效。
• 捕获策略：警惕lambda表达式中的引用捕获（如 [&x]{...}）。除非能百分百确保被捕获对象的生命周期长于监听器本身，否则，优先考虑值捕获。

发布事件时怎么避免迭代器失效和重复调用

发布事件的逻辑看似简单——遍历对应事件的所有监听器并调用它们。但问题恰恰出在这里：用户在这些回调函数里，可能会同步地调用 unsubscribe 甚至再次 publish 同一个事件。这直接导致正在被遍历的容器被修改，迭代器失效，程序崩溃。

给整个 std::map 加一把大锁？这想法很自然，但粒度太粗，严重影响并发性能，而且C++标准库容器本身并不提供内置的线程安全保证。

一个更可行的策略是采用「快照式遍历」。具体来说，在开始调用监听器之前，先拷贝一份当前事件对应的监听器列表（std::vector），然后遍历这个副本。这样一来，原始容器可以安全地被其他操作修改，而副本则保持只读状态，完美避开了迭代器失效的陷阱。

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

• 拷贝成本：不必过分担心性能。std::function 对象本身通常不大（经过小对象优化后一般在16到32字节），而且一个事件下的监听器数量通常有限，拷贝开销可控。
• 递归触发：要警惕在遍历监听器副本时，回调函数内部又发布了同一事件，这可能导致无限递归。可以考虑加入深度计数器或标记位来拦截。
• 异常安全：单个监听器的执行如果抛出异常，不应该中断整个事件的分发过程。稳妥的做法是用 try/catch 块包裹每一个监听器的调用。

std::any 能否用于泛化事件参数？小心类型擦除开销

为了让事件系统更通用，支持任意类型的参数（比如 publish(“click”, 123, “ok”, true)），很自然会想到 std::any 或 std::variant。这确实可行，但代价是引入了运行时的类型检查以及可能的内存分配开销。

有没有更轻量的方案？答案是肯定的。我们可以换个思路：让事件系统只负责分发，而具体的参数类型，则由业务层在编译期约定。 也就是说，每个事件名都对应一组固定的参数类型，监听器通过模板来注册。

例如：on(“login”, [](int id, const std::string& name) { … })。系统内部用 std::function 来存储。这样一来，所有类型信息在编译期就已确定，完全避免了类型擦除带来的开销，也杜绝了运行时 std::any_cast 失败的风险。

• 类型安全：如果使用动态参数，必须配套严格的类型信息校验机制。否则，像 publish(“login”, “wrong”) 这样的错误调用可能会静默失败，甚至导致崩溃。
• 性能考量：在嵌入式或游戏逻辑这类高频触发事件的场景中，频繁构造和析构 std::any 带来的开销不容忽视。
• 折中方案：如果确实需要一定的灵活性，可以考虑将多个参数打包成一个 struct，并通过 std::shared_ptr 传递。这通常比使用多个 std::any 更可控，性能也更好。

线程安全边界在哪？别假设全局互斥就够了

默认情况下，一个简单实现的事件中心并不是线程安全的。当注册、注销和发布事件的操作可能来自多个线程时，我们至少需要保证对同一个事件名的操作是串行的。但是，如果简单粗暴地给整个 std::map 加上一把全局互斥锁，那么所有事件操作都会被序列化——线程A在处理“保存”事件时，线程B连发布一个“心跳”事件都得等着，这显然不合理。

更合理的做法是按事件名进行分段加锁。例如，可以使用一个 std::unordered_map 来为每一类事件管理独立的读写锁。或者，为了减少锁对象的数量，可以采用一个 std::shared_mutex 数组，然后根据事件名的哈希值取模来决定使用哪一把锁，从而降低锁竞争。

• 锁的粒度：发布事件通常只需要获取读锁（允许多个线程并发发布同一事件），而注册和注销监听器则需要获取写锁（独占访问）。
• 避免死锁：绝对不要在监听器的回调函数内部长时间持有锁，尤其是在回调中又可能触发新事件的情况下，这极易导致死锁。
• 简化场景：如果你的应用模型是单线程事件驱动（比如Qt的主线程、游戏的主更新循环），那么完全可以不加锁，但必须在文档中明确注明这一约束。

话说回来，整个事件系统中最棘手的问题，其实是监听器的生命周期管理。开发者忘记手动注销监听器，或者对象析构时没有清理其注册的监听器，都会导致事件中心试图调用一个已经失效的 std::function——这直接引发了未定义行为。解决这个问题的经典思路，是配合使用 std::weak_ptr 来追踪对象，或者设计一个RAII封装类（例如 ScopedSubscription），在析构时自动注销。遗憾的是，这部分保障逻辑恰恰最容易被忽略，却也最为关键。