1. 項(xiàng)目概述為什么我們需要在C11時(shí)代重新審視觀察者模式在軟件開發(fā)的日常里我們經(jīng)常遇到一個(gè)場(chǎng)景一個(gè)對(duì)象我們稱之為“主題”的狀態(tài)發(fā)生了變化而其他一系列對(duì)象我們稱之為“觀察者”需要立刻知道這個(gè)變化并做出相應(yīng)的反應(yīng)。比如一個(gè)圖形用戶界面GUI中的按鈕被點(diǎn)擊了菜單、工具欄、狀態(tài)欄都需要更新又或者一個(gè)游戲引擎中的角色生命值發(fā)生了變化血條UI、音效系統(tǒng)、任務(wù)系統(tǒng)都需要被通知。這種“一對(duì)多”的依賴關(guān)系如果直接用硬編碼的方式去調(diào)用代碼會(huì)變得高度耦合難以維護(hù)和擴(kuò)展。這時(shí)候設(shè)計(jì)模式就派上用場(chǎng)了而觀察者模式Observer Pattern正是為解決這類問題而生的經(jīng)典模式。那么為什么還要專門用C11來實(shí)現(xiàn)它呢這不僅僅是“用新語法重寫舊模式”那么簡(jiǎn)單。C11標(biāo)準(zhǔn)為這門語言帶來了革命性的變化引入了智能指針、lambda表達(dá)式、移動(dòng)語義、右值引用、std::function和std::bind等一系列現(xiàn)代特性。這些特性讓我們能夠以更安全、更高效、更優(yōu)雅的方式來實(shí)現(xiàn)觀察者模式徹底告別過去那些基于原始指針、手動(dòng)管理內(nèi)存、接口臃腫的實(shí)現(xiàn)方式。使用C11我們可以輕松解決內(nèi)存泄漏、懸垂指針的問題讓回調(diào)的注冊(cè)和使用變得異常靈活代碼的可讀性和可維護(hù)性也大大提升。這篇文章就是從一個(gè)常年奮戰(zhàn)在一線的C開發(fā)者的角度來和你一起拆解如何用C11的特性打造一個(gè)工業(yè)級(jí)強(qiáng)度的觀察者模式實(shí)現(xiàn)。我們會(huì)從最基礎(chǔ)的思路開始一步步深入到線程安全、性能優(yōu)化等高級(jí)話題并分享我在實(shí)際項(xiàng)目中踩過的坑和總結(jié)的經(jīng)驗(yàn)。無論你是剛接觸設(shè)計(jì)模式的初學(xué)者還是想優(yōu)化現(xiàn)有代碼的老手相信都能從中獲得一些實(shí)用的啟發(fā)。2. 核心設(shè)計(jì)思路從傳統(tǒng)模式到現(xiàn)代C的演進(jìn)在動(dòng)手寫代碼之前我們先得把思路理清楚。觀察者模式的核心思想是“解耦”讓主題和觀察者之間不直接依賴而是通過一個(gè)抽象的接口進(jìn)行通信。傳統(tǒng)C98/03時(shí)代的實(shí)現(xiàn)大致框架是這樣的定義一個(gè)抽象的Observer觀察者接口通常包含一個(gè)update()之類的純虛函數(shù)。具體的觀察者類繼承這個(gè)接口實(shí)現(xiàn)自己的update邏輯。定義一個(gè)Subject主題基類或具體類內(nèi)部維護(hù)一個(gè)觀察者指針通常是原始指針的列表。Subject提供attach注冊(cè)、detach注銷和notify通知方法。當(dāng)主題狀態(tài)變化時(shí)調(diào)用notify遍歷列表調(diào)用每個(gè)觀察者的update方法。這個(gè)框架本身沒問題但問題出在實(shí)現(xiàn)細(xì)節(jié)上尤其是在C中。使用原始指針管理觀察者列表誰負(fù)責(zé)釋放這些指針觀察者先于主題被銷毀怎么辦這就是典型的資源管理和對(duì)象生命周期問題。C11的智能指針特別是std::shared_ptr和std::weak_ptr為我們提供了完美的解決方案。我的設(shè)計(jì)思路是進(jìn)行一場(chǎng)“現(xiàn)代化改造”用std::shared_ptr管理觀察者對(duì)象的所有權(quán)主題持有觀察者的std::shared_ptr意味著只要主題還存在它注冊(cè)的觀察者就不會(huì)被意外釋放。這解決了手動(dòng)管理內(nèi)存的麻煩。但更要警惕循環(huán)引用如果觀察者也反向持有主題的shared_ptr就會(huì)形成循環(huán)引用導(dǎo)致內(nèi)存永遠(yuǎn)無法釋放。因此在主題內(nèi)部我們應(yīng)使用std::weak_ptr來引用觀察者。weak_ptr是一種“弱引用”它不會(huì)增加對(duì)象的引用計(jì)數(shù)因此不會(huì)阻止其所指對(duì)象被銷毀。在通知時(shí)我們?cè)賴L試將weak_ptr提升lock()為shared_ptr如果提升成功說明觀察者還活著就調(diào)用它如果失敗說明觀察者已被銷毀我們就安全地將其從列表中移除。這是現(xiàn)代C實(shí)現(xiàn)觀察者模式最核心、最安全的技巧。用std::function替代固定的接口為什么觀察者一定要繼承自某個(gè)基類、實(shí)現(xiàn)某個(gè)特定簽名的update函數(shù)呢C11的std::function提供了通用的可調(diào)用對(duì)象包裝器。我們可以讓主題接受任何可調(diào)用對(duì)象函數(shù)、lambda、仿函數(shù)、綁定后的成員函數(shù)等作為觀察者。這極大地增加了靈活性實(shí)現(xiàn)了徹底的接口解耦。利用std::mutex保證線程安全在現(xiàn)代多線程程序中主題和觀察者很可能在不同的線程中被訪問和修改。對(duì)觀察者列表的增刪改查操作必須是原子的否則會(huì)導(dǎo)致數(shù)據(jù)競(jìng)爭(zhēng)和未定義行為。我們需要用互斥鎖來保護(hù)這個(gè)共享資源。基于以上思路我們的現(xiàn)代觀察者模式將圍繞以下幾個(gè)核心組件構(gòu)建一個(gè)使用std::vectorstd::weak_ptr...或類似結(jié)構(gòu)存儲(chǔ)觀察者的主題類一個(gè)用于包裝任意回調(diào)的std::function以及確保線程安全的鎖機(jī)制。2.1 為何選擇weak_ptrfunction的組合這是一個(gè)關(guān)鍵的設(shè)計(jì)決策。讓我們深入分析一下為什么這是最佳組合。使用weak_ptr的必要性想象一個(gè)場(chǎng)景一個(gè)UI組件觀察者訂閱了某個(gè)數(shù)據(jù)模型主題的變化。當(dāng)用戶關(guān)閉這個(gè)UI窗口時(shí)組件對(duì)象被銷毀。如果主題仍然持有該組件的shared_ptr那么這個(gè)組件對(duì)象將因?yàn)橐糜?jì)數(shù)不為零而無法被正確釋放導(dǎo)致內(nèi)存泄漏。如果主題持有的是weak_ptr則不會(huì)影響組件的生命周期。當(dāng)主題下次通知時(shí)通過lock()會(huì)發(fā)現(xiàn)該weak_ptr已失效從而可以安全地清理這個(gè)“僵尸”觀察者。這實(shí)現(xiàn)了觀察者生命周期的自動(dòng)管理是資源安全的基石。使用std::function的靈活性傳統(tǒng)的基于繼承的接口方式強(qiáng)制所有觀察者必須擁有相同的函數(shù)簽名如void update(int)。這很不靈活。也許有的觀察者只需要一個(gè)事件通知不需要參數(shù)有的需要豐富的上下文信息。使用std::function我們可以定義主題通知時(shí)傳遞的參數(shù)比如一個(gè)包含事件詳情的結(jié)構(gòu)體而觀察者只需要提供一個(gè)能接受該參數(shù)的函數(shù)即可。它可以是全局函數(shù)、類的靜態(tài)成員函數(shù)、通過std::bind綁定了對(duì)象的成員函數(shù)或者一個(gè)捕獲了上下文的lambda表達(dá)式。這種靈活性讓代碼的適應(yīng)性變得極強(qiáng)。// 傳統(tǒng)方式必須繼承 class MyObserver : public Observer { public: void update(int value) override { /* ... */ } }; // 現(xiàn)代方式任何可調(diào)用對(duì)象都可以 subject.attach([](const Event e) { std::cout “Lambda caught: ” e.id std::endl; }); subject.attach(std::bind(MyClass::onEvent, myObj, std::placeholders::_1));這種組合帶來的好處是安全與靈活并存。既避免了內(nèi)存問題又解耦了接口約束這正是現(xiàn)代C設(shè)計(jì)所追求的目標(biāo)。3. 核心實(shí)現(xiàn)細(xì)節(jié)與類設(shè)計(jì)接下來我們進(jìn)入具體的實(shí)現(xiàn)環(huán)節(jié)。我將展示一個(gè)支持模板化事件類型、線程安全、且易于使用的觀察者模式實(shí)現(xiàn)。3.1 定義事件類型與觀察者別名首先我們不固定事件類型而是使用模板讓主題可以通知任何類型的事件數(shù)據(jù)。同時(shí)我們定義觀察者的類型為一個(gè)接受特定事件類型的std::function。#include memory #include functional #include vector #include mutex #include algorithm // 前向聲明主題類 template typename EventT class Subject; // 觀察者類型一個(gè)接收EventT類型參數(shù)的函數(shù)對(duì)象 template typename EventT using Observer std::functionvoid(const EventT); // 觀察者弱引用類型 template typename EventT using ObserverWeakPtr std::weak_ptrObserverEventT; // 觀察者強(qiáng)引用類型主要用于外部保存 template typename EventT using ObserverPtr std::shared_ptrObserverEventT;這里的關(guān)鍵點(diǎn)是Observer本身是一個(gè)std::function而我們將它的shared_ptr和weak_ptr進(jìn)行了別名定義。為什么需要shared_ptrObserver因?yàn)閟td::function本身是可拷貝的類型但有時(shí)我們希望能夠明確地標(biāo)識(shí)和注銷某個(gè)特定的觀察者回調(diào)。將其包裝進(jìn)shared_ptr我們就得到了一個(gè)唯一的、可管理的句柄。3.2 實(shí)現(xiàn)主題Subject類主題類是整個(gè)模式的核心。它需要管理一個(gè)觀察者列表并提供注冊(cè)、注銷和通知的方法。template typename EventT class Subject { public: Subject() default; ~Subject() default; // 禁止拷貝和賦值通常主題是唯一的。如果需要可以手動(dòng)實(shí)現(xiàn)或啟用移動(dòng)語義。 Subject(const Subject) delete; Subject operator(const Subject) delete; /** * 注冊(cè)一個(gè)觀察者。 * param observer 觀察者函數(shù)對(duì)象 * return 返回一個(gè)ObserverPtr可用于后續(xù)顯式注銷該觀察者。 */ ObserverPtrEventT attach(ObserverEventT observer) { auto observerPtr std::make_sharedObserverEventT(std::move(observer)); { std::lock_guardstd::mutex lock(mutex_); observers_.emplace_back(observerPtr); } return observerPtr; } /** * 注銷一個(gè)觀察者通過weak_ptr。 * 這是線程安全的惰性刪除。實(shí)際刪除發(fā)生在notify時(shí)。 * param observerWeak 要注銷的觀察者的弱引用 */ void detach(const ObserverWeakPtrEventT observerWeak) { std::lock_guardstd::mutex lock(mutex_); // 我們只是標(biāo)記一下真正的清理在notify時(shí)進(jìn)行。 // 這里可以將對(duì)應(yīng)的weak_ptr重置或者放入一個(gè)待刪除列表。 // 一種簡(jiǎn)單實(shí)現(xiàn)在notify遍歷時(shí)跳過無法lock的weak_ptr并移除。 // 另一種做法這里直接查找并移除。我們采用后者更及時(shí)。 auto it std::find_if(observers_.begin(), observers_.end(), [observerWeak](const ObserverWeakPtrEventT wp) { return !(wp.owner_before(observerWeak) || observerWeak.owner_before(wp)); }); if (it ! observers_.end()) { observers_.erase(it); } } /** * 通知所有觀察者。 * param event 要傳遞的事件對(duì)象 */ void notify(const EventT event) { std::vectorObserverPtrEventT validObservers; { std::lock_guardstd::mutex lock(mutex_); // 1. 清理失效的觀察者 observers_.erase( std::remove_if(observers_.begin(), observers_.end(), [](const ObserverWeakPtrEventT wp) { return wp.expired(); }), observers_.end()); // 2. 收集當(dāng)前有效的觀察者強(qiáng)引用避免在調(diào)用回調(diào)時(shí)持有鎖。 validObservers.reserve(observers_.size()); for (const auto weakObserver : observers_) { if (auto strongObserver weakObserver.lock()) { validObservers.push_back(strongObserver); } } } // 鎖在這里釋放 // 3. 在無鎖狀態(tài)下調(diào)用觀察者 for (const auto observer : validObservers) { try { (*observer)(event); // 調(diào)用std::function } catch (...) { // 強(qiáng)烈建議單個(gè)觀察者的異常不應(yīng)影響其他觀察者。 // 這里可以記錄日志但繼續(xù)執(zhí)行。 // 在實(shí)際項(xiàng)目中需要定義更完善的錯(cuò)誤處理策略。 } } } // 獲取當(dāng)前觀察者數(shù)量主要用于調(diào)試 size_t observerCount() const { std::lock_guardstd::mutex lock(mutex_); return observers_.size(); } private: mutable std::mutex mutex_; std::vectorObserverWeakPtrEventT observers_; };這個(gè)實(shí)現(xiàn)包含了幾個(gè)重要的設(shè)計(jì)點(diǎn)和技巧線程安全所有對(duì)observers_容器的修改操作attach,detach,notify中的清理和收集都通過std::lock_guard保護(hù)。notify方法中我們先收集有效的觀察者強(qiáng)引用到一個(gè)局部向量然后釋放鎖最后再調(diào)用回調(diào)。這是關(guān)鍵優(yōu)化如果在持有鎖的情況下調(diào)用用戶提供的回調(diào)函數(shù)萬一回調(diào)函數(shù)執(zhí)行時(shí)間很長(zhǎng)或者它內(nèi)部又嘗試去attach/detach同一個(gè)主題造成遞歸鎖或死鎖就會(huì)導(dǎo)致性能瓶頸甚至死鎖。先收集再調(diào)用的方式避免了這個(gè)問題。惰性清理與及時(shí)清理結(jié)合在notify中我們先使用std::remove_if和expired()方法清理掉所有已經(jīng)失效的weak_ptr。detach方法也提供了主動(dòng)移除的途徑。兩種方式結(jié)合保證了列表的整潔。異常安全在遍歷調(diào)用觀察者時(shí)我們用try-catch塊包裹了每個(gè)調(diào)用。確保一個(gè)觀察者的崩潰拋出異常不會(huì)阻止其他觀察者接收到通知。在生產(chǎn)環(huán)境中這里應(yīng)該記錄下異常信息以便調(diào)試。使用std::move優(yōu)化在attach中我們使用std::move(observer)來轉(zhuǎn)移傳入的std::function避免不必要的拷貝。注意weak_ptr的比較不能直接用。我們使用了owner_before來檢查兩個(gè)weak_ptr是否指向同一個(gè)控制塊這是標(biāo)準(zhǔn)庫推薦的方式來判斷weak_ptr是否“等價(jià)”。3.3 如何使用這個(gè)現(xiàn)代觀察者模式下面我們通過一個(gè)簡(jiǎn)單的例子來演示如何使用上面實(shí)現(xiàn)的Subject類。#include iostream #include string // 定義一個(gè)具體的事件類型 struct ButtonClickEvent { int buttonId; std::string buttonName; long timestamp; }; int main() { SubjectButtonClickEvent buttonSubject; // 觀察者1使用Lambda表達(dá)式 auto observer1 buttonSubject.attach([](const ButtonClickEvent e) { std::cout “[Lambda] Button clicked: ” e.buttonName “ (ID: ” e.buttonId “)” std::endl; }); // 觀察者2使用普通函數(shù) void logEvent(const ButtonClickEvent e); auto observer2 buttonSubject.attach(logEvent); // 觀察者3使用綁定成員函數(shù) class Logger { public: void onButtonClicked(const ButtonClickEvent e) { std::cout “[Logger] Click recorded at ” e.timestamp std::endl; } }; Logger myLogger; auto observer3 buttonSubject.attach(std::bind(Logger::onButtonClicked, myLogger, std::placeholders::_1)); // 模擬事件發(fā)生 ButtonClickEvent event{1001, “SubmitButton”, 1234567890}; std::cout “Notifying observers...“ std::endl; buttonSubject.notify(event); std::cout “Current observer count: ” buttonSubject.observerCount() std::endl; // 注銷一個(gè)觀察者 std::cout “\nDetaching observer1...” std::endl; buttonSubject.detach(observer1); buttonSubject.notify(event); // 這次observer1不會(huì)被調(diào)用 std::cout “Current observer count after detach: ” buttonSubject.observerCount() std::endl; // observer2和observer3會(huì)在main函數(shù)結(jié)束時(shí)隨著buttonSubject的銷毀 // 其weak_ptr在notify時(shí)被清理不會(huì)造成內(nèi)存泄漏。 return 0; } void logEvent(const ButtonClickEvent e) { std::cout “[Function] Click event logged.” std::endl; }這個(gè)例子展示了現(xiàn)代實(shí)現(xiàn)的巨大優(yōu)勢(shì)注冊(cè)觀察者變得極其自由。你不再需要為了一個(gè)回調(diào)而去繼承一個(gè)基類并實(shí)現(xiàn)虛函數(shù)任何可調(diào)用對(duì)象都可以直接“扔”給主題。代碼簡(jiǎn)潔意圖清晰。4. 高級(jí)話題與性能優(yōu)化一個(gè)基礎(chǔ)的、線程安全的觀察者模式實(shí)現(xiàn)已經(jīng)完成了。但在高性能、高并發(fā)的實(shí)際項(xiàng)目中我們還需要考慮更多。4.1 處理通知順序與優(yōu)先級(jí)默認(rèn)情況下觀察者被通知的順序就是它們被注冊(cè)的順序std::vector的遍歷順序。但有時(shí)業(yè)務(wù)上需要優(yōu)先級(jí)。我們可以修改attach方法接受一個(gè)優(yōu)先級(jí)參數(shù)并在內(nèi)部使用一個(gè)按優(yōu)先級(jí)排序的容器比如std::multimap或帶排序的std::vector。template typename EventT class PrioritySubject { public: using Priority int; // 優(yōu)先級(jí)數(shù)字越小優(yōu)先級(jí)越高 using ObserverItem std::pairPriority, ObserverWeakPtrEventT; ObserverPtrEventT attach(ObserverEventT observer, Priority priority 0) { auto observerPtr std::make_sharedObserverEventT(std::move(observer)); { std::lock_guardstd::mutex lock(mutex_); // 按優(yōu)先級(jí)插入同優(yōu)先級(jí)按插入時(shí)間此處為插入位置 observers_.emplace_back(priority, observerPtr); // 每次插入后排序不是最高效的可以改為在notify時(shí)排序或使用有序容器。 std::stable_sort(observers_.begin(), observers_.end(), [](const ObserverItem a, const ObserverItem b) { return a.first b.first; }); } return observerPtr; } // ... 其他方法需要相應(yīng)調(diào)整比如detach和notify需要處理pair結(jié)構(gòu) private: mutable std::mutex mutex_; std::vectorObserverItem observers_; };注意在每次attach后都進(jìn)行全排序在觀察者數(shù)量多、注冊(cè)頻繁的場(chǎng)景下性能較差。更優(yōu)的方案是使用std::multimapPriority, ObserverWeakPtrEventT它本身就能保持鍵值有序。但需要注意multimap的迭代器穩(wěn)定性問題以及在多線程下修改結(jié)構(gòu)的復(fù)雜性。4.2 異步通知在某些場(chǎng)景下我們可能希望主題在notify時(shí)不要阻塞當(dāng)前線程而是將通知任務(wù)拋到另一個(gè)線程去異步執(zhí)行。這可以防止耗時(shí)的觀察者回調(diào)拖慢主題的狀態(tài)更新流程。我們可以結(jié)合C11的std::async或線程池來實(shí)現(xiàn)。下面是一個(gè)使用std::async進(jìn)行異步通知的簡(jiǎn)化示例template typename EventT void SubjectEventT::notifyAsync(const EventT event) { std::vectorObserverPtrEventT validObservers; { std::lock_guardstd::mutex lock(mutex_); // ... 同樣的清理和收集邏輯 observers_.erase(std::remove_if(...), observers_.end()); for (const auto weakObserver : observers_) { if (auto strongObserver weakObserver.lock()) { validObservers.push_back(strongObserver); } } } // 為每個(gè)觀察者啟動(dòng)一個(gè)異步任務(wù) std::vectorstd::futurevoid futures; futures.reserve(validObservers.size()); for (const auto observer : validObservers) { futures.emplace_back(std::async(std::launch::async, [observer, event]() { try { (*observer)(event); } catch (...) { // 處理異常 } })); } // 可以選擇等待所有異步任務(wù)完成也可以不等待fire-and-forget。 // 這里等待只是為了示例實(shí)際中可能不需要。 for (auto fut : futures) { fut.wait(); // 或者使用fut.get()來獲取異常 } }重要提醒異步通知引入了新的復(fù)雜性。觀察者回調(diào)的執(zhí)行順序無法保證且它們可能并發(fā)執(zhí)行因此觀察者的實(shí)現(xiàn)必須是線程安全的。此外大量頻繁的異步任務(wù)創(chuàng)建和銷毀開銷很大在生產(chǎn)環(huán)境中務(wù)必使用線程池來管理這些任務(wù)而不是為每個(gè)通知都創(chuàng)建新線程。4.3 使用std::shared_mutexC17優(yōu)化讀多寫少的場(chǎng)景在我們的實(shí)現(xiàn)中notify讀操作和attach/detach寫操作使用了同一個(gè)互斥鎖std::mutex。這是一種保守但安全的做法。然而在觀察者列表不常變化寫操作少但通知非常頻繁讀操作極多的場(chǎng)景下這會(huì)造成不必要的競(jìng)爭(zhēng)影響notify的性能。C17引入了std::shared_mutex共享互斥量它支持“共享鎖”多個(gè)線程可以同時(shí)讀和“獨(dú)占鎖”只有一個(gè)線程可以寫。我們可以利用它來優(yōu)化#include shared_mutex template typename EventT class OptimizedSubject { public: ObserverPtrEventT attach(ObserverEventT observer) { auto observerPtr std::make_sharedObserverEventT(std::move(observer)); { std::unique_lockstd::shared_mutex lock(mutex_); // 寫操作用unique_lock observers_.emplace_back(observerPtr); } return observerPtr; } void notify(const EventT event) { std::vectorObserverPtrEventT validObservers; { std::shared_lockstd::shared_mutex lock(mutex_); // 讀操作用shared_lock // 注意shared_lock下不能修改容器所以不能在這里執(zhí)行erase清理。 // 我們需要先收集但失效的weak_ptr也會(huì)被收集在lock外調(diào)用前檢查。 validObservers.reserve(observers_.size()); for (const auto weakObserver : observers_) { if (auto strongObserver weakObserver.lock()) { validObservers.push_back(strongObserver); } } } // 讀鎖釋放 // 調(diào)用觀察者 for (const auto observer : validObservers) { try { (*observer)(event); } catch (...) { /* ... */ } } // 惰性清理在下次notify或單獨(dú)調(diào)用清理方法時(shí)用寫鎖進(jìn)行。 // 可以引入一個(gè)計(jì)數(shù)器每N次通知后清理一次避免每次讀都要寫的沖突。 cleanupIfNeeded(); } private: void cleanupIfNeeded() { static std::atomicint callCount{0}; if (callCount % 100 0) { // 每100次通知清理一次 std::unique_lockstd::shared_mutex lock(mutex_); observers_.erase(std::remove_if(observers_.begin(), observers_.end(), [](const auto wp) { return wp.expired(); }), observers_.end()); } } mutable std::shared_mutex mutex_; std::vectorObserverWeakPtrEventT observers_; };這個(gè)優(yōu)化在觀察者數(shù)量龐大、通知極其頻繁的系統(tǒng)中能帶來顯著的性能提升。代價(jià)是代碼邏輯變得更復(fù)雜一些并且清理策略需要精心設(shè)計(jì)以避免臟數(shù)據(jù)積累過多。5. 常見問題、陷阱與調(diào)試技巧即使有了一個(gè)健壯的實(shí)現(xiàn)在實(shí)際使用觀察者模式時(shí)仍然會(huì)遇到不少坑。這里記錄一些我踩過的雷和解決方法。5.1 生命周期管理誰該持有誰的指針這是最核心的問題。我們的實(shí)現(xiàn)中主題持有觀察者的weak_ptr外部用戶比如創(chuàng)建觀察者的模塊持有觀察者的shared_ptr即attach的返回值。這個(gè)shared_ptr是觀察者回調(diào)對(duì)象的唯一所有者。陷阱如果外部用戶過早釋放了shared_ptr那么觀察者回調(diào)對(duì)象就被銷毀了主題內(nèi)部的weak_ptr會(huì)失效這是正常行為。陷阱如果外部用戶沒有保存attach返回的shared_ptr那么這個(gè)臨時(shí)shared_ptr在語句結(jié)束后就被銷毀觀察者會(huì)立即失效導(dǎo)致永遠(yuǎn)收不到通知。務(wù)必保存好attach的返回值最佳實(shí)踐通常將返回的ObserverPtr作為觀察者對(duì)象的成員變量保存在觀察者對(duì)象的析構(gòu)函數(shù)中調(diào)用主題的detach方法如果主題還存活。這實(shí)現(xiàn)了自動(dòng)化的注冊(cè)與反注冊(cè)。class MyController { public: MyController(SubjectMyEvent subject) : subject_(subject) { // 注冊(cè)并保存token observerToken_ subject_.attach([this](const MyEvent e) { this-handleEvent(e); }); } ~MyController() { // 反注冊(cè) subject_.detach(observerToken_); } private: void handleEvent(const MyEvent e) { /* ... */ } SubjectMyEvent subject_; ObserverPtrMyEvent observerToken_; // 關(guān)鍵 };5.2 在回調(diào)中再次修改觀察者列表這是一個(gè)典型的遞歸鎖或死鎖場(chǎng)景。如果一個(gè)觀察者的回調(diào)函數(shù)內(nèi)部又調(diào)用了同一個(gè)主題的attach或detach方法而我們的mutex_不是遞歸鎖std::mutex不是那么程序會(huì)死鎖。解決方案1不推薦使用std::recursive_mutex。但這會(huì)隱藏設(shè)計(jì)問題并可能帶來性能開銷和復(fù)雜性。解決方案2推薦嚴(yán)格禁止在觀察者回調(diào)中同步修改其所屬的主題的觀察者列表。如果確實(shí)需要可以將修改操作“延遲”執(zhí)行。例如在回調(diào)中只是將一個(gè)修改請(qǐng)求放入一個(gè)隊(duì)列主題在完成本次notify的所有回調(diào)遍歷后再去處理這個(gè)隊(duì)列。這需要更復(fù)雜的狀態(tài)管理。我們的實(shí)現(xiàn)中notify方法在調(diào)用回調(diào)前已經(jīng)釋放了鎖所以觀察者回調(diào)中調(diào)用attach是安全的因?yàn)閍ttach會(huì)重新獲取鎖。但是如果回調(diào)中調(diào)用的是detach自己而detach需要遍歷列表查找這可能會(huì)破壞notify中正在進(jìn)行的迭代器雖然我們已經(jīng)收集了強(qiáng)引用但detach會(huì)修改原始列表。所以最安全的做法依然是約定不要在回調(diào)中修改當(dāng)前主題的觀察者列表。5.3 性能瓶頸與優(yōu)化點(diǎn)鎖競(jìng)爭(zhēng)這是多線程下最主要的瓶頸。優(yōu)化方法包括使用讀寫鎖shared_mutex、減小鎖的粒度如分片、或使用無鎖數(shù)據(jù)結(jié)構(gòu)難度極高。對(duì)于我們這個(gè)模式使用shared_mutex并配合先收集后回調(diào)的策略在大多數(shù)場(chǎng)景下已經(jīng)足夠。weak_ptr的lock()開銷lock()是一個(gè)原子操作有一定開銷。在觀察者數(shù)量很多時(shí)遍歷并lock每個(gè)weak_ptr的成本不容忽視。如果觀察者的生命周期和主題緊密綁定且不會(huì)先于主題銷毀可以考慮在調(diào)試穩(wěn)定后在性能關(guān)鍵路徑上冒險(xiǎn)使用shared_ptr并仔細(xì)管理生命周期或者使用其他ID機(jī)制來管理觀察者。動(dòng)態(tài)內(nèi)存分配每次attach都涉及創(chuàng)建shared_ptr和weak_ptr以及可能的容器擴(kuò)容。對(duì)于高頻注冊(cè)/注銷的場(chǎng)景可以考慮使用對(duì)象池來復(fù)用function對(duì)象的內(nèi)存或者使用固定大小的環(huán)形緩沖區(qū)。5.4 調(diào)試技巧觀察者不生效怎么辦當(dāng)發(fā)現(xiàn)事件發(fā)出了但觀察者沒反應(yīng)時(shí)可以按以下步驟排查檢查attach返回值是否被保存這是最常見的原因。沒有保存ObserverPtr回調(diào)對(duì)象立刻被銷毀。檢查觀察者生命周期確保發(fā)出notify時(shí)觀察者對(duì)象如果是綁定成員函數(shù)或者捕獲了上下文資源的lambda還活著。檢查事件類型是否匹配std::function對(duì)參數(shù)類型要求嚴(yán)格。如果Subjectint的觀察者注冊(cè)了一個(gè)void(double)的函數(shù)編譯不會(huì)報(bào)錯(cuò)因?yàn)槟０搴蛃td::function的構(gòu)造是寬松的但在notify調(diào)用時(shí)會(huì)發(fā)生類型轉(zhuǎn)換錯(cuò)誤或靜默失敗。確保事件類型嚴(yán)格匹配。在notify方法中添加調(diào)試日志打印出當(dāng)前觀察者列表的有效數(shù)量以及每次嘗試調(diào)用前后的信息看是列表空了還是調(diào)用過程出錯(cuò)了。檢查多線程時(shí)序問題是否有可能在notify遍歷的過程中另一個(gè)線程剛好detach了某個(gè)觀察者我們的實(shí)現(xiàn)先收集強(qiáng)引用可以避免迭代器失效但收集之后、調(diào)用之前如果觀察者被detach并銷毀我們?nèi)匀粫?huì)調(diào)用一個(gè)已銷毀對(duì)象的函數(shù)因?yàn)閺?qiáng)引用shared_ptr還保持著對(duì)象存活。這強(qiáng)調(diào)了detach需要同步或者確保業(yè)務(wù)邏輯上不會(huì)出現(xiàn)這種極端競(jìng)爭(zhēng)。最后我個(gè)人在大型項(xiàng)目中更傾向于使用一個(gè)中心化的事件總線Event Bus來管理多個(gè)主題和觀察者上述的Subject類可以作為事件總線中針對(duì)某一類事件的通道實(shí)現(xiàn)。這樣架構(gòu)更清晰也便于進(jìn)行全局的監(jiān)控和管理。但無論如何這個(gè)基于C11現(xiàn)代特性的觀察者模式核心實(shí)現(xiàn)都是構(gòu)建更復(fù)雜事件系統(tǒng)的一塊堅(jiān)實(shí)、可靠的基石。