1. 项目概述与核心价值最近在重构一个老旧的C服务端框架其中一个痛点就是模块间的通信。早期为了图省事用了不少回调函数和裸指针代码耦合得跟意大利面似的调试起来更是噩梦。尤其是在多线程环境下一个对象在A线程被销毁了B线程还在傻乎乎地往它上面发事件直接导致程序崩溃这种“悬垂回调”问题太常见了。当时就想要是能有一个既解耦又线程安全的通信机制就好了。这不Qt的信号与槽Signals Slots机制名声在外但它绑定在Qt框架里对于很多纯后端或者不想引入Qt的项目来说太重了。于是我决定自己动手基于现代CC17的特性实现一个轻量级、线程安全的信号与槽库。这个实现的核心目标很明确第一是解耦让发送信号的“发布者”和接收信号的“订阅者”之间不需要知道对方的具体类型通过一个中间层信号对象来连接。第二是线程安全这是重中之重必须保证在任何线程中连接Connect、发射Emit或断开连接Disconnect信号时都不会引发数据竞争、死锁或访问已销毁对象的问题。第三是易用且高效接口要直观接近Qt的使用体验同时避免过度的运行时开销。为什么选择C17因为C17为我们提供了几件趁手的“兵器”让实现变得优雅而安全。std::shared_ptr和std::weak_ptr是管理对象生命周期的黄金搭档能有效解决悬垂指针问题。std::function和std::bind或lambda让我们可以存储任何可调用对象作为槽函数。而std::mutex、std::recursive_mutex以及std::lock_guard、std::unique_lock则是构建线程安全基础的基石。此外C17的std::invoke提供了更通用的调用方式std::apply可以方便地处理参数包这些都能让我们的实现更加健壮和灵活。这个自实现的信号槽机制非常适合用于事件驱动架构的应用程序比如游戏引擎中的事件系统、GUI框架中的控件通信、网络服务器中的请求-响应处理或者是任何需要模块间进行松耦合、异步通信的场景。如果你也在为C项目中的模块通信头疼特别是多线程环境下的安全问题那么接下来的内容应该能给你提供一套可以直接“抄作业”的解决方案。2. 核心设计思路与架构拆解2.1 信号与槽的基本模型在开始敲代码之前我们先要把模型想清楚。一个最简单的信号槽模型包含三个核心角色信号Signal一个特殊的事件发射器。它内部维护着一个列表记录所有对它感兴趣的“订阅者”即槽函数。当某个事件发生时比如数据更新、用户点击信号就被“发射”Emit它会遍历这个列表依次调用每个订阅的槽函数。槽Slot本质上就是一个可调用对象Callable Object。它可以是一个普通的全局函数、一个类的静态成员函数、一个类的非静态成员函数需要绑定对象实例或者一个lambda表达式、函数对象等。槽函数定义了当信号被发射时应该执行什么操作。连接Connection将特定的信号与特定的槽函数关联起来的动作。一个信号可以连接多个槽一个槽也可以被多个信号连接。我们的设计目标就是创建一个Signal类模板它能够接受任意参数类型的槽函数。当调用Signal的emit方法或重载的operator()时所有连接的槽函数都会以这些参数被调用。2.2 线程安全的核心挑战与方案选型线程安全是我们这个实现区别于许多玩具版信号槽的关键。主要面临以下几个挑战竞态条件Race Condition当线程A正在遍历槽函数列表并执行时线程B可能同时在修改这个列表连接新槽或断开连接。这会导致迭代器失效引发未定义行为通常是崩溃。生命周期管理Lifetime Management槽函数可能绑定了一个对象的成员函数。如果对象在槽函数被调用前就被销毁了就会导致“悬垂调用”访问无效内存。死锁Deadlock如果信号槽的调用链中涉及到锁的嵌套获取设计不当就容易引发死锁。我们的解决方案是对于竞态条件在Signal类内部使用一个互斥锁std::mutex或std::recursive_mutex来保护槽函数列表通常用std::vector或std::list存储的所有操作包括连接、断开、遍历执行。这里有一个细节需要考虑遍历执行槽函数时如果槽函数内部又试图操作同一个信号比如在槽函数里断开连接使用普通的std::mutex会导致死锁同一个线程试图重复获取已持有的锁。因此我选择了std::recursive_mutex它允许同一个线程多次锁定完美适配这种“自递归”场景。对于生命周期管理这是实现的重中之重。我们不能直接存储裸指针或std::function绑定对象指针。我的方案是引入一个“连接句柄”Connection的概念。每个连接在内部不仅存储可调用对象还存储一个std::weak_ptrvoid它弱引用着槽函数所属的对象对于成员函数槽。当需要调用槽函数前先尝试将weak_ptr提升lock()为shared_ptr。如果提升成功说明对象还活着安全执行如果提升失败返回空说明对象已被销毁那么这个连接就自动失效我们可以安全地将其从列表中移除。这个机制通常被称为“自动断开”Auto-Disconnection。对于执行策略信号发射时是应该同步调用阻塞直到所有槽函数执行完还是异步调用将调用任务投递到队列为了通用性和简单性我首先实现同步调用。这意味着emit调用会阻塞并依次在所有调用者的线程上下文中执行槽函数。这简单直接但要求槽函数执行不能太耗时否则会阻塞信号发射者。在后续扩展中可以很容易地引入Qt::QueuedConnection类似的机制将槽函数调用封装成任务投递到目标对象所属线程的事件队列中去执行这需要配合一个事件循环Event Loop实现起来更复杂但能彻底解决跨线程调用和阻塞问题。2.3 接口设计如何让用起来像Qt一样顺手好的接口能让库的易用性提升一个档次。我参考了Qt和boost::signals2的设计目标是让用户几乎无感知地使用。连接Connect提供connect成员函数它应该能接受各种可调用对象。对于成员函数我们需要用户提供对象实例的shared_ptr。函数签名可能像这样template typename T, typename... Args Connection connect(std::shared_ptrT obj, void (T::*func)(Args...));同时也要支持lambda和std::function。断开连接Disconnect提供disconnect函数可以接受一个Connection对象由connect返回来断开特定连接也可以断开与某个特定对象的所有连接。发射Emit提供emit函数或重载operator()允许用户以信号定义的参数类型进行调用。连接句柄Connection这是一个轻量级的对象用户可以用它来手动管理连接的生命周期比如在作用域结束前提前断开。它内部应该包含足够的信息来唯一标识一个连接。基于以上思路我们可以开始勾勒出核心类的框架。3. 核心类实现详解3.1 Connection连接句柄与生命周期纽带Connection类是整个机制中管理连接生命周期和实现自动断开的关键。它本身不包含业务逻辑主要是一个标识符和资源管理单元。class Connection { public: Connection() default; ~Connection() default; // 允许移动禁止拷贝一个连接只应属于一个所有者 Connection(Connection) noexcept default; Connection operator(Connection) noexcept default; Connection(const Connection) delete; Connection operator(const Connection) delete; // 主动断开连接 void disconnect() { if (disconnector_ disconnector_-enabled) { disconnector_-disconnect(); disconnector_.reset(); // 断开后释放资源 } } // 检查连接是否仍然有效即未被断开 bool isConnected() const { return disconnector_ disconnector_-enabled; } private: friend class SignalBase; // SignalBase需要访问其内部 // 内部使用的断开器抽象基类 struct Disconnector { virtual ~Disconnector() default; virtual void disconnect() 0; bool enabled true; }; // 具体的断开器持有断开操作所需的资源如指向信号槽列表的弱引用和迭代器 template typename DisconnectFunc struct DisconnectorImpl : public Disconnector { DisconnectFunc func; DisconnectorImpl(DisconnectFunc f) : func(std::move(f)) {} void disconnect() override { if (enabled) { func(); enabled false; } } }; std::shared_ptrDisconnector disconnector_; };关键点解析禁止拷贝一个连接代表一个唯一的订阅关系。如果允许拷贝那么拷贝体断开连接会影响原体语义混乱。所以我们只允许移动语义。类型擦除Type ErasureDisconnector基类和模板化的DisconnectorImpl是经典的类型擦除技术。Signal类内部在创建连接时会生成一个lambda这个lambda知道如何从自己的槽列表中移除这个特定的连接例如通过存储列表迭代器。我们将这个lambda包装进DisconnectorImpl再将其基类指针存入Connection。这样Connection类型就统一了无需模板参数用户用起来很方便。自动断开机制这个机制实际上不在Connection内部而是在Signal调用槽函数时。Connection在这里的作用是提供一种手动管理的方式。自动断开依赖于槽函数列表中存储的std::weak_ptr。3.2 SignalBase非模板化基类与线程安全基础设施为了让不同的Signal模板实例能有一些共享的行为比如跟踪所有连接我们引入一个非模板的基类SignalBase。它主要管理线程安全锁。class SignalBase { protected: // 使用递归锁允许在槽函数内操作同一个信号 mutable std::recursive_mutex mutex_; // 提供一个受保护的锁获取方法供派生类使用 std::unique_lockstd::recursive_mutex getLock() const { return std::unique_lockstd::recursive_mutex(mutex_); } };这里选择std::recursive_mutex的理由前面已经阐述。getLock方法返回一个std::unique_lock利用RAII资源获取即初始化机制确保在作用域结束时锁一定会被释放即使发生异常也能保证这是编写健壮多线程代码的基本习惯。3.3 Signal核心模板类的实现这是最核心的部分。我们将实现一个类模板SignalArgs...其中Args...是信号发射时传递的参数类型列表。template typename... Args class Signal : public SignalBase { public: using SlotType std::functionvoid(Args...); ~Signal() { // 析构时需要断开所有连接。 // 这里加锁是为了防止正在遍历时被析构。 auto lock getLock(); slots_.clear(); } // 连接自由函数或静态函数、lambda、函数对象 Connection connect(SlotType slot) { auto lock getLock(); slots_.push_back(std::move(slot)); auto it std::prev(slots_.end()); // 创建并返回一个Connection对象 auto disconnector std::make_sharedDisconnectorImpl([this, it]() { auto lock getLock(); // 断开时也需要加锁 slots_.erase(it); }); Connection conn; conn.disconnector_ disconnector; return conn; } // 连接对象的成员函数核心重载 template typename T Connection connect(std::shared_ptrT obj, void (T::*func)(Args...)) { // 使用weak_ptr弱引用对象解决生命周期问题 std::weak_ptrT weakObj obj; // 构造一个slot内部检查对象是否存活 SlotType slot [weakObj, func](Args... args) { if (auto sharedObj weakObj.lock()) { // 对象存活安全调用成员函数 // 使用std::invoke提供更通用的调用方式C17 std::invoke(func, sharedObj.get(), std::forwardArgs(args)...); } // 如果对象已销毁则什么也不做。这个连接会在下次emit时被清理吗 // 不这里只是调用时跳过。清理需要额外机制见后文。 }; // 存储这个slot auto lock getLock(); slots_.push_back(std::move(slot)); auto it std::prev(slots_.end()); // 创建断开器除了从slots_移除还需要从跟踪对象的map中移除如果需要 auto disconnector std::make_sharedDisconnectorImpl([this, it, weakObj]() { auto lock getLock(); // 从主列表移除 slots_.erase(it); // 注意这里我们暂时无法从 per-object 跟踪中移除因为我们现在没有这个结构。 // 我们需要一个更复杂的设计来同时支持按对象断开。 }); Connection conn; conn.disconnector_ disconnector; return conn; } // 发射信号 void emit(Args... args) { // 问题1直接遍历slots_并调用如果在调用某个slot时 // 该slot内部又调用了connect/disconnect修改了slots_会导致迭代器失效。 // 解决方案在调用前复制一份当前slot列表。 decltype(slots_) slotsCopy; { auto lock getLock(); slotsCopy slots_; // 复制注意这里复制的是std::function有一定开销但保证了安全。 } // 问题2如何清理那些对象已经销毁的“僵尸连接” // 我们可以在遍历复制的列表时进行检查和清理。但复制列表里是function丢失了weak_ptr信息。 // 因此我们需要在存储slot时额外存储一个用于检查有效性的函数。 // 新的设计SlotHolder 结构体 for (auto slot : slotsCopy) { if (slot) { // 简单的空检查 slot(std::forwardArgs(args)...); } } } // 重载函数调用运算符方便使用 void operator()(Args... args) { emit(std::forwardArgs(args)...); } private: // 我们需要一个更强大的结构来存储slot并支持有效性检查和按对象跟踪 struct SlotHolder { SlotType slot; // 实际的可调用对象 std::functionbool() isAlive; // 检查关联对象是否存活的函数 // 可以添加其他元信息如连接ID等 }; std::vectorSlotHolder slots_; // 替换原来的std::vectorSlotType };关键点与问题分析上面的代码勾勒了框架但暴露了几个关键问题迭代器失效与执行安全在emit中我们复制了整个slots_列表。这确实避免了在遍历时原列表被修改导致的迭代器失效是个简单有效的策略。但复制std::function或SlotHolder是有成本的如果槽函数列表很大或槽函数对象很大需要评估性能。另一种更精细的策略是使用“标记删除”在断开连接时只是标记该连接为无效在emit遍历后再统一清理。这里我们先采用复制策略以保证正确性。“僵尸连接”清理我们引入了SlotHolder和isAlive成员。对于连接到成员函数的槽isAlive应该返回对应weak_ptr的lock()是否成功。对于普通函数、静态函数等没有绑定对象的槽isAlive可以始终返回true。在emit函数中我们遍历slots_时应该先检查isAlive()如果返回false则将该连接标记为待删除或直接移除然后跳过执行。这样就能实现自动清理。按对象断开连接用户可能希望一次性断开某个对象的所有连接。这要求我们在Signal内部维护一个从对象的weak_ptr或shared_ptr的引用到一组连接或SlotHolder迭代器的映射。这增加了复杂性但非常实用。让我们重新设计SlotHolder和连接逻辑解决上述问题。4. 完整实现与优化4.1 增强型SlotHolder与连接管理我们重新设计Signal的内部数据结构以支持自动清理和按对象断开。template typename... Args class Signal : public SignalBase { private: // 每个槽的完整信息 struct SlotHolder { using IdType uint64_t; IdType id; // 唯一ID用于标识连接 std::functionvoid(Args...) callback; // 实际回调 std::functionbool() isAlive; // 有效性检查 std::weak_ptrvoid trackedObject; // 跟踪的对象的弱引用用于按对象断开 }; std::vectorSlotHolder slots_; std::atomicSlotHolder::IdType nextId_{1}; // 用于生成唯一ID // 映射被跟踪对象 - 该对象对应的所有槽ID列表 std::unordered_mapstd::shared_ptrvoid, std::vectorSlotHolder::IdType objectConnectionsMap_; public: ~Signal() { auto lock getLock(); slots_.clear(); objectConnectionsMap_.clear(); } // 连接通用可调用对象 template typename Callable Connection connect(Callable func) { return connectImpl(std::forwardCallable(func), std::shared_ptrvoid{}); } // 连接对象成员函数推荐接口 template typename T, typename... UArgs Connection connect(std::shared_ptrT obj, void (T::*method)(UArgs...)) { // 静态断言检查信号参数与槽函数参数是否匹配 static_assert(std::is_same_vstd::tupleArgs..., std::tupleUArgs..., Signal and slot argument types must match!); // 构造一个捕获weak_ptr的lambda std::weak_ptrT weakObj obj; auto callback [weakObj, method](Args... args) { if (auto sharedObj weakObj.lock()) { std::invoke(method, sharedObj.get(), std::forwardArgs(args)...); } }; // 构造 isAlive 检查器 auto isAlive [weakObj]() - bool { return !weakObj.expired(); }; return connectImpl(std::move(callback), std::move(isAlive), obj); } private: // 通用的连接实现核心 template typename Callable Connection connectImpl(Callable callback, std::functionbool() isAlive, std::shared_ptrvoid trackedObj nullptr) { auto lock getLock(); SlotHolder::IdType id nextId_; SlotHolder holder; holder.id id; holder.callback std::forwardCallable(callback); holder.isAlive std::move(isAlive); if (trackedObj) { holder.trackedObject trackedObj; // 记录对象到连接的映射 objectConnectionsMap_[trackedObj].push_back(id); } slots_.push_back(std::move(holder)); auto it std::prev(slots_.end()); // 创建断开器 auto disconnector std::make_sharedtypename Connection::DisconnectorImpl([this, id, trackedObj]() { auto lock getLock(); // 从slots_中查找并删除 auto slotIt std::find_if(slots_.begin(), slots_.end(), [id](const SlotHolder h) { return h.id id; }); if (slotIt ! slots_.end()) { slots_.erase(slotIt); } // 如果有关联对象也从映射中删除 if (trackedObj) { auto mapIt objectConnectionsMap_.find(trackedObj); if (mapIt ! objectConnectionsMap_.end()) { auto idVec mapIt-second; idVec.erase(std::remove(idVec.begin(), idVec.end(), id), idVec.end()); if (idVec.empty()) { objectConnectionsMap_.erase(mapIt); } } } }); Connection conn; conn.disconnector_ disconnector; return conn; } public: // 发射信号线程安全支持自动清理僵尸连接 void emit(Args... args) { // 1. 获取当前有效槽的列表复制回调函数避免在锁内调用用户代码 std::vectorstd::functionvoid(Args...) validCallbacks; std::vectorSlotHolder::IdType deadSlotIds; // 记录需要清理的僵尸连接ID { auto lock getLock(); validCallbacks.reserve(slots_.size()); for (const auto holder : slots_) { if (holder.isAlive holder.isAlive()) { // 对象存活复制回调以备执行 validCallbacks.push_back(holder.callback); } else { // 对象已死标记为待清理 deadSlotIds.push_back(holder.id); } } // 立即清理僵尸连接在锁内进行防止竞争 if (!deadSlotIds.empty()) { cleanupDeadSlots(deadSlotIds); } } // 锁作用域结束释放锁 // 2. 在无锁状态下执行所有有效的回调 // 这是关键避免了用户槽函数内部再次操作本信号时可能引发的死锁或性能问题。 // 但要求槽函数不会访问被其他线程同时修改的、且未受保护的数据。 for (auto cb : validCallbacks) { if (cb) { // 使用try-catch包裹防止一个槽函数异常导致后续槽函数无法执行 try { cb(std::forwardArgs(args)...); } catch (...) { // 通常应该记录日志这里简单处理避免异常传播中断其他槽。 // 注意异常不应从信号发射中抛出这不符合事件处理的常规预期。 } } } } // 断开与特定对象关联的所有连接 template typename T void disconnect(std::shared_ptrT obj) { auto lock getLock(); auto mapIt objectConnectionsMap_.find(obj); if (mapIt ! objectConnectionsMap_.end()) { // 获取该对象的所有连接ID auto idsToRemove mapIt-second; // 复制一份因为后面清理会修改容器 // 根据ID清理slots_ for (auto id : idsToRemove) { auto slotIt std::find_if(slots_.begin(), slots_.end(), [id](const SlotHolder h) { return h.id id; }); if (slotIt ! slots_.end()) { slots_.erase(slotIt); } } // 从map中移除该对象 objectConnectionsMap_.erase(mapIt); } } private: // 根据ID列表清理僵尸连接 void cleanupDeadSlots(const std::vectorSlotHolder::IdType deadIds) { // 从slots_中移除 slots_.erase(std::remove_if(slots_.begin(), slots_.end(), [deadIds](const SlotHolder holder) { return std::find(deadIds.begin(), deadIds.end(), holder.id) ! deadIds.end(); }), slots_.end()); // 清理objectConnectionsMap_中的空项这是一个优化可以定期进行不一定每次 for (auto it objectConnectionsMap_.begin(); it ! objectConnectionsMap_.end(); ) { auto idVec it-second; // 移除那些已经不在slots_中的ID idVec.erase(std::remove_if(idVec.begin(), idVec.end(), [this](SlotHolder::IdType id) { return std::find_if(slots_.begin(), slots_.end(), [id](const SlotHolder h) { return h.id id; }) slots_.end(); }), idVec.end()); if (idVec.empty()) { it objectConnectionsMap_.erase(it); } else { it; } } } };4.2 关键设计决策与优化点解析锁的粒度与执行分离这是性能优化的关键。在emit函数中我们只在收集有效回调和标记僵尸连接时加锁。一旦获得了需要执行的回调列表就立刻释放锁。然后在无锁状态下执行这些回调。这样做的好处是避免死锁用户槽函数内部如果也操作同一个信号比如连接/断开不会因为等待锁而死锁因为执行时锁已释放。提高并发性信号发射期间其他线程可以自由地连接或断开不会因为长时间执行槽函数而被阻塞。风险槽函数执行时其关联的对象状态可能被其他线程改变。这需要用户自己保证槽函数内部的线程安全性。这是合理的因为对象的线程安全应由对象自身负责。僵尸连接的惰性清理我们在每次emit时都检查并清理失效连接。这保证了连接列表不会无限膨胀。虽然增加了一点emit的开销但这是“自动断开”功能必须付出的代价且开销可控主要是检查weak_ptr::expired()很快。按对象断开通过objectConnectionsMap_我们可以高效地断开某个对象的所有连接。这在对象析构时非常有用可以避免手动管理一堆Connection对象。异常安全在调用用户槽函数时使用了try-catch。这是为了防止一个槽函数的异常导致整个信号发射过程终止影响其他槽函数的执行。在事件系统中通常希望异常被隔离和处理而不是向上传播。这里可以选择记录日志或调用一个用户自定义的异常处理器。连接ID使用自增的ID来唯一标识每个连接比存储迭代器更安全因为迭代器在容器修改后可能失效而ID是稳定的。5. 使用示例与性能考量5.1 基本用法示例#include iostream #include memory #include thread #include chrono // 假设我们的Signal类在 namespace my 下 using my::Signal; using my::Connection; class Receiver : public std::enable_shared_from_thisReceiver { public: void onEvent(int value, const std::string msg) { std::cout Receiver[ this ] got event: value value , msg msg (thread: std::this_thread::get_id() ) std::endl; } void onAnotherEvent() { std::cout Receiver[ this ] got another event. std::endl; } }; class Sender { public: Signalint, const std::string valueChanged; Signal workFinished; }; int main() { auto sender std::make_sharedSender(); auto receiver1 std::make_sharedReceiver(); auto receiver2 std::make_sharedReceiver(); // 连接成员函数 Connection conn1 sender-valueChanged.connect(receiver1, Receiver::onEvent); Connection conn2 sender-valueChanged.connect(receiver2, Receiver::onEvent); Connection conn3 sender-workFinished.connect(receiver1, Receiver::onAnotherEvent); // 连接lambda表达式 Connection conn4 sender-valueChanged.connect([](int v, const std::string s) { std::cout Lambda slot: s - v std::endl; }); // 在多线程环境中发射信号 std::thread t1([sender]() { for (int i 0; i 5; i) { sender-valueChanged(i, from thread1); std::this_thread::sleep_for(std::chrono::milliseconds(10)); } sender-workFinished(); }); std::thread t2([sender]() { for (int i 10; i 15; i) { sender-valueChanged(i, from thread2); std::this_thread::sleep_for(std::chrono::milliseconds(20)); } }); // 模拟receiver2提前销毁 std::this_thread::sleep_for(std::chrono::milliseconds(30)); std::cout \n--- Destroying receiver2 ---\n; receiver2.reset(); // receiver2 被销毁其连接应自动失效 // 继续发射信号receiver2的槽不应再被调用 sender-valueChanged(100, after destruction); // 手动断开一个连接 conn1.disconnect(); sender-valueChanged(200, after manual disconnect); t1.join(); t2.join(); // 断开某个对象的所有连接 sender-valueChanged.disconnect(receiver1); // 此后receiver1的onEvent将不再被调用 return 0; }5.2 性能考量与优化建议锁竞争emit中复制回调列表和清理僵尸连接需要在锁内进行。如果槽函数数量巨大成千上万这个复制操作可能成为瓶颈。优化方向使用std::shared_ptrstd::vectorSlotHolder来管理列表emit时通过原子操作获取一个快照std::shared_ptr的拷贝实现写时复制Copy-On-Write减少锁的持有时间。将僵尸连接的清理放到一个单独的、低优先度的后台线程中定期进行而不是每次emit都做。内存开销每个连接都是一个SlotHolder结构体包含多个std::function和std::weak_ptr。std::function可能有堆分配开销。对于性能极度敏感的场景可以考虑使用自定义的小对象优化Small Object Optimization的可调用对象包装器或者直接存储函数指针和对象指针配合weak_ptr但这会牺牲一些灵活性。参数转发与拷贝emit使用完美转发std::forwardArgs(args)...。这保证了如果参数是右值可以移动到槽函数中减少拷贝。但需要注意如果同一个参数需要传递给多个槽函数而第一个槽函数以移动方式取走了资源后面的槽函数就会拿到无效对象。这种情况下信号参数应该按值传递如果类型可廉价拷贝或按const引用传递。递归锁的开销std::recursive_mutex通常比std::mutex开销稍大。如果能够严格保证槽函数内不会操作同一个信号可以改用std::mutex并在设计上禁止递归操作例如在文档中明确说明。6. 常见问题与排查技巧在实际使用中你可能会遇到以下问题槽函数没有被调用检查连接是否成功确保connect调用后返回的Connection对象是有效的或者你存储了它。如果Connection对象被过早销毁某些实现可能会自动断开连接。检查对象生命周期这是最常见的问题。如果你连接了一个对象的成员函数但在发射信号前该对象已经被销毁那么连接会自动失效。确保持有对象的shared_ptr直到你不再需要接收信号为止。线程问题如果你期望槽函数在另一个线程执行类似Qt::QueuedConnection但我们的基础实现是同步的那么槽函数会在发射信号的线程执行。你需要确保接收对象在那个线程是安全的或者扩展实现队列机制。程序崩溃特别是在多线程环境下竞态条件确保你没有在信号槽系统之外以非线程安全的方式共享数据。我们的信号槽只保证了自身操作的线程安全连接、断开、发射不保证槽函数内部访问共享数据的线程安全。悬垂指针如果你错误地使用了裸指针而不是shared_ptr来连接成员函数当对象删除后再调用槽函数就会崩溃。务必使用shared_ptr进行连接。在槽函数中删除发送者如果槽函数中直接删除了正在发射信号的对象会导致未定义行为。如果需要应该使用deleteLater模式将删除操作异步化。性能瓶颈过多的槽函数如果单个信号连接了成百上千个槽函数每次emit的遍历开销会很大。考虑对架构进行重新设计或者使用更高效的事件分发机制如观察者模式配合更精细的分类。槽函数执行过慢同步发射会阻塞发射线程。如果槽函数执行IO或密集计算考虑将其改为异步执行例如将任务提交到线程池。内存泄漏循环引用这是使用shared_ptr和弱回调时经典的问题。如果对象A持有信号S的shared_ptr而信号S又通过shared_ptr连接了对象A的成员函数这就形成了循环引用导致两者都无法释放。我们的实现使用了weak_ptr来跟踪对象因此不会因为信号持有对象的shared_ptr而导致循环引用。循环引用通常发生在业务逻辑层面比如对象A和对象B互相持有对方的shared_ptr。需要仔细设计所有权关系必要时使用weak_ptr打破循环。调试技巧可以在Signal的connect、emit、disconnect等关键函数中加入日志输出打印线程ID、连接ID等信息方便跟踪连接和调用的流程。使用valgrind或AddressSanitizer等工具检查内存错误和竞态条件。对于复杂的多线程交互可以尝试使用线程分析工具或者通过大量的压力测试来暴露问题。实现一个工业级的线程安全信号槽机制需要考虑很多边界情况本文提供的实现是一个功能完整、线程安全的基础版本涵盖了自动生命周期管理、线程安全操作和易用的接口。你可以以此为基础根据项目的具体需求进行扩展例如添加槽函数执行的优先级、异步发射、信号链一个信号触发另一个信号等高级特性。希望这份详细的拆解和实现能为你解决C项目中的模块通信难题提供一个可靠的方案。
1. 项目概述与核心价值最近在重构一个老旧的C服务端框架其中一个痛点就是模块间的通信。早期为了图省事用了不少回调函数和裸指针代码耦合得跟意大利面似的调试起来更是噩梦。尤其是在多线程环境下一个对象在A线程被销毁了B线程还在傻乎乎地往它上面发事件直接导致程序崩溃这种“悬垂回调”问题太常见了。当时就想要是能有一个既解耦又线程安全的通信机制就好了。这不Qt的信号与槽Signals Slots机制名声在外但它绑定在Qt框架里对于很多纯后端或者不想引入Qt的项目来说太重了。于是我决定自己动手基于现代CC17的特性实现一个轻量级、线程安全的信号与槽库。这个实现的核心目标很明确第一是解耦让发送信号的“发布者”和接收信号的“订阅者”之间不需要知道对方的具体类型通过一个中间层信号对象来连接。第二是线程安全这是重中之重必须保证在任何线程中连接Connect、发射Emit或断开连接Disconnect信号时都不会引发数据竞争、死锁或访问已销毁对象的问题。第三是易用且高效接口要直观接近Qt的使用体验同时避免过度的运行时开销。为什么选择C17因为C17为我们提供了几件趁手的“兵器”让实现变得优雅而安全。std::shared_ptr和std::weak_ptr是管理对象生命周期的黄金搭档能有效解决悬垂指针问题。std::function和std::bind或lambda让我们可以存储任何可调用对象作为槽函数。而std::mutex、std::recursive_mutex以及std::lock_guard、std::unique_lock则是构建线程安全基础的基石。此外C17的std::invoke提供了更通用的调用方式std::apply可以方便地处理参数包这些都能让我们的实现更加健壮和灵活。这个自实现的信号槽机制非常适合用于事件驱动架构的应用程序比如游戏引擎中的事件系统、GUI框架中的控件通信、网络服务器中的请求-响应处理或者是任何需要模块间进行松耦合、异步通信的场景。如果你也在为C项目中的模块通信头疼特别是多线程环境下的安全问题那么接下来的内容应该能给你提供一套可以直接“抄作业”的解决方案。2. 核心设计思路与架构拆解2.1 信号与槽的基本模型在开始敲代码之前我们先要把模型想清楚。一个最简单的信号槽模型包含三个核心角色信号Signal一个特殊的事件发射器。它内部维护着一个列表记录所有对它感兴趣的“订阅者”即槽函数。当某个事件发生时比如数据更新、用户点击信号就被“发射”Emit它会遍历这个列表依次调用每个订阅的槽函数。槽Slot本质上就是一个可调用对象Callable Object。它可以是一个普通的全局函数、一个类的静态成员函数、一个类的非静态成员函数需要绑定对象实例或者一个lambda表达式、函数对象等。槽函数定义了当信号被发射时应该执行什么操作。连接Connection将特定的信号与特定的槽函数关联起来的动作。一个信号可以连接多个槽一个槽也可以被多个信号连接。我们的设计目标就是创建一个Signal类模板它能够接受任意参数类型的槽函数。当调用Signal的emit方法或重载的operator()时所有连接的槽函数都会以这些参数被调用。2.2 线程安全的核心挑战与方案选型线程安全是我们这个实现区别于许多玩具版信号槽的关键。主要面临以下几个挑战竞态条件Race Condition当线程A正在遍历槽函数列表并执行时线程B可能同时在修改这个列表连接新槽或断开连接。这会导致迭代器失效引发未定义行为通常是崩溃。生命周期管理Lifetime Management槽函数可能绑定了一个对象的成员函数。如果对象在槽函数被调用前就被销毁了就会导致“悬垂调用”访问无效内存。死锁Deadlock如果信号槽的调用链中涉及到锁的嵌套获取设计不当就容易引发死锁。我们的解决方案是对于竞态条件在Signal类内部使用一个互斥锁std::mutex或std::recursive_mutex来保护槽函数列表通常用std::vector或std::list存储的所有操作包括连接、断开、遍历执行。这里有一个细节需要考虑遍历执行槽函数时如果槽函数内部又试图操作同一个信号比如在槽函数里断开连接使用普通的std::mutex会导致死锁同一个线程试图重复获取已持有的锁。因此我选择了std::recursive_mutex它允许同一个线程多次锁定完美适配这种“自递归”场景。对于生命周期管理这是实现的重中之重。我们不能直接存储裸指针或std::function绑定对象指针。我的方案是引入一个“连接句柄”Connection的概念。每个连接在内部不仅存储可调用对象还存储一个std::weak_ptrvoid它弱引用着槽函数所属的对象对于成员函数槽。当需要调用槽函数前先尝试将weak_ptr提升lock()为shared_ptr。如果提升成功说明对象还活着安全执行如果提升失败返回空说明对象已被销毁那么这个连接就自动失效我们可以安全地将其从列表中移除。这个机制通常被称为“自动断开”Auto-Disconnection。对于执行策略信号发射时是应该同步调用阻塞直到所有槽函数执行完还是异步调用将调用任务投递到队列为了通用性和简单性我首先实现同步调用。这意味着emit调用会阻塞并依次在所有调用者的线程上下文中执行槽函数。这简单直接但要求槽函数执行不能太耗时否则会阻塞信号发射者。在后续扩展中可以很容易地引入Qt::QueuedConnection类似的机制将槽函数调用封装成任务投递到目标对象所属线程的事件队列中去执行这需要配合一个事件循环Event Loop实现起来更复杂但能彻底解决跨线程调用和阻塞问题。2.3 接口设计如何让用起来像Qt一样顺手好的接口能让库的易用性提升一个档次。我参考了Qt和boost::signals2的设计目标是让用户几乎无感知地使用。连接Connect提供connect成员函数它应该能接受各种可调用对象。对于成员函数我们需要用户提供对象实例的shared_ptr。函数签名可能像这样template typename T, typename... Args Connection connect(std::shared_ptrT obj, void (T::*func)(Args...));同时也要支持lambda和std::function。断开连接Disconnect提供disconnect函数可以接受一个Connection对象由connect返回来断开特定连接也可以断开与某个特定对象的所有连接。发射Emit提供emit函数或重载operator()允许用户以信号定义的参数类型进行调用。连接句柄Connection这是一个轻量级的对象用户可以用它来手动管理连接的生命周期比如在作用域结束前提前断开。它内部应该包含足够的信息来唯一标识一个连接。基于以上思路我们可以开始勾勒出核心类的框架。3. 核心类实现详解3.1 Connection连接句柄与生命周期纽带Connection类是整个机制中管理连接生命周期和实现自动断开的关键。它本身不包含业务逻辑主要是一个标识符和资源管理单元。class Connection { public: Connection() default; ~Connection() default; // 允许移动禁止拷贝一个连接只应属于一个所有者 Connection(Connection) noexcept default; Connection operator(Connection) noexcept default; Connection(const Connection) delete; Connection operator(const Connection) delete; // 主动断开连接 void disconnect() { if (disconnector_ disconnector_-enabled) { disconnector_-disconnect(); disconnector_.reset(); // 断开后释放资源 } } // 检查连接是否仍然有效即未被断开 bool isConnected() const { return disconnector_ disconnector_-enabled; } private: friend class SignalBase; // SignalBase需要访问其内部 // 内部使用的断开器抽象基类 struct Disconnector { virtual ~Disconnector() default; virtual void disconnect() 0; bool enabled true; }; // 具体的断开器持有断开操作所需的资源如指向信号槽列表的弱引用和迭代器 template typename DisconnectFunc struct DisconnectorImpl : public Disconnector { DisconnectFunc func; DisconnectorImpl(DisconnectFunc f) : func(std::move(f)) {} void disconnect() override { if (enabled) { func(); enabled false; } } }; std::shared_ptrDisconnector disconnector_; };关键点解析禁止拷贝一个连接代表一个唯一的订阅关系。如果允许拷贝那么拷贝体断开连接会影响原体语义混乱。所以我们只允许移动语义。类型擦除Type ErasureDisconnector基类和模板化的DisconnectorImpl是经典的类型擦除技术。Signal类内部在创建连接时会生成一个lambda这个lambda知道如何从自己的槽列表中移除这个特定的连接例如通过存储列表迭代器。我们将这个lambda包装进DisconnectorImpl再将其基类指针存入Connection。这样Connection类型就统一了无需模板参数用户用起来很方便。自动断开机制这个机制实际上不在Connection内部而是在Signal调用槽函数时。Connection在这里的作用是提供一种手动管理的方式。自动断开依赖于槽函数列表中存储的std::weak_ptr。3.2 SignalBase非模板化基类与线程安全基础设施为了让不同的Signal模板实例能有一些共享的行为比如跟踪所有连接我们引入一个非模板的基类SignalBase。它主要管理线程安全锁。class SignalBase { protected: // 使用递归锁允许在槽函数内操作同一个信号 mutable std::recursive_mutex mutex_; // 提供一个受保护的锁获取方法供派生类使用 std::unique_lockstd::recursive_mutex getLock() const { return std::unique_lockstd::recursive_mutex(mutex_); } };这里选择std::recursive_mutex的理由前面已经阐述。getLock方法返回一个std::unique_lock利用RAII资源获取即初始化机制确保在作用域结束时锁一定会被释放即使发生异常也能保证这是编写健壮多线程代码的基本习惯。3.3 Signal核心模板类的实现这是最核心的部分。我们将实现一个类模板SignalArgs...其中Args...是信号发射时传递的参数类型列表。template typename... Args class Signal : public SignalBase { public: using SlotType std::functionvoid(Args...); ~Signal() { // 析构时需要断开所有连接。 // 这里加锁是为了防止正在遍历时被析构。 auto lock getLock(); slots_.clear(); } // 连接自由函数或静态函数、lambda、函数对象 Connection connect(SlotType slot) { auto lock getLock(); slots_.push_back(std::move(slot)); auto it std::prev(slots_.end()); // 创建并返回一个Connection对象 auto disconnector std::make_sharedDisconnectorImpl([this, it]() { auto lock getLock(); // 断开时也需要加锁 slots_.erase(it); }); Connection conn; conn.disconnector_ disconnector; return conn; } // 连接对象的成员函数核心重载 template typename T Connection connect(std::shared_ptrT obj, void (T::*func)(Args...)) { // 使用weak_ptr弱引用对象解决生命周期问题 std::weak_ptrT weakObj obj; // 构造一个slot内部检查对象是否存活 SlotType slot [weakObj, func](Args... args) { if (auto sharedObj weakObj.lock()) { // 对象存活安全调用成员函数 // 使用std::invoke提供更通用的调用方式C17 std::invoke(func, sharedObj.get(), std::forwardArgs(args)...); } // 如果对象已销毁则什么也不做。这个连接会在下次emit时被清理吗 // 不这里只是调用时跳过。清理需要额外机制见后文。 }; // 存储这个slot auto lock getLock(); slots_.push_back(std::move(slot)); auto it std::prev(slots_.end()); // 创建断开器除了从slots_移除还需要从跟踪对象的map中移除如果需要 auto disconnector std::make_sharedDisconnectorImpl([this, it, weakObj]() { auto lock getLock(); // 从主列表移除 slots_.erase(it); // 注意这里我们暂时无法从 per-object 跟踪中移除因为我们现在没有这个结构。 // 我们需要一个更复杂的设计来同时支持按对象断开。 }); Connection conn; conn.disconnector_ disconnector; return conn; } // 发射信号 void emit(Args... args) { // 问题1直接遍历slots_并调用如果在调用某个slot时 // 该slot内部又调用了connect/disconnect修改了slots_会导致迭代器失效。 // 解决方案在调用前复制一份当前slot列表。 decltype(slots_) slotsCopy; { auto lock getLock(); slotsCopy slots_; // 复制注意这里复制的是std::function有一定开销但保证了安全。 } // 问题2如何清理那些对象已经销毁的“僵尸连接” // 我们可以在遍历复制的列表时进行检查和清理。但复制列表里是function丢失了weak_ptr信息。 // 因此我们需要在存储slot时额外存储一个用于检查有效性的函数。 // 新的设计SlotHolder 结构体 for (auto slot : slotsCopy) { if (slot) { // 简单的空检查 slot(std::forwardArgs(args)...); } } } // 重载函数调用运算符方便使用 void operator()(Args... args) { emit(std::forwardArgs(args)...); } private: // 我们需要一个更强大的结构来存储slot并支持有效性检查和按对象跟踪 struct SlotHolder { SlotType slot; // 实际的可调用对象 std::functionbool() isAlive; // 检查关联对象是否存活的函数 // 可以添加其他元信息如连接ID等 }; std::vectorSlotHolder slots_; // 替换原来的std::vectorSlotType };关键点与问题分析上面的代码勾勒了框架但暴露了几个关键问题迭代器失效与执行安全在emit中我们复制了整个slots_列表。这确实避免了在遍历时原列表被修改导致的迭代器失效是个简单有效的策略。但复制std::function或SlotHolder是有成本的如果槽函数列表很大或槽函数对象很大需要评估性能。另一种更精细的策略是使用“标记删除”在断开连接时只是标记该连接为无效在emit遍历后再统一清理。这里我们先采用复制策略以保证正确性。“僵尸连接”清理我们引入了SlotHolder和isAlive成员。对于连接到成员函数的槽isAlive应该返回对应weak_ptr的lock()是否成功。对于普通函数、静态函数等没有绑定对象的槽isAlive可以始终返回true。在emit函数中我们遍历slots_时应该先检查isAlive()如果返回false则将该连接标记为待删除或直接移除然后跳过执行。这样就能实现自动清理。按对象断开连接用户可能希望一次性断开某个对象的所有连接。这要求我们在Signal内部维护一个从对象的weak_ptr或shared_ptr的引用到一组连接或SlotHolder迭代器的映射。这增加了复杂性但非常实用。让我们重新设计SlotHolder和连接逻辑解决上述问题。4. 完整实现与优化4.1 增强型SlotHolder与连接管理我们重新设计Signal的内部数据结构以支持自动清理和按对象断开。template typename... Args class Signal : public SignalBase { private: // 每个槽的完整信息 struct SlotHolder { using IdType uint64_t; IdType id; // 唯一ID用于标识连接 std::functionvoid(Args...) callback; // 实际回调 std::functionbool() isAlive; // 有效性检查 std::weak_ptrvoid trackedObject; // 跟踪的对象的弱引用用于按对象断开 }; std::vectorSlotHolder slots_; std::atomicSlotHolder::IdType nextId_{1}; // 用于生成唯一ID // 映射被跟踪对象 - 该对象对应的所有槽ID列表 std::unordered_mapstd::shared_ptrvoid, std::vectorSlotHolder::IdType objectConnectionsMap_; public: ~Signal() { auto lock getLock(); slots_.clear(); objectConnectionsMap_.clear(); } // 连接通用可调用对象 template typename Callable Connection connect(Callable func) { return connectImpl(std::forwardCallable(func), std::shared_ptrvoid{}); } // 连接对象成员函数推荐接口 template typename T, typename... UArgs Connection connect(std::shared_ptrT obj, void (T::*method)(UArgs...)) { // 静态断言检查信号参数与槽函数参数是否匹配 static_assert(std::is_same_vstd::tupleArgs..., std::tupleUArgs..., Signal and slot argument types must match!); // 构造一个捕获weak_ptr的lambda std::weak_ptrT weakObj obj; auto callback [weakObj, method](Args... args) { if (auto sharedObj weakObj.lock()) { std::invoke(method, sharedObj.get(), std::forwardArgs(args)...); } }; // 构造 isAlive 检查器 auto isAlive [weakObj]() - bool { return !weakObj.expired(); }; return connectImpl(std::move(callback), std::move(isAlive), obj); } private: // 通用的连接实现核心 template typename Callable Connection connectImpl(Callable callback, std::functionbool() isAlive, std::shared_ptrvoid trackedObj nullptr) { auto lock getLock(); SlotHolder::IdType id nextId_; SlotHolder holder; holder.id id; holder.callback std::forwardCallable(callback); holder.isAlive std::move(isAlive); if (trackedObj) { holder.trackedObject trackedObj; // 记录对象到连接的映射 objectConnectionsMap_[trackedObj].push_back(id); } slots_.push_back(std::move(holder)); auto it std::prev(slots_.end()); // 创建断开器 auto disconnector std::make_sharedtypename Connection::DisconnectorImpl([this, id, trackedObj]() { auto lock getLock(); // 从slots_中查找并删除 auto slotIt std::find_if(slots_.begin(), slots_.end(), [id](const SlotHolder h) { return h.id id; }); if (slotIt ! slots_.end()) { slots_.erase(slotIt); } // 如果有关联对象也从映射中删除 if (trackedObj) { auto mapIt objectConnectionsMap_.find(trackedObj); if (mapIt ! objectConnectionsMap_.end()) { auto idVec mapIt-second; idVec.erase(std::remove(idVec.begin(), idVec.end(), id), idVec.end()); if (idVec.empty()) { objectConnectionsMap_.erase(mapIt); } } } }); Connection conn; conn.disconnector_ disconnector; return conn; } public: // 发射信号线程安全支持自动清理僵尸连接 void emit(Args... args) { // 1. 获取当前有效槽的列表复制回调函数避免在锁内调用用户代码 std::vectorstd::functionvoid(Args...) validCallbacks; std::vectorSlotHolder::IdType deadSlotIds; // 记录需要清理的僵尸连接ID { auto lock getLock(); validCallbacks.reserve(slots_.size()); for (const auto holder : slots_) { if (holder.isAlive holder.isAlive()) { // 对象存活复制回调以备执行 validCallbacks.push_back(holder.callback); } else { // 对象已死标记为待清理 deadSlotIds.push_back(holder.id); } } // 立即清理僵尸连接在锁内进行防止竞争 if (!deadSlotIds.empty()) { cleanupDeadSlots(deadSlotIds); } } // 锁作用域结束释放锁 // 2. 在无锁状态下执行所有有效的回调 // 这是关键避免了用户槽函数内部再次操作本信号时可能引发的死锁或性能问题。 // 但要求槽函数不会访问被其他线程同时修改的、且未受保护的数据。 for (auto cb : validCallbacks) { if (cb) { // 使用try-catch包裹防止一个槽函数异常导致后续槽函数无法执行 try { cb(std::forwardArgs(args)...); } catch (...) { // 通常应该记录日志这里简单处理避免异常传播中断其他槽。 // 注意异常不应从信号发射中抛出这不符合事件处理的常规预期。 } } } } // 断开与特定对象关联的所有连接 template typename T void disconnect(std::shared_ptrT obj) { auto lock getLock(); auto mapIt objectConnectionsMap_.find(obj); if (mapIt ! objectConnectionsMap_.end()) { // 获取该对象的所有连接ID auto idsToRemove mapIt-second; // 复制一份因为后面清理会修改容器 // 根据ID清理slots_ for (auto id : idsToRemove) { auto slotIt std::find_if(slots_.begin(), slots_.end(), [id](const SlotHolder h) { return h.id id; }); if (slotIt ! slots_.end()) { slots_.erase(slotIt); } } // 从map中移除该对象 objectConnectionsMap_.erase(mapIt); } } private: // 根据ID列表清理僵尸连接 void cleanupDeadSlots(const std::vectorSlotHolder::IdType deadIds) { // 从slots_中移除 slots_.erase(std::remove_if(slots_.begin(), slots_.end(), [deadIds](const SlotHolder holder) { return std::find(deadIds.begin(), deadIds.end(), holder.id) ! deadIds.end(); }), slots_.end()); // 清理objectConnectionsMap_中的空项这是一个优化可以定期进行不一定每次 for (auto it objectConnectionsMap_.begin(); it ! objectConnectionsMap_.end(); ) { auto idVec it-second; // 移除那些已经不在slots_中的ID idVec.erase(std::remove_if(idVec.begin(), idVec.end(), [this](SlotHolder::IdType id) { return std::find_if(slots_.begin(), slots_.end(), [id](const SlotHolder h) { return h.id id; }) slots_.end(); }), idVec.end()); if (idVec.empty()) { it objectConnectionsMap_.erase(it); } else { it; } } } };4.2 关键设计决策与优化点解析锁的粒度与执行分离这是性能优化的关键。在emit函数中我们只在收集有效回调和标记僵尸连接时加锁。一旦获得了需要执行的回调列表就立刻释放锁。然后在无锁状态下执行这些回调。这样做的好处是避免死锁用户槽函数内部如果也操作同一个信号比如连接/断开不会因为等待锁而死锁因为执行时锁已释放。提高并发性信号发射期间其他线程可以自由地连接或断开不会因为长时间执行槽函数而被阻塞。风险槽函数执行时其关联的对象状态可能被其他线程改变。这需要用户自己保证槽函数内部的线程安全性。这是合理的因为对象的线程安全应由对象自身负责。僵尸连接的惰性清理我们在每次emit时都检查并清理失效连接。这保证了连接列表不会无限膨胀。虽然增加了一点emit的开销但这是“自动断开”功能必须付出的代价且开销可控主要是检查weak_ptr::expired()很快。按对象断开通过objectConnectionsMap_我们可以高效地断开某个对象的所有连接。这在对象析构时非常有用可以避免手动管理一堆Connection对象。异常安全在调用用户槽函数时使用了try-catch。这是为了防止一个槽函数的异常导致整个信号发射过程终止影响其他槽函数的执行。在事件系统中通常希望异常被隔离和处理而不是向上传播。这里可以选择记录日志或调用一个用户自定义的异常处理器。连接ID使用自增的ID来唯一标识每个连接比存储迭代器更安全因为迭代器在容器修改后可能失效而ID是稳定的。5. 使用示例与性能考量5.1 基本用法示例#include iostream #include memory #include thread #include chrono // 假设我们的Signal类在 namespace my 下 using my::Signal; using my::Connection; class Receiver : public std::enable_shared_from_thisReceiver { public: void onEvent(int value, const std::string msg) { std::cout Receiver[ this ] got event: value value , msg msg (thread: std::this_thread::get_id() ) std::endl; } void onAnotherEvent() { std::cout Receiver[ this ] got another event. std::endl; } }; class Sender { public: Signalint, const std::string valueChanged; Signal workFinished; }; int main() { auto sender std::make_sharedSender(); auto receiver1 std::make_sharedReceiver(); auto receiver2 std::make_sharedReceiver(); // 连接成员函数 Connection conn1 sender-valueChanged.connect(receiver1, Receiver::onEvent); Connection conn2 sender-valueChanged.connect(receiver2, Receiver::onEvent); Connection conn3 sender-workFinished.connect(receiver1, Receiver::onAnotherEvent); // 连接lambda表达式 Connection conn4 sender-valueChanged.connect([](int v, const std::string s) { std::cout Lambda slot: s - v std::endl; }); // 在多线程环境中发射信号 std::thread t1([sender]() { for (int i 0; i 5; i) { sender-valueChanged(i, from thread1); std::this_thread::sleep_for(std::chrono::milliseconds(10)); } sender-workFinished(); }); std::thread t2([sender]() { for (int i 10; i 15; i) { sender-valueChanged(i, from thread2); std::this_thread::sleep_for(std::chrono::milliseconds(20)); } }); // 模拟receiver2提前销毁 std::this_thread::sleep_for(std::chrono::milliseconds(30)); std::cout \n--- Destroying receiver2 ---\n; receiver2.reset(); // receiver2 被销毁其连接应自动失效 // 继续发射信号receiver2的槽不应再被调用 sender-valueChanged(100, after destruction); // 手动断开一个连接 conn1.disconnect(); sender-valueChanged(200, after manual disconnect); t1.join(); t2.join(); // 断开某个对象的所有连接 sender-valueChanged.disconnect(receiver1); // 此后receiver1的onEvent将不再被调用 return 0; }5.2 性能考量与优化建议锁竞争emit中复制回调列表和清理僵尸连接需要在锁内进行。如果槽函数数量巨大成千上万这个复制操作可能成为瓶颈。优化方向使用std::shared_ptrstd::vectorSlotHolder来管理列表emit时通过原子操作获取一个快照std::shared_ptr的拷贝实现写时复制Copy-On-Write减少锁的持有时间。将僵尸连接的清理放到一个单独的、低优先度的后台线程中定期进行而不是每次emit都做。内存开销每个连接都是一个SlotHolder结构体包含多个std::function和std::weak_ptr。std::function可能有堆分配开销。对于性能极度敏感的场景可以考虑使用自定义的小对象优化Small Object Optimization的可调用对象包装器或者直接存储函数指针和对象指针配合weak_ptr但这会牺牲一些灵活性。参数转发与拷贝emit使用完美转发std::forwardArgs(args)...。这保证了如果参数是右值可以移动到槽函数中减少拷贝。但需要注意如果同一个参数需要传递给多个槽函数而第一个槽函数以移动方式取走了资源后面的槽函数就会拿到无效对象。这种情况下信号参数应该按值传递如果类型可廉价拷贝或按const引用传递。递归锁的开销std::recursive_mutex通常比std::mutex开销稍大。如果能够严格保证槽函数内不会操作同一个信号可以改用std::mutex并在设计上禁止递归操作例如在文档中明确说明。6. 常见问题与排查技巧在实际使用中你可能会遇到以下问题槽函数没有被调用检查连接是否成功确保connect调用后返回的Connection对象是有效的或者你存储了它。如果Connection对象被过早销毁某些实现可能会自动断开连接。检查对象生命周期这是最常见的问题。如果你连接了一个对象的成员函数但在发射信号前该对象已经被销毁那么连接会自动失效。确保持有对象的shared_ptr直到你不再需要接收信号为止。线程问题如果你期望槽函数在另一个线程执行类似Qt::QueuedConnection但我们的基础实现是同步的那么槽函数会在发射信号的线程执行。你需要确保接收对象在那个线程是安全的或者扩展实现队列机制。程序崩溃特别是在多线程环境下竞态条件确保你没有在信号槽系统之外以非线程安全的方式共享数据。我们的信号槽只保证了自身操作的线程安全连接、断开、发射不保证槽函数内部访问共享数据的线程安全。悬垂指针如果你错误地使用了裸指针而不是shared_ptr来连接成员函数当对象删除后再调用槽函数就会崩溃。务必使用shared_ptr进行连接。在槽函数中删除发送者如果槽函数中直接删除了正在发射信号的对象会导致未定义行为。如果需要应该使用deleteLater模式将删除操作异步化。性能瓶颈过多的槽函数如果单个信号连接了成百上千个槽函数每次emit的遍历开销会很大。考虑对架构进行重新设计或者使用更高效的事件分发机制如观察者模式配合更精细的分类。槽函数执行过慢同步发射会阻塞发射线程。如果槽函数执行IO或密集计算考虑将其改为异步执行例如将任务提交到线程池。内存泄漏循环引用这是使用shared_ptr和弱回调时经典的问题。如果对象A持有信号S的shared_ptr而信号S又通过shared_ptr连接了对象A的成员函数这就形成了循环引用导致两者都无法释放。我们的实现使用了weak_ptr来跟踪对象因此不会因为信号持有对象的shared_ptr而导致循环引用。循环引用通常发生在业务逻辑层面比如对象A和对象B互相持有对方的shared_ptr。需要仔细设计所有权关系必要时使用weak_ptr打破循环。调试技巧可以在Signal的connect、emit、disconnect等关键函数中加入日志输出打印线程ID、连接ID等信息方便跟踪连接和调用的流程。使用valgrind或AddressSanitizer等工具检查内存错误和竞态条件。对于复杂的多线程交互可以尝试使用线程分析工具或者通过大量的压力测试来暴露问题。实现一个工业级的线程安全信号槽机制需要考虑很多边界情况本文提供的实现是一个功能完整、线程安全的基础版本涵盖了自动生命周期管理、线程安全操作和易用的接口。你可以以此为基础根据项目的具体需求进行扩展例如添加槽函数执行的优先级、异步发射、信号链一个信号触发另一个信号等高级特性。希望这份详细的拆解和实现能为你解决C项目中的模块通信难题提供一个可靠的方案。
