1. 项目概述从“通知”到“解耦”的设计哲学今天我们来聊聊C设计模式里一个既经典又实用的家伙——观察者模式。你可能在无数框架和库的源码里见过它的身影比如Qt的信号槽、各种事件驱动系统甚至是游戏引擎里的消息广播。它的核心思想其实特别生活化想象一下你关注了一个公众号每当它发布新文章你作为订阅者就会自动收到推送而你完全不需要每隔五分钟就去刷新一下它的主页。观察者模式干的就是这个事儿——在软件对象之间建立一种“发布-订阅”的依赖关系让一个对象主题的状态变化能自动通知到所有依赖它的对象观察者并且彼此之间还不用知道对方的具体细节。为什么在C的日常训练里要单独拿一天来啃这个模式因为它是解耦的利器。在稍微复杂点的项目里尤其是那些带有用户界面、需要实时数据更新或者事件响应的系统比如股票行情监控、游戏UI状态同步、日志系统硬编码的对象间调用会让代码很快变成一团乱麻。A模块改了状态得亲自去调用B、C、D模块的更新函数一旦要加个E模块又得回头改A的代码。观察者模式通过引入一个抽象的中间层把“谁变了”和“谁需要知道”这两件事分开让系统更容易扩展和维护。今天这篇实战篇我们就抛开那些干巴巴的UML图直接上手从零构建一个工业级强度的观察者模式把内存管理、线程安全、性能优化这些坑一个个填平。2. 模式核心理解“一对多”与“松耦合”的精髓2.1 发布-订阅机制的本质观察者模式也叫发布-订阅模式其核心是定义了一种一对多的依赖关系。让我们拆开看主题Subject也叫被观察者或发布者。它维护一个观察者列表并提供添加Attach、移除Detach和通知Notify观察者的方法。当它的内部状态发生变化时它会遍历这个列表调用每个观察者的更新方法。观察者Observer也叫订阅者。它定义一个更新接口通常是一个Update方法。当接收到主题的通知时观察者会从主题那里拉取或接收主题推送的所需的新数据并执行相应的业务逻辑。关键点在于松耦合主题只知道观察者实现了某个接口但不知道观察者具体是谁、属于哪个类、要做什么。观察者也只知道可以从主题获取信息但通常不关心主题内部如何实现。这种关系就像杂志社和订户杂志社只管按名单寄杂志订户只管收杂志看双方通过“邮寄地址”接口联系而不需要了解对方的生活细节。2.2 推模型 vs. 拉模型数据传递的两种策略在实现通知时有两种主流的数据传递策略选择哪一种直接影响了接口设计和系统效率。推模型Push Model主题在通知观察者时主动将变化的数据作为参数传递给观察者的Update方法。优点对观察者方便直接拿到数据无需再回主题查询。缺点主题需要知道观察者需要什么数据。如果不同的观察者需要的数据不同主题要么传递一个庞大的“数据包”可能包含很多观察者不需要的信息要么为不同类型的观察者定义不同的更新接口这增加了主题的复杂性破坏了封装性。拉模型Pull Model主题在通知观察者时只传递一个指向自身的引用或指针。观察者在自己的Update方法内部通过这个引用主动去主题那里查询它关心的特定数据。优点主题的接口保持简洁统一只有一个Update方法观察者按需索取主题无需关心观察者的数据需求。封装性更好。缺点观察者需要知道主题的查询接口增加了观察者对主题的依赖同时因为观察者要主动拉取可能涉及多次函数调用效率略低于推模型一次传完。在C实战中拉模型更为常用和推荐因为它更好地遵循了面向对象的设计原则尤其是“最少知识原则”。我们的实战也将基于拉模型构建。2.3 C实现的关键挑战与设计选择用C实现一个健壮的观察者模式不能只满足于书本上的示例。我们要直面几个工程问题内存管理观察者通常以指针形式存储在主题的列表中。谁来负责删除这些观察者对象主题删除时列表里的指针怎么办这就是经典的“对象生命周期”问题处理不好就是内存泄漏或悬空指针。线程安全在现代多线程程序中主题的状态可能在任意线程被修改观察者的更新也可能在任意线程被触发。如何保证在遍历观察者列表进行通知时列表本身不会被另一个线程同时修改比如添加或删除观察者性能考量如果观察者数量很多成千上万每次通知都遍历整个列表可能成为瓶颈。通知过程是同步还是异步观察者的更新函数如果很耗时会不会阻塞主题线程依赖管理如何优雅地处理观察者先于主题销毁或者主题先于观察者销毁的情况如何避免一个观察者被多次添加到同一个主题接下来的完整实战我们将逐一解决这些问题构建一个可用于真实项目的观察者模式框架。3. 基础框架搭建定义核心接口与类我们先从最基础的、线程不安全的版本开始把核心流程跑通然后再逐步加固。3.1 定义观察者接口观察者接口极其简单就是一个纯虚函数Update。我们让Update方法接收一个对主题的常量引用这是拉模型的典型做法。// Observer.h #ifndef OBSERVER_H #define OBSERVER_H // 前向声明避免循环包含 class Subject; class Observer { public: virtual ~Observer() default; // 基类析构函数必须是虚函数 virtual void Update(const Subject theChangedSubject) 0; }; #endif // OBSERVER_H关键细节virtual ~Observer() default;这行至关重要。基类的析构函数声明为虚函数是为了当通过基类指针删除派生类对象时能够正确调用派生类的析构函数避免资源泄漏。即使这里没有资源需要释放这也是一个必须养成的好习惯。const Subject theChangedSubject使用常量引用传递主题一是避免拷贝开销二是明确表示观察者不应通过此接口修改主题。3.2 定义主题基类主题类需要维护一个观察者列表并提供注册、注销和通知的方法。// Subject.h #ifndef SUBJECT_H #define SUBJECT_H #include list #include memory // 为了std::weak_ptr #include “Observer.h” class Subject { public: virtual ~Subject() default; // 注册观察者 void Attach(Observer* observer) { // 简单的实现先不考虑去重和线程安全 observers_.push_back(observer); } // 注销观察者 void Detach(Observer* observer) { observers_.remove(observer); } // 通知所有观察者 void Notify() { for (auto* obs : observers_) { if (obs) { obs-Update(*this); } } } protected: // 观察者列表。使用裸指针后续我们会改进。 std::listObserver* observers_; }; #endif // SUBJECT_H这个基础版本的问题内存管理Attach和Detach接受裸指针Observer*。主题完全不知道这个指针指向的对象是谁拥有的何时销毁。如果观察者对象被delete了而主题没有及时Detach那么observers_列表里就留下了一个“悬空指针”后续Notify时调用Update会导致未定义行为通常是程序崩溃。线程安全Attach,Detach,Notify这三个函数如果被多个线程同时调用对std::list的修改和遍历会引发数据竞争。重复添加同一个观察者指针可以被多次Attach导致被多次通知。4. 进阶实现解决内存管理与线程安全4.1 使用智能指针管理观察者生命周期解决内存问题的核心思路是明确所有权。谁拥有观察者对象谁就负责它的生命周期。通常观察者对象由创建它的模块如UI组件、业务逻辑模块拥有。主题不应该拥有观察者它只应该“借用”观察者的引用。因此我们不应该在主题中存储Observer*而应该存储std::weak_ptrObserver。weak_ptr是一种不控制对象生命周期的智能指针它指向一个由shared_ptr管理的对象。它允许你安全地“观察”一个对象而不会阻止该对象被销毁。当对象存在时你可以通过weak_ptr获得一个可用的shared_ptr来使用它当对象已被销毁weak_ptr会过期expired()返回true。这就要求我们的Observer接口也必须由shared_ptr来管理。我们修改接口和实现// Observer.h (修改版) #ifndef OBSERVER_H #define OBSERVER_H #include memory class Subject; class Observer : public std::enable_shared_from_thisObserver { public: virtual ~Observer() default; virtual void Update(const Subject theChangedSubject) 0; }; using ObserverPtr std::shared_ptrObserver; using ObserverWeakPtr std::weak_ptrObserver; #endif // OBSERVER_H// Subject.h (修改版) #ifndef SUBJECT_H #define SUBJECT_H #include list #include memory #include mutex // 用于线程安全 #include “Observer.h” class Subject { public: virtual ~Subject() default; void Attach(ObserverWeakPtr observer) { std::lock_guardstd::mutex lock(mutex_); // 可以在这里添加去重逻辑检查是否已存在 observers_.push_back(std::move(observer)); } void Detach(ObserverWeakPtr observer) { std::lock_guardstd::mutex lock(mutex_); // 由于存储的是weak_ptr比较需要先lock()获取shared_ptr再比较或者直接比较原始指针 // 更简单的做法是在Observer析构时自动Detach见下文。 observers_.remove_if([observer](const ObserverWeakPtr wp) { auto sp1 wp.lock(); auto sp2 observer.lock(); return sp1 sp2 sp1.get() sp2.get(); }); } void Notify() { std::listObserverWeakPtr observersCopy; { std::lock_guardstd::mutex lock(mutex_); observersCopy observers_; // 复制列表缩短锁的持有时间 } for (const auto weakObs : observersCopy) { if (auto obs weakObs.lock()) { // 尝试提升为shared_ptr obs-Update(*this); } } } protected: std::listObserverWeakPtr observers_; mutable std::mutex mutex_; // 保护observers_列表 }; #endif // SUBJECT_H改进点解析std::enable_shared_from_this这是一个混入类模板。当一个类T公有继承它时T的对象就可以安全地生成一个指向自身的shared_ptr通过shared_from_this()成员函数。这在我们需要将this指针作为shared_ptr传递时比如在观察者内部将自己注册到主题是必需的否则直接std::shared_ptrObserver(this)会创建出一个新的、独立的所有权组导致双重删除。weak_ptr的使用主题存储weak_ptr表示它不拥有观察者。在Notify时通过lock()方法尝试将weak_ptr提升为shared_ptr。如果提升成功返回非空的shared_ptr说明观察者对象还活着可以安全调用Update。如果提升失败返回空的shared_ptr说明观察者对象已经被销毁这个weak_ptr已经过期我们直接跳过它。这优雅地解决了悬空指针问题。去重逻辑在Attach中我们可以遍历observers_对每个已有的weak_ptr执行lock()与待添加的observer.lock()比较原始指针如果相同则不再添加。这里为了代码清晰先省略。Detach的复杂性由于列表里存的是weak_ptr直接比较两个weak_ptr是否指向同一对象比较麻烦。上面的代码展示了通过比较它们lock()后得到的shared_ptr的原始指针来实现。但更常见的做法是让观察者在自己的析构函数中主动从所有主题注销自己这样主题就不需要实现复杂的Detach查找逻辑了。4.2 实现观察者自动注销使用RAII管理注册关系为了让观察者的注册/注销更自动化避免遗忘Detach导致的问题我们可以采用RAII资源获取即初始化思想。创建一个辅助类ObserverRegistration它在构造时执行Attach在析构时执行Detach。// ObserverRegistration.h #ifndef OBSERVER_REGISTRATION_H #define OBSERVER_REGISTRATION_H #include “Subject.h” #include “Observer.h” class ObserverRegistration { public: // 构造函数观察者注册到主题 ObserverRegistration(Subject subject, ObserverPtr observer) : subject_(subject), observer_(std::move(observer)) { subject_.Attach(observer_); } // 析构函数自动从主题注销 ~ObserverRegistration() { subject_.Detach(observer_); } // 禁止拷贝 ObserverRegistration(const ObserverRegistration) delete; ObserverRegistration operator(const ObserverRegistration) delete; // 允许移动 ObserverRegistration(ObserverRegistration) default; ObserverRegistration operator(ObserverRegistration) default; private: Subject subject_; ObserverWeakPtr observer_; // 这里存储weak_ptr即可因为Subject内部也是weak_ptr }; #endif // OBSERVER_REGISTRATION_H使用方式// 在某个作用域比如一个UI窗口类的构造函数中 auto myObserver std::make_sharedMyConcreteObserver(); ObserverRegistration reg(*mySubject, myObserver); // 注册 // ... 当reg离开作用域被销毁时自动从mySubject注销这种方法将注册的生命周期与一个局部对象绑定非常清晰安全是C中管理资源依赖的经典手法。4.3 线程安全优化细粒度锁与通知策略我们上面的Notify实现复制了整个观察者列表这虽然缩短了锁的持有时间只锁定了复制操作但如果观察者数量巨大复制开销也不小。另一种更高效的做法是使用读写锁std::shared_mutexC17因为Attach/Detach是写操作而遍历通知是读操作。// SubjectThreadSafe.h (可选进阶版) #include shared_mutex #include list #include memory #include “Observer.h” class ThreadSafeSubject { public: void Attach(ObserverWeakPtr observer) { std::unique_lockstd::shared_mutex lock(mutex_); observers_.push_back(std::move(observer)); } void Detach(ObserverWeakPtr observer) { std::unique_lockstd::shared_mutex lock(mutex_); // ... 查找并移除逻辑 } void Notify() { std::shared_lockstd::shared_mutex lock(mutex_); // 读锁允许多个线程同时Notify // 注意这里遍历时不能调用可能修改observers_的Detach操作。 // 如果观察者在Update中尝试Detach自己会导致死锁或未定义行为。 // 因此在观察者Update中直接Detach自己是危险的。 auto it observers_.begin(); while (it ! observers_.end()) { if (auto obs it-lock()) { obs-Update(*this); it; } else { // 观察者已失效从列表中移除这是写操作但我们在读锁下 // 这违反了读写锁规则。因此更安全的做法是标记删除稍后清理。 // 或者回到使用互斥锁并在Notify中复制列表。 it observers_.erase(it); // 错误在读锁下执行写操作。 } } } private: std::listObserverWeakPtr observers_; mutable std::shared_mutex mutex_; };重要警告在Notify遍历过程中如果尝试修改观察者列表比如移除过期的weak_ptr会与读写锁的语义冲突。因此对于需要在通知过程中清理过期观察者的场景更实用的方案是仍然使用普通的std::mutex。在Notify中复制列表如我们最初所做。或者定期在Attach/Detach时或单独用一个清理函数来移除过期观察者而不是在Notify遍历时做。此外绝对要避免在观察者的Update方法中直接调用主题的Detach来注销自己因为这可能导致如果主题使用互斥锁并且在Notify中持有锁遍历列表那么在Update中调用Detach会尝试再次获取同一个锁造成死锁除非使用可重入锁但std::mutex不可重入。如果主题使用读写锁在Notify的读锁中调用Detach写操作是未定义行为。遍历迭代器失效在遍历列表时从列表中删除当前元素会使迭代器失效导致程序崩溃。安全的做法是观察者将需要注销的请求记录到一个待处理队列中主题在Notify完成后再处理这些注销请求。5. 完整实战案例一个简单的股票价格监控系统让我们用一个具体的例子把上面的概念串起来。假设我们有一个Stock股票类作为主题当股价变化时通知注册的观察者。观察者可以是Display显示面板和Alert价格警报器。5.1 定义具体主题Stock类// Stock.h #ifndef STOCK_H #define STOCK_H #include “Subject.h” #include string class Stock : public Subject { public: Stock(const std::string symbol, double price) : symbol_(symbol), price_(price) {} const std::string GetSymbol() const { return symbol_; } double GetPrice() const { return price_; } // 改变股价并通知所有观察者 void SetPrice(double newPrice) { if (std::abs(price_ - newPrice) 1e-6) { // 简单判断是否有变化 price_ newPrice; Notify(); // 关键状态改变触发通知 } } private: std::string symbol_; double price_; }; #endif // STOCK_H5.2 定义具体观察者// Display.h #ifndef DISPLAY_H #define DISPLAY_H #include “Observer.h” #include “Stock.h” #include iostream #include memory class Display : public Observer, public std::enable_shared_from_thisDisplay { public: explicit Display(const std::string name) : name_(name) {} void Update(const Subject theChangedSubject) override { // 安全的向下转型确认主题类型 const Stock* pStock dynamic_castconst Stock*(theChangedSubject); if (pStock) { std::cout “[Display “ name_ “] Stock “ pStock-GetSymbol() “ price updated to: “ pStock-GetPrice() std::endl; } } private: std::string name_; }; #endif // DISPLAY_H// Alert.h #ifndef ALERT_H #define ALERT_H #include “Observer.h” #include “Stock.h” #include iostream #include memory class Alert : public Observer, public std::enable_shared_from_thisAlert { public: Alert(const std::string stockSymbol, double threshold, bool above) : stockSymbol_(stockSymbol), threshold_(threshold), triggerAbove_(above) {} void Update(const Subject theChangedSubject) override { const Stock* pStock dynamic_castconst Stock*(theChangedSubject); if (pStock pStock-GetSymbol() stockSymbol_) { double currentPrice pStock-GetPrice(); bool conditionMet triggerAbove_ ? (currentPrice threshold_) : (currentPrice threshold_); if (conditionMet) { std::cout “[ALERT!] Stock “ stockSymbol_ “ price is “ (triggerAbove_ ? “above” : “below”) “ threshold “ threshold_ “. Current: “ currentPrice std::endl; } } } private: std::string stockSymbol_; double threshold_; bool triggerAbove_; // true为高于阈值警报false为低于阈值警报 }; #endif // ALERT_H5.3 主程序演示// main.cpp #include “Stock.h” #include “Display.h” #include “Alert.h” #include “ObserverRegistration.h” #include memory #include vector int main() { // 创建主题苹果公司的股票 Stock aapl(“AAPL”, 150.0); // 创建观察者 auto display1 std::make_sharedDisplay(“Main Screen”); auto display2 std::make_sharedDisplay(“Mobile App”); auto alertHigh std::make_sharedAlert(“AAPL”, 160.0, true); // 股价高于160报警 auto alertLow std::make_sharedAlert(“AAPL”, 145.0, false); // 股价低于145报警 // 使用RAII包装器进行注册 std::vectorObserverRegistration registrations; registrations.emplace_back(aapl, display1); registrations.emplace_back(aapl, display2); registrations.emplace_back(aapl, alertHigh); registrations.emplace_back(aapl, alertLow); std::cout “ Initial State ” std::endl; // 初始状态观察者不会自动被通知除非主动调用一次Notify。这里我们先不调用。 std::cout “\n Price Change 1: 155.5 ” std::endl; aapl.SetPrice(155.5); // 自动触发通知 std::cout “\n Price Change 2: 162.3 ” std::endl; aapl.SetPrice(162.3); // 触发高价警报 std::cout “\n Price Change 3: 142.1 ” std::endl; aapl.SetPrice(142.1); // 触发低价警报 std::cout “\n End of Demo ” std::endl; // registrations离开作用域自动执行Detach return 0; }预期输出 Initial State Price Change 1: 155.5 [Display Main Screen] Stock AAPL price updated to: 155.5 [Display Mobile App] Stock AAPL price updated to: 155.5 Price Change 2: 162.3 [Display Main Screen] Stock AAPL price updated to: 162.3 [Display Mobile App] Stock AAPL price updated to: 162.3 [ALERT!] Stock AAPL price is above threshold 160. Current: 162.3 Price Change 3: 142.1 [Display Main Screen] Stock AAPL price updated to: 142.1 [Display Mobile App] Stock AAPL price updated to: 142.1 [ALERT!] Stock AAPL price is below threshold 145. Current: 142.1 End of Demo 6. 性能优化与高级话题6.1 避免在Notify中阻塞异步通知如果观察者的Update方法执行很慢比如涉及文件I/O、网络请求或复杂计算同步的Notify会阻塞主题线程导致主题响应变慢。一种解决方案是使用异步通知。我们可以将通知任务提交到一个线程池中执行。这里简单演示使用std::async需要C11或更高版本进行异步调用// AsyncSubject.h (简化示例) #include future #include vector class AsyncSubject : public Subject { // 继承自我们之前定义的Subject基类 public: void AsyncNotify() { std::lock_guardstd::mutex lock(mutex_); std::listObserverWeakPtr observersCopy observers_; // 复制列表 // 为每个有效的观察者启动一个异步任务 std::vectorstd::futurevoid futures; for (const auto weakObs : observersCopy) { if (auto obs weakObs.lock()) { futures.push_back(std::async(std::launch::async, [obs, this]() { obs-Update(*this); })); } } // futures离开作用域其析构函数会等待所有异步任务完成。 // 如果不想等待可以将futures存储到类的成员变量中稍后处理。 } };注意异步通知引入了新的复杂性执行顺序观察者的更新顺序无法保证。线程安全观察者的Update方法必须自身是线程安全的。生命周期需要确保在异步任务执行时观察者对象仍然存活。我们使用shared_ptr已经解决了这个问题。资源消耗大量观察者可能创建大量线程需要合理使用线程池来控制。6.2 按事件类型过滤通知有时观察者只关心主题的特定类型变化。例如一个股票主题可能有“价格变化”、“成交量变化”等不同事件。我们可以扩展接口让观察者注册时指定感兴趣的事件类型主题在通知时进行过滤。// 定义事件类型枚举 enum class StockEventType { PriceChanged, VolumeChanged, // ... }; class AdvancedObserver { public: virtual ~AdvancedObserver() default; virtual void Update(const Subject theChangedSubject, StockEventType eventType) 0; }; class AdvancedStock : public Subject { public: void Attach(ObserverWeakPtr observer, StockEventType interest) { std::lock_guardstd::mutex lock(mutex_); observerInterests_.emplace_back(observer, interest); } void Notify(StockEventType eventType) { std::liststd::pairObserverWeakPtr, StockEventType copy; { std::lock_guardstd::mutex lock(mutex_); copy observerInterests_; } for (const auto [weakObs, interest] : copy) { if (interest eventType) { if (auto obs weakObs.lock()) { // 需要将Observer向下转型为AdvancedObserver这里省略了类型检查 // dynamic_castAdvancedObserver*(obs.get())-Update(*this, eventType); } } } } private: std::liststd::pairObserverWeakPtr, StockEventType observerInterests_; };6.3 使用标准库或第三方库对于生产环境重新造轮子需要充分考虑所有边界情况。实际上C标准库本身没有提供观察者模式的直接实现但我们可以利用std::function和std::signalC11中的boost::signals2或未来标准中的std::experimental::signal来构建更灵活的回调机制。例如使用std::function和std::vector可以快速实现一个信号槽系统#include functional #include vector templatetypename... Args class Signal { public: using SlotType std::functionvoid(Args...); void connect(SlotType slot) { slots_.push_back(std::move(slot)); } void emit(Args... args) { for (const auto slot : slots_) { if (slot) { slot(args...); } } } private: std::vectorSlotType slots_; }; // 使用 Signaldouble priceChangedSignal; // 定义一个信号传递double类型的新价格 priceChangedSignal.connect([](double price) { std::cout “Price: “ price ‘\n’; }); priceChangedSignal.emit(155.5);这种基于std::function的方式更现代、更灵活类型安全且避免了继承体系。但它失去了观察者模式中“观察者接口”的显式契约并且需要自己处理线程安全和对象生命周期问题比如连接后如果对象销毁需要手动断开连接或者使用std::weak_ptr包装std::function。7. 常见陷阱、调试技巧与最佳实践7.1 内存泄漏与循环引用排查问题虽然我们用了weak_ptr但如果设计不当仍可能产生循环引用导致内存泄漏。例如如果主题也持有观察者的shared_ptr而不是weak_ptr而观察者内部又持有主题的shared_ptr就会形成循环导致两者都无法被释放。排查工具Valgrind (Memcheck)Linux/macOS下的经典内存检查工具。AddressSanitizer (ASan)GCC/Clang的编译选项-fsanitizeaddress能在运行时检测内存错误。Visual Studio Diagnostic ToolsWindows下VS自带的内存和性能分析工具。最佳实践始终坚持主题持有观察者的weak_ptr。使用ObserverRegistration这类RAII管理器来明确注册关系的生命周期。在观察者中如果必须持有主题的引用优先使用裸指针或weak_ptr除非你有明确的理由需要共享所有权。7.2 多线程环境下的数据竞争调试问题即使在主题内部加了锁如果观察者的Update方法访问了其他共享数据而这些数据没有被正确保护依然会产生数据竞争。调试技巧代码审查仔细检查所有在Update中被访问的全局或成员变量。线程消毒器 (ThreadSanitizer)GCC/Clang的编译选项-fsanitizethread能检测数据竞争。锁层次分析确保锁的获取顺序一致避免死锁。可以使用std::lock或std::scoped_lockC17来一次性获取多个锁。最佳实践尽量让观察者的Update方法无状态或只操作线程安全的对象。如果Update必须操作共享资源确保该资源有自己的锁机制并且注意锁的粒度避免在持有主题锁的同时再去获取其他锁容易引起死锁。考虑使用消息队列将通知事件放入队列由专门的消费者线程异步处理彻底解耦。7.3 通知风暴与性能优化问题如果主题状态在极短时间内频繁变化例如高速数据流会导致Notify被频繁调用可能引发性能问题“通知风暴”。优化策略合并通知在主题内部设置一个“脏标志”dirty flag。当状态变化时只标记为脏而不立即通知。可以提供一个UpdateIfDirty方法或者在一个固定的时间间隔/事件循环中检查脏标志并统一通知一次。节流 (Throttling)确保在单位时间内通知最多被发送N次。例如使用一个计时器如果上次通知后还没超过100ms则忽略本次状态变化。增量更新如果可能在通知时传递状态变化的差值而不是完整状态减少观察者的处理开销。按需更新让观察者能够查询它是否需要更新。例如在Update调用前主题可以先调用观察者的一个IsInterested方法。7.4 设计模式对比与选用时机观察者模式 vs. 中介者模式中介者模式集中处理对象间的通信所有对象只与中介者交互。而观察者模式是分散的主题和观察者直接耦合尽管是松耦合。当中介者变得过于复杂时观察者模式可能是更好的选择。观察者模式 vs. 发布-订阅模式两者概念非常接近。通常发布-订阅模式中发布者和订阅者通过一个中间的消息代理Message Broker通信彼此完全不知道对方的存在解耦更彻底。而观察者模式中主题至少知道观察者的接口。我们实现的这个模式更接近经典的观察者模式。何时使用当一个对象的改变需要同时改变其他对象且你不知道具体有多少对象需要改变时。当一个对象需要通知其他对象但又不希望与这些对象紧密耦合时。适用于事件驱动系统、模型-视图-控制器MVC架构、实时数据流处理等场景。踩过几次坑之后我的体会是观察者模式入门简单但要在复杂的C项目中用得稳健必须把内存安全、线程安全和性能这三点考虑周全。从使用裸指针到智能指针从同步通知到异步队列每一次改进都是对问题更深入的理解。对于新项目我倾向于从基于std::function的信号槽开始它更轻量灵活对于需要显式接口契约和复杂生命周期管理的模块则采用我们今天打磨的这个weak_ptrRAII的经典观察者模式变体。最后无论用哪种实现一定要为观察者的Update方法写好单元测试模拟主题状态的各种变化序列这是保证系统行为正确的关键。
C++观察者模式实战：从基础原理到工业级实现
发布时间：2026/7/16 5:04:54
1. 项目概述从“通知”到“解耦”的设计哲学今天我们来聊聊C设计模式里一个既经典又实用的家伙——观察者模式。你可能在无数框架和库的源码里见过它的身影比如Qt的信号槽、各种事件驱动系统甚至是游戏引擎里的消息广播。它的核心思想其实特别生活化想象一下你关注了一个公众号每当它发布新文章你作为订阅者就会自动收到推送而你完全不需要每隔五分钟就去刷新一下它的主页。观察者模式干的就是这个事儿——在软件对象之间建立一种“发布-订阅”的依赖关系让一个对象主题的状态变化能自动通知到所有依赖它的对象观察者并且彼此之间还不用知道对方的具体细节。为什么在C的日常训练里要单独拿一天来啃这个模式因为它是解耦的利器。在稍微复杂点的项目里尤其是那些带有用户界面、需要实时数据更新或者事件响应的系统比如股票行情监控、游戏UI状态同步、日志系统硬编码的对象间调用会让代码很快变成一团乱麻。A模块改了状态得亲自去调用B、C、D模块的更新函数一旦要加个E模块又得回头改A的代码。观察者模式通过引入一个抽象的中间层把“谁变了”和“谁需要知道”这两件事分开让系统更容易扩展和维护。今天这篇实战篇我们就抛开那些干巴巴的UML图直接上手从零构建一个工业级强度的观察者模式把内存管理、线程安全、性能优化这些坑一个个填平。2. 模式核心理解“一对多”与“松耦合”的精髓2.1 发布-订阅机制的本质观察者模式也叫发布-订阅模式其核心是定义了一种一对多的依赖关系。让我们拆开看主题Subject也叫被观察者或发布者。它维护一个观察者列表并提供添加Attach、移除Detach和通知Notify观察者的方法。当它的内部状态发生变化时它会遍历这个列表调用每个观察者的更新方法。观察者Observer也叫订阅者。它定义一个更新接口通常是一个Update方法。当接收到主题的通知时观察者会从主题那里拉取或接收主题推送的所需的新数据并执行相应的业务逻辑。关键点在于松耦合主题只知道观察者实现了某个接口但不知道观察者具体是谁、属于哪个类、要做什么。观察者也只知道可以从主题获取信息但通常不关心主题内部如何实现。这种关系就像杂志社和订户杂志社只管按名单寄杂志订户只管收杂志看双方通过“邮寄地址”接口联系而不需要了解对方的生活细节。2.2 推模型 vs. 拉模型数据传递的两种策略在实现通知时有两种主流的数据传递策略选择哪一种直接影响了接口设计和系统效率。推模型Push Model主题在通知观察者时主动将变化的数据作为参数传递给观察者的Update方法。优点对观察者方便直接拿到数据无需再回主题查询。缺点主题需要知道观察者需要什么数据。如果不同的观察者需要的数据不同主题要么传递一个庞大的“数据包”可能包含很多观察者不需要的信息要么为不同类型的观察者定义不同的更新接口这增加了主题的复杂性破坏了封装性。拉模型Pull Model主题在通知观察者时只传递一个指向自身的引用或指针。观察者在自己的Update方法内部通过这个引用主动去主题那里查询它关心的特定数据。优点主题的接口保持简洁统一只有一个Update方法观察者按需索取主题无需关心观察者的数据需求。封装性更好。缺点观察者需要知道主题的查询接口增加了观察者对主题的依赖同时因为观察者要主动拉取可能涉及多次函数调用效率略低于推模型一次传完。在C实战中拉模型更为常用和推荐因为它更好地遵循了面向对象的设计原则尤其是“最少知识原则”。我们的实战也将基于拉模型构建。2.3 C实现的关键挑战与设计选择用C实现一个健壮的观察者模式不能只满足于书本上的示例。我们要直面几个工程问题内存管理观察者通常以指针形式存储在主题的列表中。谁来负责删除这些观察者对象主题删除时列表里的指针怎么办这就是经典的“对象生命周期”问题处理不好就是内存泄漏或悬空指针。线程安全在现代多线程程序中主题的状态可能在任意线程被修改观察者的更新也可能在任意线程被触发。如何保证在遍历观察者列表进行通知时列表本身不会被另一个线程同时修改比如添加或删除观察者性能考量如果观察者数量很多成千上万每次通知都遍历整个列表可能成为瓶颈。通知过程是同步还是异步观察者的更新函数如果很耗时会不会阻塞主题线程依赖管理如何优雅地处理观察者先于主题销毁或者主题先于观察者销毁的情况如何避免一个观察者被多次添加到同一个主题接下来的完整实战我们将逐一解决这些问题构建一个可用于真实项目的观察者模式框架。3. 基础框架搭建定义核心接口与类我们先从最基础的、线程不安全的版本开始把核心流程跑通然后再逐步加固。3.1 定义观察者接口观察者接口极其简单就是一个纯虚函数Update。我们让Update方法接收一个对主题的常量引用这是拉模型的典型做法。// Observer.h #ifndef OBSERVER_H #define OBSERVER_H // 前向声明避免循环包含 class Subject; class Observer { public: virtual ~Observer() default; // 基类析构函数必须是虚函数 virtual void Update(const Subject theChangedSubject) 0; }; #endif // OBSERVER_H关键细节virtual ~Observer() default;这行至关重要。基类的析构函数声明为虚函数是为了当通过基类指针删除派生类对象时能够正确调用派生类的析构函数避免资源泄漏。即使这里没有资源需要释放这也是一个必须养成的好习惯。const Subject theChangedSubject使用常量引用传递主题一是避免拷贝开销二是明确表示观察者不应通过此接口修改主题。3.2 定义主题基类主题类需要维护一个观察者列表并提供注册、注销和通知的方法。// Subject.h #ifndef SUBJECT_H #define SUBJECT_H #include list #include memory // 为了std::weak_ptr #include “Observer.h” class Subject { public: virtual ~Subject() default; // 注册观察者 void Attach(Observer* observer) { // 简单的实现先不考虑去重和线程安全 observers_.push_back(observer); } // 注销观察者 void Detach(Observer* observer) { observers_.remove(observer); } // 通知所有观察者 void Notify() { for (auto* obs : observers_) { if (obs) { obs-Update(*this); } } } protected: // 观察者列表。使用裸指针后续我们会改进。 std::listObserver* observers_; }; #endif // SUBJECT_H这个基础版本的问题内存管理Attach和Detach接受裸指针Observer*。主题完全不知道这个指针指向的对象是谁拥有的何时销毁。如果观察者对象被delete了而主题没有及时Detach那么observers_列表里就留下了一个“悬空指针”后续Notify时调用Update会导致未定义行为通常是程序崩溃。线程安全Attach,Detach,Notify这三个函数如果被多个线程同时调用对std::list的修改和遍历会引发数据竞争。重复添加同一个观察者指针可以被多次Attach导致被多次通知。4. 进阶实现解决内存管理与线程安全4.1 使用智能指针管理观察者生命周期解决内存问题的核心思路是明确所有权。谁拥有观察者对象谁就负责它的生命周期。通常观察者对象由创建它的模块如UI组件、业务逻辑模块拥有。主题不应该拥有观察者它只应该“借用”观察者的引用。因此我们不应该在主题中存储Observer*而应该存储std::weak_ptrObserver。weak_ptr是一种不控制对象生命周期的智能指针它指向一个由shared_ptr管理的对象。它允许你安全地“观察”一个对象而不会阻止该对象被销毁。当对象存在时你可以通过weak_ptr获得一个可用的shared_ptr来使用它当对象已被销毁weak_ptr会过期expired()返回true。这就要求我们的Observer接口也必须由shared_ptr来管理。我们修改接口和实现// Observer.h (修改版) #ifndef OBSERVER_H #define OBSERVER_H #include memory class Subject; class Observer : public std::enable_shared_from_thisObserver { public: virtual ~Observer() default; virtual void Update(const Subject theChangedSubject) 0; }; using ObserverPtr std::shared_ptrObserver; using ObserverWeakPtr std::weak_ptrObserver; #endif // OBSERVER_H// Subject.h (修改版) #ifndef SUBJECT_H #define SUBJECT_H #include list #include memory #include mutex // 用于线程安全 #include “Observer.h” class Subject { public: virtual ~Subject() default; void Attach(ObserverWeakPtr observer) { std::lock_guardstd::mutex lock(mutex_); // 可以在这里添加去重逻辑检查是否已存在 observers_.push_back(std::move(observer)); } void Detach(ObserverWeakPtr observer) { std::lock_guardstd::mutex lock(mutex_); // 由于存储的是weak_ptr比较需要先lock()获取shared_ptr再比较或者直接比较原始指针 // 更简单的做法是在Observer析构时自动Detach见下文。 observers_.remove_if([observer](const ObserverWeakPtr wp) { auto sp1 wp.lock(); auto sp2 observer.lock(); return sp1 sp2 sp1.get() sp2.get(); }); } void Notify() { std::listObserverWeakPtr observersCopy; { std::lock_guardstd::mutex lock(mutex_); observersCopy observers_; // 复制列表缩短锁的持有时间 } for (const auto weakObs : observersCopy) { if (auto obs weakObs.lock()) { // 尝试提升为shared_ptr obs-Update(*this); } } } protected: std::listObserverWeakPtr observers_; mutable std::mutex mutex_; // 保护observers_列表 }; #endif // SUBJECT_H改进点解析std::enable_shared_from_this这是一个混入类模板。当一个类T公有继承它时T的对象就可以安全地生成一个指向自身的shared_ptr通过shared_from_this()成员函数。这在我们需要将this指针作为shared_ptr传递时比如在观察者内部将自己注册到主题是必需的否则直接std::shared_ptrObserver(this)会创建出一个新的、独立的所有权组导致双重删除。weak_ptr的使用主题存储weak_ptr表示它不拥有观察者。在Notify时通过lock()方法尝试将weak_ptr提升为shared_ptr。如果提升成功返回非空的shared_ptr说明观察者对象还活着可以安全调用Update。如果提升失败返回空的shared_ptr说明观察者对象已经被销毁这个weak_ptr已经过期我们直接跳过它。这优雅地解决了悬空指针问题。去重逻辑在Attach中我们可以遍历observers_对每个已有的weak_ptr执行lock()与待添加的observer.lock()比较原始指针如果相同则不再添加。这里为了代码清晰先省略。Detach的复杂性由于列表里存的是weak_ptr直接比较两个weak_ptr是否指向同一对象比较麻烦。上面的代码展示了通过比较它们lock()后得到的shared_ptr的原始指针来实现。但更常见的做法是让观察者在自己的析构函数中主动从所有主题注销自己这样主题就不需要实现复杂的Detach查找逻辑了。4.2 实现观察者自动注销使用RAII管理注册关系为了让观察者的注册/注销更自动化避免遗忘Detach导致的问题我们可以采用RAII资源获取即初始化思想。创建一个辅助类ObserverRegistration它在构造时执行Attach在析构时执行Detach。// ObserverRegistration.h #ifndef OBSERVER_REGISTRATION_H #define OBSERVER_REGISTRATION_H #include “Subject.h” #include “Observer.h” class ObserverRegistration { public: // 构造函数观察者注册到主题 ObserverRegistration(Subject subject, ObserverPtr observer) : subject_(subject), observer_(std::move(observer)) { subject_.Attach(observer_); } // 析构函数自动从主题注销 ~ObserverRegistration() { subject_.Detach(observer_); } // 禁止拷贝 ObserverRegistration(const ObserverRegistration) delete; ObserverRegistration operator(const ObserverRegistration) delete; // 允许移动 ObserverRegistration(ObserverRegistration) default; ObserverRegistration operator(ObserverRegistration) default; private: Subject subject_; ObserverWeakPtr observer_; // 这里存储weak_ptr即可因为Subject内部也是weak_ptr }; #endif // OBSERVER_REGISTRATION_H使用方式// 在某个作用域比如一个UI窗口类的构造函数中 auto myObserver std::make_sharedMyConcreteObserver(); ObserverRegistration reg(*mySubject, myObserver); // 注册 // ... 当reg离开作用域被销毁时自动从mySubject注销这种方法将注册的生命周期与一个局部对象绑定非常清晰安全是C中管理资源依赖的经典手法。4.3 线程安全优化细粒度锁与通知策略我们上面的Notify实现复制了整个观察者列表这虽然缩短了锁的持有时间只锁定了复制操作但如果观察者数量巨大复制开销也不小。另一种更高效的做法是使用读写锁std::shared_mutexC17因为Attach/Detach是写操作而遍历通知是读操作。// SubjectThreadSafe.h (可选进阶版) #include shared_mutex #include list #include memory #include “Observer.h” class ThreadSafeSubject { public: void Attach(ObserverWeakPtr observer) { std::unique_lockstd::shared_mutex lock(mutex_); observers_.push_back(std::move(observer)); } void Detach(ObserverWeakPtr observer) { std::unique_lockstd::shared_mutex lock(mutex_); // ... 查找并移除逻辑 } void Notify() { std::shared_lockstd::shared_mutex lock(mutex_); // 读锁允许多个线程同时Notify // 注意这里遍历时不能调用可能修改observers_的Detach操作。 // 如果观察者在Update中尝试Detach自己会导致死锁或未定义行为。 // 因此在观察者Update中直接Detach自己是危险的。 auto it observers_.begin(); while (it ! observers_.end()) { if (auto obs it-lock()) { obs-Update(*this); it; } else { // 观察者已失效从列表中移除这是写操作但我们在读锁下 // 这违反了读写锁规则。因此更安全的做法是标记删除稍后清理。 // 或者回到使用互斥锁并在Notify中复制列表。 it observers_.erase(it); // 错误在读锁下执行写操作。 } } } private: std::listObserverWeakPtr observers_; mutable std::shared_mutex mutex_; };重要警告在Notify遍历过程中如果尝试修改观察者列表比如移除过期的weak_ptr会与读写锁的语义冲突。因此对于需要在通知过程中清理过期观察者的场景更实用的方案是仍然使用普通的std::mutex。在Notify中复制列表如我们最初所做。或者定期在Attach/Detach时或单独用一个清理函数来移除过期观察者而不是在Notify遍历时做。此外绝对要避免在观察者的Update方法中直接调用主题的Detach来注销自己因为这可能导致如果主题使用互斥锁并且在Notify中持有锁遍历列表那么在Update中调用Detach会尝试再次获取同一个锁造成死锁除非使用可重入锁但std::mutex不可重入。如果主题使用读写锁在Notify的读锁中调用Detach写操作是未定义行为。遍历迭代器失效在遍历列表时从列表中删除当前元素会使迭代器失效导致程序崩溃。安全的做法是观察者将需要注销的请求记录到一个待处理队列中主题在Notify完成后再处理这些注销请求。5. 完整实战案例一个简单的股票价格监控系统让我们用一个具体的例子把上面的概念串起来。假设我们有一个Stock股票类作为主题当股价变化时通知注册的观察者。观察者可以是Display显示面板和Alert价格警报器。5.1 定义具体主题Stock类// Stock.h #ifndef STOCK_H #define STOCK_H #include “Subject.h” #include string class Stock : public Subject { public: Stock(const std::string symbol, double price) : symbol_(symbol), price_(price) {} const std::string GetSymbol() const { return symbol_; } double GetPrice() const { return price_; } // 改变股价并通知所有观察者 void SetPrice(double newPrice) { if (std::abs(price_ - newPrice) 1e-6) { // 简单判断是否有变化 price_ newPrice; Notify(); // 关键状态改变触发通知 } } private: std::string symbol_; double price_; }; #endif // STOCK_H5.2 定义具体观察者// Display.h #ifndef DISPLAY_H #define DISPLAY_H #include “Observer.h” #include “Stock.h” #include iostream #include memory class Display : public Observer, public std::enable_shared_from_thisDisplay { public: explicit Display(const std::string name) : name_(name) {} void Update(const Subject theChangedSubject) override { // 安全的向下转型确认主题类型 const Stock* pStock dynamic_castconst Stock*(theChangedSubject); if (pStock) { std::cout “[Display “ name_ “] Stock “ pStock-GetSymbol() “ price updated to: “ pStock-GetPrice() std::endl; } } private: std::string name_; }; #endif // DISPLAY_H// Alert.h #ifndef ALERT_H #define ALERT_H #include “Observer.h” #include “Stock.h” #include iostream #include memory class Alert : public Observer, public std::enable_shared_from_thisAlert { public: Alert(const std::string stockSymbol, double threshold, bool above) : stockSymbol_(stockSymbol), threshold_(threshold), triggerAbove_(above) {} void Update(const Subject theChangedSubject) override { const Stock* pStock dynamic_castconst Stock*(theChangedSubject); if (pStock pStock-GetSymbol() stockSymbol_) { double currentPrice pStock-GetPrice(); bool conditionMet triggerAbove_ ? (currentPrice threshold_) : (currentPrice threshold_); if (conditionMet) { std::cout “[ALERT!] Stock “ stockSymbol_ “ price is “ (triggerAbove_ ? “above” : “below”) “ threshold “ threshold_ “. Current: “ currentPrice std::endl; } } } private: std::string stockSymbol_; double threshold_; bool triggerAbove_; // true为高于阈值警报false为低于阈值警报 }; #endif // ALERT_H5.3 主程序演示// main.cpp #include “Stock.h” #include “Display.h” #include “Alert.h” #include “ObserverRegistration.h” #include memory #include vector int main() { // 创建主题苹果公司的股票 Stock aapl(“AAPL”, 150.0); // 创建观察者 auto display1 std::make_sharedDisplay(“Main Screen”); auto display2 std::make_sharedDisplay(“Mobile App”); auto alertHigh std::make_sharedAlert(“AAPL”, 160.0, true); // 股价高于160报警 auto alertLow std::make_sharedAlert(“AAPL”, 145.0, false); // 股价低于145报警 // 使用RAII包装器进行注册 std::vectorObserverRegistration registrations; registrations.emplace_back(aapl, display1); registrations.emplace_back(aapl, display2); registrations.emplace_back(aapl, alertHigh); registrations.emplace_back(aapl, alertLow); std::cout “ Initial State ” std::endl; // 初始状态观察者不会自动被通知除非主动调用一次Notify。这里我们先不调用。 std::cout “\n Price Change 1: 155.5 ” std::endl; aapl.SetPrice(155.5); // 自动触发通知 std::cout “\n Price Change 2: 162.3 ” std::endl; aapl.SetPrice(162.3); // 触发高价警报 std::cout “\n Price Change 3: 142.1 ” std::endl; aapl.SetPrice(142.1); // 触发低价警报 std::cout “\n End of Demo ” std::endl; // registrations离开作用域自动执行Detach return 0; }预期输出 Initial State Price Change 1: 155.5 [Display Main Screen] Stock AAPL price updated to: 155.5 [Display Mobile App] Stock AAPL price updated to: 155.5 Price Change 2: 162.3 [Display Main Screen] Stock AAPL price updated to: 162.3 [Display Mobile App] Stock AAPL price updated to: 162.3 [ALERT!] Stock AAPL price is above threshold 160. Current: 162.3 Price Change 3: 142.1 [Display Main Screen] Stock AAPL price updated to: 142.1 [Display Mobile App] Stock AAPL price updated to: 142.1 [ALERT!] Stock AAPL price is below threshold 145. Current: 142.1 End of Demo 6. 性能优化与高级话题6.1 避免在Notify中阻塞异步通知如果观察者的Update方法执行很慢比如涉及文件I/O、网络请求或复杂计算同步的Notify会阻塞主题线程导致主题响应变慢。一种解决方案是使用异步通知。我们可以将通知任务提交到一个线程池中执行。这里简单演示使用std::async需要C11或更高版本进行异步调用// AsyncSubject.h (简化示例) #include future #include vector class AsyncSubject : public Subject { // 继承自我们之前定义的Subject基类 public: void AsyncNotify() { std::lock_guardstd::mutex lock(mutex_); std::listObserverWeakPtr observersCopy observers_; // 复制列表 // 为每个有效的观察者启动一个异步任务 std::vectorstd::futurevoid futures; for (const auto weakObs : observersCopy) { if (auto obs weakObs.lock()) { futures.push_back(std::async(std::launch::async, [obs, this]() { obs-Update(*this); })); } } // futures离开作用域其析构函数会等待所有异步任务完成。 // 如果不想等待可以将futures存储到类的成员变量中稍后处理。 } };注意异步通知引入了新的复杂性执行顺序观察者的更新顺序无法保证。线程安全观察者的Update方法必须自身是线程安全的。生命周期需要确保在异步任务执行时观察者对象仍然存活。我们使用shared_ptr已经解决了这个问题。资源消耗大量观察者可能创建大量线程需要合理使用线程池来控制。6.2 按事件类型过滤通知有时观察者只关心主题的特定类型变化。例如一个股票主题可能有“价格变化”、“成交量变化”等不同事件。我们可以扩展接口让观察者注册时指定感兴趣的事件类型主题在通知时进行过滤。// 定义事件类型枚举 enum class StockEventType { PriceChanged, VolumeChanged, // ... }; class AdvancedObserver { public: virtual ~AdvancedObserver() default; virtual void Update(const Subject theChangedSubject, StockEventType eventType) 0; }; class AdvancedStock : public Subject { public: void Attach(ObserverWeakPtr observer, StockEventType interest) { std::lock_guardstd::mutex lock(mutex_); observerInterests_.emplace_back(observer, interest); } void Notify(StockEventType eventType) { std::liststd::pairObserverWeakPtr, StockEventType copy; { std::lock_guardstd::mutex lock(mutex_); copy observerInterests_; } for (const auto [weakObs, interest] : copy) { if (interest eventType) { if (auto obs weakObs.lock()) { // 需要将Observer向下转型为AdvancedObserver这里省略了类型检查 // dynamic_castAdvancedObserver*(obs.get())-Update(*this, eventType); } } } } private: std::liststd::pairObserverWeakPtr, StockEventType observerInterests_; };6.3 使用标准库或第三方库对于生产环境重新造轮子需要充分考虑所有边界情况。实际上C标准库本身没有提供观察者模式的直接实现但我们可以利用std::function和std::signalC11中的boost::signals2或未来标准中的std::experimental::signal来构建更灵活的回调机制。例如使用std::function和std::vector可以快速实现一个信号槽系统#include functional #include vector templatetypename... Args class Signal { public: using SlotType std::functionvoid(Args...); void connect(SlotType slot) { slots_.push_back(std::move(slot)); } void emit(Args... args) { for (const auto slot : slots_) { if (slot) { slot(args...); } } } private: std::vectorSlotType slots_; }; // 使用 Signaldouble priceChangedSignal; // 定义一个信号传递double类型的新价格 priceChangedSignal.connect([](double price) { std::cout “Price: “ price ‘\n’; }); priceChangedSignal.emit(155.5);这种基于std::function的方式更现代、更灵活类型安全且避免了继承体系。但它失去了观察者模式中“观察者接口”的显式契约并且需要自己处理线程安全和对象生命周期问题比如连接后如果对象销毁需要手动断开连接或者使用std::weak_ptr包装std::function。7. 常见陷阱、调试技巧与最佳实践7.1 内存泄漏与循环引用排查问题虽然我们用了weak_ptr但如果设计不当仍可能产生循环引用导致内存泄漏。例如如果主题也持有观察者的shared_ptr而不是weak_ptr而观察者内部又持有主题的shared_ptr就会形成循环导致两者都无法被释放。排查工具Valgrind (Memcheck)Linux/macOS下的经典内存检查工具。AddressSanitizer (ASan)GCC/Clang的编译选项-fsanitizeaddress能在运行时检测内存错误。Visual Studio Diagnostic ToolsWindows下VS自带的内存和性能分析工具。最佳实践始终坚持主题持有观察者的weak_ptr。使用ObserverRegistration这类RAII管理器来明确注册关系的生命周期。在观察者中如果必须持有主题的引用优先使用裸指针或weak_ptr除非你有明确的理由需要共享所有权。7.2 多线程环境下的数据竞争调试问题即使在主题内部加了锁如果观察者的Update方法访问了其他共享数据而这些数据没有被正确保护依然会产生数据竞争。调试技巧代码审查仔细检查所有在Update中被访问的全局或成员变量。线程消毒器 (ThreadSanitizer)GCC/Clang的编译选项-fsanitizethread能检测数据竞争。锁层次分析确保锁的获取顺序一致避免死锁。可以使用std::lock或std::scoped_lockC17来一次性获取多个锁。最佳实践尽量让观察者的Update方法无状态或只操作线程安全的对象。如果Update必须操作共享资源确保该资源有自己的锁机制并且注意锁的粒度避免在持有主题锁的同时再去获取其他锁容易引起死锁。考虑使用消息队列将通知事件放入队列由专门的消费者线程异步处理彻底解耦。7.3 通知风暴与性能优化问题如果主题状态在极短时间内频繁变化例如高速数据流会导致Notify被频繁调用可能引发性能问题“通知风暴”。优化策略合并通知在主题内部设置一个“脏标志”dirty flag。当状态变化时只标记为脏而不立即通知。可以提供一个UpdateIfDirty方法或者在一个固定的时间间隔/事件循环中检查脏标志并统一通知一次。节流 (Throttling)确保在单位时间内通知最多被发送N次。例如使用一个计时器如果上次通知后还没超过100ms则忽略本次状态变化。增量更新如果可能在通知时传递状态变化的差值而不是完整状态减少观察者的处理开销。按需更新让观察者能够查询它是否需要更新。例如在Update调用前主题可以先调用观察者的一个IsInterested方法。7.4 设计模式对比与选用时机观察者模式 vs. 中介者模式中介者模式集中处理对象间的通信所有对象只与中介者交互。而观察者模式是分散的主题和观察者直接耦合尽管是松耦合。当中介者变得过于复杂时观察者模式可能是更好的选择。观察者模式 vs. 发布-订阅模式两者概念非常接近。通常发布-订阅模式中发布者和订阅者通过一个中间的消息代理Message Broker通信彼此完全不知道对方的存在解耦更彻底。而观察者模式中主题至少知道观察者的接口。我们实现的这个模式更接近经典的观察者模式。何时使用当一个对象的改变需要同时改变其他对象且你不知道具体有多少对象需要改变时。当一个对象需要通知其他对象但又不希望与这些对象紧密耦合时。适用于事件驱动系统、模型-视图-控制器MVC架构、实时数据流处理等场景。踩过几次坑之后我的体会是观察者模式入门简单但要在复杂的C项目中用得稳健必须把内存安全、线程安全和性能这三点考虑周全。从使用裸指针到智能指针从同步通知到异步队列每一次改进都是对问题更深入的理解。对于新项目我倾向于从基于std::function的信号槽开始它更轻量灵活对于需要显式接口契约和复杂生命周期管理的模块则采用我们今天打磨的这个weak_ptrRAII的经典观察者模式变体。最后无论用哪种实现一定要为观察者的Update方法写好单元测试模拟主题状态的各种变化序列这是保证系统行为正确的关键。
相关文章
KronosView 完整数据库设计方案
KronosView 完整数据库设计方案 版本： v2.0 Final 设计时间： 2026-07-10 00:07 数据库引擎： SQLite 3.x 字符集： UTF-8 📋 一、设计原则与目标 核心设计原则 原则说明实现方式数据完整性避免重复、保证一致性UNIQUE约…
开关调节器输出特性与电源设计优化实践
1. 开关调节器输出特性：电源设计的核心考量当我在2013年第一次独立设计工业控制板电源模块时，曾犯过一个典型错误——在未充分理解开关调节器输出特性的情况下，直接照搬参考设计。结果样机在负载突变时出现300mV的电压跌落，导致MC…
Python pow()函数深度解析：从模幂运算到RSA密码学实战
1. 项目概述：为什么pow()值得你花时间深究？ 如果你用Python做过数学计算，或者写过一些简单的脚本， pow() 函数对你来说可能只是一个计算幂运算的工具，比如 pow(2, 3) 返回8。这看起来平平无奇，对吧&…
Java循环控制进阶：while与do..while的实战抉择与break/continue的精准调控
1. 为什么需要while和do..while循环？在日常编程中，我们经常遇到需要重复执行某段代码的场景。比如读取用户输入直到输入合法、处理文件中的每一行数据、或者游戏中的主循环。这时候，循环结构就派上用场了。Java提供了三种主要的循环结构&…
【AI总结】2026年6月 主流国内外大模型总结
目录 引言一、 国际主流模型 1. OpenAI GPT 系列2. Anthropic Claude 系列3. Google Gemini 系列4. Meta Llama 系列5. xAI Grok 系列6. 其他值得关注的国际模型 二、 国内主流模型 1. 百度 文心大模型2. 阿里 通义千问3. 腾讯 混元大模型4. 字节跳动 豆包大模型 / 扣子5. 智谱…
【2014-01-20】cocos2dx学习笔记：判断当前平台
[历史归档] 本文原发布于 cstriker1407.info 个人博客，内容为历史存档，仅供参考。 发布时间： 2014-01-20 ｜ 标题：cocos2dx学习笔记：判断当前平台 ｜ 分类： 编程 / C && C…
【2014-01-20】cocos2dx学习笔记：吞噬事件相应
[历史归档] 本文原发布于 cstriker1407.info 个人博客，内容为历史存档，仅供参考。 发布时间： 2014-01-20 ｜ 标题：cocos2dx学习笔记：吞噬事件相应 ｜ 分类： 编程 / C && C…
Claude Opus更爱抬杠、Sonnet更会安慰人、连中英文性格都不同，Anthropic分析30万条真实对话首次揭秘Claude“人格”！
编译 | 苏宓出品 | CSDN（ID：CSDNnews）“见人说人话，见鬼说鬼话”，放在人身上叫高情商；放在 AI 身上，却意味着模型可能拥有完全不同的“性格”。最近，不少 Claude 用户发现࿰…
Lovart：用Agent重构PSD工作流的运营视觉生产平台
1. 项目概述：为什么“一套运营视觉”成了团队最耗时的黑洞？最近在帮三个不同行业的客户做品牌视觉落地，发现一个惊人共性：哪怕是最基础的「朋友圈九宫格公众号头图小红书封面抖音竖版海报」四件套，从设计初稿到最终交付…
遗传算法解5皇后问题：从Hello World到工业优化的进化实验室
1. 项目概述：为什么用遗传算法解5皇后问题，而不是直接回溯？我带过十几届算法课，也给不少初创团队做过AI架构咨询。每次讲到组合优化问题，学生和工程师的第一反应永远是“写个回溯试试”。这没错——55棋盘上找所有合法…
A--10 Codex Review与GitHub PR工作流实战指南：从代码审查到安全合并
摘要：本文系统讲解如何利用Codex App的Review功能与GitHub PR工作流，实现从代码修改到安全合并的完整流程。涵盖Review面板深度使用、/review命令实战、GitHub Connector配置、PR描述撰写技巧，以及常见问题排查方法。通过多个实战案例和流程图，帮助开发者建立高效的AI辅助代…
uos-exporter核心组件解析：10个关键监控导出器功能详解
uos-exporter核心组件解析：10个关键监控导出器功能详解 【免费下载链接】uos-exporter uos-exporter collects metrics from os 项目地址: https://gitcode.com/openeuler/uos-exporter 前往项目官网免费下载：https://ar.openeuler.org/ar/ uos-…
MQ-2 烟雾传感器 ESP32-S3 驱动实战：ADC 读取与阈值校准 3 步完成
MQ-2 烟雾传感器 ESP32-S3 驱动实战：ADC 读取与阈值校准 3 步完成在智能家居和工业安全监测领域，烟雾检测是一个至关重要的环节。MQ-2 作为一款高性价比的半导体烟雾传感器，因其对多种可燃气体（如液化气、丙烷、氢气等）…
SPEC CPU 2006 v1.0.1 基准测试实战：ARM/X86/MIPS 三平台配置与 3 轮测试结果解读
SPEC CPU 2006 跨平台基准测试深度实战：ARM/X86/MIPS 架构配置优化与结果分析方法论在当今多元化的计算架构时代，如何客观评估不同处理器平台的真实性能成为系统工程师和性能优化专家的核心挑战。SPEC CPU 2006 作为业界公认的计算密集型基准测试套件&am…
每天60s读懂世界：2026年7月11日重点要闻解读
🔥 个人主页：杨利杰YJlio❄️ 个人专栏：《Windows 疑难杂症与工单复盘案例库》 《Sysinternals实战教程》《WINDOWS教程》 《Windows PowerShell 实战》 《人工智能实战合集》《超简单：用Python让Excel飞起来》🌟…
FAE放射组学分析工具：医学影像特征探索的完整解决方案
FAE放射组学分析工具：医学影像特征探索的完整解决方案 【免费下载链接】FAE FeAture Explorer 项目地址: https://gitcode.com/gh_mirrors/fae/FAE 你是否曾经面对海量医学影像数据感到无从下手？想要从CT、MRI等影像中提取有价值的定量特征&#…
0.69B参数实现中文多模态AI：揭秘Qwen3-SmVL模型融合技术的完整实战指南
0.69B参数实现中文多模态AI：揭秘Qwen3-SmVL模型融合技术的完整实战指南 【免费下载链接】happy-llm 📚 从零开始构建大模型 项目地址: https://gitcode.com/GitHub_Trending/ha/happy-llm 还在为大型多模态模型动辄数十亿参数、显存占用高而烦恼&…
解锁AMD Ryzen处理器性能潜力的SMU调试神器：从新手到专家的完整指南
解锁AMD Ryzen处理器性能潜力的SMU调试神器：从新手到专家的完整指南 【免费下载链接】SMUDebugTool A dedicated tool to help write/read various parameters of Ryzen-based systems, such as manual overclock, SMU, PCI, CPUID, MSR and Power Table. 项目地址…