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