【編者按】本文作者是 BAE 系統公司的軟件工程師 Justin Albano。在本篇文章中，作者通過在 Java8 環境下實現觀察者模式的實例，進一步介紹了什麼是觀察者模式、專業化及其命名規則，供大家參考學習。
觀 察者（Observer）模式又名發佈-訂閱（Publish/Subscribe）模式，是四人組（GoF，即 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides）在1994合著的《設計模式:可複用面向對象軟件的基礎》中提出的（詳見書中293-313頁）。儘管這種模式已經有相當長的歷史， 它仍然廣泛適用於各種場景，甚至成爲了標準Java庫的一個組成部分。目前雖然已經有大量關於觀察者模式的文章，但它們都專注於在 Java 中的實現，卻忽視了開發者在Java中使用觀察者模式時遇到的各種問題。
本文的寫作初衷就是爲了填補這一空白：本文主要介紹通過使用 Java8 架構實現觀察者模式，並在此基礎上進一步探討關於經典模式的複雜問題，包括匿名內部類、lambda 表達式、線程安全以及非平凡耗時長的觀察者實現。本文內容雖然並不全面，很多這種模式所涉及的複雜問題，遠不是一篇文章就能說清的。但是讀完本文，讀者能 瞭解什麼是觀察者模式，它在Java中的通用性以及如何處理在 Java 中實現觀察者模式時的一些常見問題。
觀察者模式
根據 GoF 提出的經典定義，觀察者模式的主旨是：
定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並被自動更新。
什 麼意思呢？很多軟件應用中，對象之間的狀態都是互相依賴的。例如，如果一個應用專注於數值數據加工，這個數據也許會通過圖形用戶界面（GUI）的表格或圖 表來展現或者兩者同時使用，也就是說，當底層數據更新時，相應的 GUI 組件也要更新。問題的關鍵在於如何做到底層數據更新時 GUI 組件也隨之更新，同時儘量減小 GUI 組件和底層數據的耦合度。
一種簡單且不可擴展的解決方案是給管理這些底層數據的對象該表格和圖像 GUI 組件的引用，使得對象可以在底層數據變化時能夠通知 GUI 組件。顯然，對於處理有更多 GUI 組件的複雜應用，這個簡單的解決方案很快顯示出其不足。例如，有20個 GUI 組件都依賴於底層數據，那麼管理底層數據的對象就需要維護指向這20個組件的引用。隨着依賴於相關數據的對象數量的增加，數據管理和對象之間的耦合度也變 得難以控制。
另一個更好的解決方案是允許對象註冊獲取感興趣數據更新的權限，當數據變化時，數據管理器就會通知這些對象。通俗地說就是，讓 感興趣的數據對象告訴管理器：“當數據變化時請通知我”。此外，這些對象不僅可以註冊獲取更新通知，也可以取消註冊，保證數據管理器在數據變化時不再通知 該對象。在 GoF 的原始定義中，註冊獲取更新的對象叫作“觀察者”（observer），對應的數據管理器叫作“目標”(Subject)，觀察者感興趣的數據叫作“目標 狀態”，註冊過程叫“添加”（attach），撤銷觀察的過程叫“移除”（detach）。前文已經提到觀察者模式又叫發佈－訂閱模式，可以理解爲客戶訂 閱關於目標的觀察者，當目標狀態更新時，目標把這些更新發布給訂閱者（這種設計模式擴展爲通用架構，稱爲發佈——訂閱架構）。這些概念可以用下面的類圖表 示：
具 體觀察者（ConcereteObserver）用來接收更新的狀態變化，同時將指向具體主題（ConcereteSubject）的引用傳遞給它的構造 函數。這爲具體觀察者提供了指向具體主題的引用，在狀態變化時可由此獲得更新。簡單來說，具體觀察者會被告知主題更新，同時用其構造函數中的引用來獲取具 體主題的狀態，最後將這些檢索狀態對象存儲在具體觀察者的觀察狀態（observerState）屬性下。這一過程如下面的序列圖所示：
經典模式的專業化
儘管觀察者模式是通用的，但也有很多專業化的模式，最常見是以下兩種：
爲State對象提供一個參數，傳給觀察者調用的Update方法。在經典模式下，當觀察者被通知Subject狀態發生變化後，會直接從 Subject獲得其更新後狀態。這要求觀察者保存指向獲取狀態的對象引用。這樣就形成了一個循環引用，ConcreteSubject的引用指向其觀察 者列表，ConcreteObserver的引用指向能獲得主題狀態的ConcreteSubject。除了獲得更新的狀態，觀察者和其註冊監聽的 Subject間並沒有聯繫，觀察者關心的是State對象，而非Subject本身。也就是說，很多情況下都將ConcreteObserver和 ConcreteSubject強行聯繫一起，相反，當ConcreteSubject調用Update函數時，將State對象傳遞給 ConcreteObserver，二者就無需關聯。ConcreteObserver和State對象之間關聯減小了觀察者和State之間的依賴程度 （關聯和依賴的更多區別請參見Martin Fowler’s的文章）。
將Subject抽象類和ConcreteSubject合併到一個 singleSubject類中。多數情況下，Subject使用抽象類並不會提升程序的靈活性和可擴展性，因此，將這一抽象類和具體類合併簡化了設計。
這兩個專業化的模式組合後，其簡化類圖如下：
在這些專業化的模式中，靜態類結構大大簡化，類之間的相互作用也得以簡化。此時的序列圖如下：
專 業化模式另一特點是刪除了 ConcreteObserver 的成員變量 observerState。有時候具體觀察者並不需要保存Subject的最新狀態，而只需要監測狀態更新時 Subject 的狀態。例如，如果觀察者將成員變量的值更新到標準輸出上，就可以刪除 observerState，這樣一來就刪除了ConcreteObserver和State類之間的關聯。
更常見的命名規則
經 典模式甚至是前文提到的專業化模式都用的是attach，detach和observer等術語，而Java實現中很多都是用的不同的詞典，包括 register，unregister，listener等。值得一提的是State是listener需要監測變化的所有對象的統稱，狀態對象的具體 名稱需要看觀察者模式用到的場景。例如，在listener監聽事件發生場景下的觀察者模式，已註冊的listener將會在事件發生時收到通知，此時的 狀態對象就是event，也就是事件是否發生。
平時實際應用中目標的命名很少包含Subject。例如，創建一個關於動物園的應用，註冊多 個監聽器用於觀察Zoo類，並在新動物進入動物園時收到通知。該案例中的目標是Zoo類，爲了和所給問題域保持術語一致，將不會用到Subject這樣的 詞彙，也就是說Zoo類不會命名爲ZooSubject。
監聽器的命名一般都會跟着Listener後綴，例如前文提到的監測新動物加入的 監聽器會命名爲AnimalAddedListener。類似的，register,、unregister和notify等函數命名常會以其對應的監聽 器名作後綴，例如AnimalAddedListener的register、unregister、notify函數會被命名爲 registerAnimalAddedListener、 unregisterAnimalAddedListener和notifyAnimalAddedListeners，需要注意的是notify函數名 的s，因爲notify函數處理的是多個而非單一監聽器。
這種命名方式會顯得冗長，而且通常一個subject會註冊多個類型的監聽器，如 前面提到的動物園的例子，Zoo內除了註冊監聽動物新增的監聽器，還需註冊監聽動物減少監聽器，此時就會有兩種register函數： （registerAnimalAddedListener和 registerAnimalRemovedListener，這種方式處理，監聽器的類型作爲一個限定符，表示其應觀察者的類型。另一解決方案是創建一 個registerListener函數然後重載，但是方案一能更方便的知道哪個監聽器正在監聽，重載是比較小衆的做法。
另一慣用語法是用on前綴而不是update，例如update函數命名爲onAnimalAdded而不是updateAnimalAdded。這種情況在監聽器獲得一個序列的通知時更常見，如向list中新增一個動物，但很少用於更新一個單獨的數據，比如動物的名字。
接下來本文將使用Java的符號規則，雖然符號規則不會改變系統的真實設計和實現，但是使用其他開發者都熟悉的術語是很重要的開發準則，因此要熟悉上文描述的Java中的觀察者模式符號規則。下文將在Java8環境下用一個簡單例子來闡述上述概念。
一個簡單的實例
還是前面提到的動物園的例子，使用Java8的API接口實現一個簡單的系統，說明觀察者模式的基本原理。問題描述爲：
創建一個系統zoo，允許用戶監聽和撤銷監聽添加新對象animal的狀態，另外再創建一個具體監聽器，負責輸出新增動物的name。
根據前面對觀察者模式的學習知道實現這樣的應用需要創建4個類，具體是：
Zoo類：即模式中的主題，負責存儲動物園中的所有動物，並在新動物加入時通知所有已註冊的監聽器。
Animal類：代表動物對象。
AnimalAddedListener類：即觀察者接口。
PrintNameAnimalAddedListener：具體的觀察者類，負責輸出新增動物的name。
首先我們創建一個Animal類，它是一個包含name成員變量、構造函數、getter和setter方法的簡單Java對象，代碼如下：
public class Animal {
private String name; public Animal (String name) { this.name = name;
} public String getName () { return this.name;
} public void setName (String name) { this.name = name;
}
}用這個類代表動物對象，接下來就可以創建AnimalAddedListener接口了：
public interface AnimalAddedListener {
public void onAnimalAdded (Animal animal);
}前面兩個類很簡單，就不再詳細介紹，接下來創建Zoo類：
public class Zoo {
private List<animal> animals = new ArrayList<>(); private List<animaladdedlistener> listeners = new ArrayList<>(); public void addAnimal (Animal animal) { // Add the animal to the list of animals
this.animals.add(animal); // Notify the list of registered listeners
this.notifyAnimalAddedListeners(animal);
} public void registerAnimalAddedListener (AnimalAddedListener listener) { // Add the listener to the list of registered listeners
this.listeners.add(listener);
} public void unregisterAnimalAddedListener (AnimalAddedListener listener) { // Remove the listener from the list of the registered listeners
this.listeners.remove(listener);
} protected void notifyAnimalAddedListeners (Animal animal) { // Notify each of the listeners in the list of registered listeners
this.listeners.forEach(listener -> listener.updateAnimalAdded(animal));
}
}這個類比前面兩個都複雜，其包含兩個list，一個用來存儲動物園中所有動物，另一個用來存儲所有的監聽器，鑑於 animals和listener集合存儲的對象都很簡單，本文選擇了ArrayList來存儲。存儲監聽器的具體數據結構要視問題而定，比如對於這裏的 動物園問題，如果監聽器有優先級，那就應該選擇其他的數據結構，或者重寫監聽器的register算法。
註冊和移除的實現都是簡單的委託方 式：各個監聽器作爲參數從監聽者的監聽列表增加或者移除。notify函數的實現與觀察者模式的標準格式稍微偏離，它包括輸入參數：新增加的 animal，這樣一來notify函數就可以把新增加的animal引用傳遞給監聽器了。用streams API的forEach函數遍歷監聽器，對每個監聽器執行theonAnimalAdded函數。
在addAnimal函數中，新增的 animal對象和監聽器各自添加到對應list。如果不考慮通知過程的複雜性，這一邏輯應包含在方便調用的方法中，只需要傳入指向新增animal對象 的引用即可，這就是通知監聽器的邏輯實現封裝在notifyAnimalAddedListeners函數中的原因，這一點在addAnimal的實現中 也提到過。
除了notify函數的邏輯問題，需要強調一下對notify函數可見性的爭議問題。在經典的觀察者模型中，如GoF在設計模式 一書中第301頁所說，notify函數是public型的，然而儘管在經典模式中用到，這並不意味着必須是public的。選擇可見性應該基於應用，例 如本文的動物園的例子，notify函數是protected類型，並不要求每個對象都可以發起一個註冊觀察者的通知，只需保證對象能從父類繼承該功能即 可。當然，也並非完全如此，需要弄清楚哪些類可以激活notify函數，然後再由此確定函數的可見性。
接下來需要實現PrintNameAnimalAddedListener類，這個類用System.out.println方法將新增動物的name輸出，具體代碼如下：
public class PrintNameAnimalAddedListener implements AnimalAddedListener {
@Override
public void updateAnimalAdded (Animal animal) { // Print the name of the newly added animal
System.out.println("Added a new animal with name '" + animal.getName() + "'");
}
}最後要實現驅動應用的主函數：
public class Main {
public static void main (String[] args) { // Create the zoo to store animals
Zoo zoo = new Zoo(); // Register a listener to be notified when an animal is added
zoo.registerAnimalAddedListener(new PrintNameAnimalAddedListener()); // Add an animal notify the registered listeners
zoo.addAnimal(new Animal("Tiger"));
}
}主函數只是簡單的創建了一個zoo對象，註冊了一個輸出動物name的監聽器，並新建了一個animal對象以觸發已註冊的監聽器，最後的輸出爲：
Added a new animal with name 'Tiger'
新增監聽器
當 監聽器重新建立並將其添加到Subject時，觀察者模式的優勢就充分顯示出來。例如，想添加一個計算動物園中動物總數的監聽器，只需要新建一個具體的監 聽器類並註冊到Zoo類即可，而無需對zoo類做任何修改。添加計數監聽器CountingAnimalAddedListener代碼如下：
public class CountingAnimalAddedListener implements AnimalAddedListener {
private static int animalsAddedCount = 0; @Override
public void updateAnimalAdded (Animal animal) { // Increment the number of animals
animalsAddedCount++; // Print the number of animals
System.out.println("Total animals added: " + animalsAddedCount);
}
}修改後的main函數如下：
public class Main {
public static void main (String[] args) { // Create the zoo to store animals
Zoo zoo = new Zoo(); // Register listeners to be notified when an animal is added
zoo.registerAnimalAddedListener(new PrintNameAnimalAddedListener());
zoo.registerAnimalAddedListener(new CountingAnimalAddedListener()); // Add an animal notify the registered listeners
zoo.addAnimal(new Animal("Tiger"));
zoo.addAnimal(new Animal("Lion"));
zoo.addAnimal(new Animal("Bear"));
}
}輸出結果爲：
Added a new animal with name 'Tiger'Total animals added: 1Added a new animal with name 'Lion'Total animals added: 2Added a new animal with name 'Bear'Total animals added: 3
使用者可在僅修改監聽器註冊代碼的情況下，創建任意監聽器。具有此可擴展性主要是因爲Subject和觀察者接口關聯，而不是直接和ConcreteObserver關聯。只要接口不被修改，調用接口的Subject就無需修改。
匿名內部類，Lambda函數和監聽器註冊
Java8 的一大改進是增加了功能特性，如增加了lambda函數。在引進lambda函數之前，Java通過匿名內部類提供了類似的功能，這些類在很多已有的應用 中仍在使用。在觀察者模式下，隨時可以創建新的監聽器而無需創建具體觀察者類，例如，PrintNameAnimalAddedListener類可以在 main函數中用匿名內部類實現，具體實現代碼如下：
public class Main {
public static void main (String[] args) { // Create the zoo to store animals
Zoo zoo = new Zoo(); // Register listeners to be notified when an animal is added
zoo.registerAnimalAddedListener(new AnimalAddedListener() { @Override
public void updateAnimalAdded (Animal animal) { // Print the name of the newly added animal
System.out.println("Added a new animal with name '" + animal.getName() + "'");
}
}); // Add an animal notify the registered listeners
zoo.addAnimal(new Animal("Tiger"));
}
}類似的，lambda函數也可以用以完成此類任務：
public class Main {
public static void main (String[] args) { // Create the zoo to store animals
Zoo zoo = new Zoo(); // Register listeners to be notified when an animal is added
zoo.registerAnimalAddedListener(
(animal) -> System.out.println("Added a new animal with name '" + animal.getName() + "'")
); // Add an animal notify the registered listeners
zoo.addAnimal(new Animal("Tiger"));
}
}需要注意的是lambda函數僅適用於監聽器接口只有一個函數的情況，這個要求雖然看起來嚴格，但實際上很多監聽器都是單一函數的，如示例中的AnimalAddedListener。如果接口有多個函數，可以選擇使用匿名內部類。
隱 式註冊創建的監聽器存在此類問題：由於對象是在註冊調用的範圍內創建的，所以不可能將引用存儲一個到具體監聽器。這意味着，通過lambda函數或者匿名 內部類註冊的監聽器不可以撤銷註冊，因爲撤銷函數需要傳入已經註冊監聽器的引用。解決這個問題的一個簡單方法是在 registerAnimalAddedListener函數中返回註冊監聽器的引用。如此一來，就可以撤銷註冊用lambda函數或匿名內部類創建的監 聽器，改進後的方法代碼如下：
public AnimalAddedListener registerAnimalAddedListener (AnimalAddedListener listener) { // Add the listener to the list of registered listeners
this.listeners.add(listener);
return listener;
}重新設計的函數交互的客戶端代碼如下：
public class Main {
public static void main (String[] args) { // Create the zoo to store animals
Zoo zoo = new Zoo(); // Register listeners to be notified when an animal is added
AnimalAddedListener listener = zoo.registerAnimalAddedListener(
(animal) -> System.out.println("Added a new animal with name '" + animal.getName() + "'")
); // Add an animal notify the registered listeners
zoo.addAnimal(new Animal("Tiger")); // Unregister the listener
zoo.unregisterAnimalAddedListener(listener); // Add another animal, which will not print the name, since the listener
// has been previously unregistered
zoo.addAnimal(new Animal("Lion"));
}
}此時的結果輸出只有Added a new animal with name ‘Tiger’，因爲在第二個animal加入之前監聽器已經撤銷了：
Added a new animal with name 'Tiger'
如果採用更復雜的解決方案，register函數也可以返回receipt類，以便unregister監聽器調用，例如:
public class AnimalAddedListenerReceipt {
private final AnimalAddedListener listener; public AnimalAddedListenerReceipt (AnimalAddedListener listener) { this.listener = listener;
} public final AnimalAddedListener getListener () { return this.listener;
}
}receipt會作爲註冊函數的返回值，以及撤銷註冊函數輸入參數，此時的zoo實現如下所示：
public class ZooUsingReceipt {
// ...Existing attributes and constructor...
public AnimalAddedListenerReceipt registerAnimalAddedListener (AnimalAddedListener listener) { // Add the listener to the list of registered listeners
this.listeners.add(listener); return new AnimalAddedListenerReceipt(listener);
} public void unregisterAnimalAddedListener (AnimalAddedListenerReceipt receipt) { // Remove the listener from the list of the registered listeners
this.listeners.remove(receipt.getListener());
} // ...Existing notification method...}上面描述的接收實現機制允許保存信息供監聽器撤銷時調用的，也就是說如果撤銷註冊算法依賴於Subject註冊監聽器時的狀態，則此狀態將被保存，如果撤銷註冊只需要指向之前註冊監聽器的引用，這樣的話接收技術則顯得麻煩，不推薦使用。
除了特別複雜的具體監聽器，最常見的註冊監聽器的方法是通過lambda函數或通過匿名內部類註冊。當然，也有例外，那就是包含subject實現觀察者接口的類和註冊一個包含調用該引用目標的監聽器。如下面代碼所示的案例：
public class ZooContainer implements AnimalAddedListener {
private Zoo zoo = new Zoo(); public ZooContainer () { // Register this object as a listener
this.zoo.registerAnimalAddedListener(this);
} public Zoo getZoo () { return this.zoo;
} @Override
public void updateAnimalAdded (Animal animal) {
System.out.println("Added animal with name '" + animal.getName() + "'");
} public static void main (String[] args) { // Create the zoo container
ZooContainer zooContainer = new ZooContainer(); // Add an animal notify the innerally notified listener
zooContainer.getZoo().addAnimal(new Animal("Tiger"));
}
}這種方法只適用於簡單情況而且代碼看起來不夠專業，儘管如此，它還是深受現代Java開發人員的喜愛，因此瞭解這個例 子的工作原理很有必要。因爲ZooContainer實現了AnimalAddedListener接口，那麼ZooContainer的實例(或者說對 象)就可以註冊爲AnimalAddedListener。ZooContainer類中，該引用代表當前對象即ZooContainer的一個實例，所 以可以被用作AnimalAddedListener。
通常，不是要求所有的container類都實現此類功能，而且實現監聽器接口的container類只能調用Subject的註冊函數，只是簡單把該引用作爲監聽器的對象傳給register函數。在接下來的章節中，將介紹多線程環境的常見問題和解決方案。
線程安全的實現
前 面章節介紹了在現代Java環境下的實現觀察者模式，雖然簡單但很完整，但這一實現忽略了一個關鍵性問題：線程安全。大多數開放的Java應用都是多線程 的，而且觀察者模式也多用於多線程或異步系統。例如，如果外部服務更新其數據庫，那麼應用也會異步地收到消息，然後用觀察者模式通知內部組件更新，而不是 內部組件直接註冊監聽外部服務。
觀察者模式的線程安全主要集中在模式的主體上，因爲修改註冊監聽器集合時很可能發生線程衝突，比如，一個線 程試圖添加一個新的監聽器，而另一線程又試圖添加一個新的animal對象，這將觸發對所有註冊監聽器的通知。鑑於先後順序，在已註冊的監聽器收到新增動 物的通知前，第一個線程可能已經完成也可能尚未完成新監聽器的註冊。這是一個經典的線程資源競爭案例，正是這一現象告訴開發者們需要一個機制來保證線程安 全。
這一問題的最簡單的解決方案是：所有訪問或修改註冊監聽器list的操作都須遵循Java的同步機制，比如：
public synchronized AnimalAddedListener registerAnimalAddedListener (AnimalAddedListener listener) { /*...*/ }public synchronized void unregisterAnimalAddedListener (AnimalAddedListener listener) { /*...*/ }public synchronized void notifyAnimalAddedListeners (Animal animal) { /*...*/ }這 樣一來，同一時刻只有一個線程可以修改或訪問已註冊的監聽器列表，可以成功地避免資源競爭問題，但是新問題又出現了，這樣的約束太過嚴格 (synchronized關鍵字和Java併發模型的更多信息，請參閱官方網頁)。通過方法同步，可以時刻觀測對監聽器list的併發訪問，註冊和撤銷 監聽器對監聽器list而言是寫操作，而通知監聽器訪問監聽器list是隻讀操作。由於通過通知訪問是讀操作，因此是可以多個通知操作同時進行的。
因 此，只要沒有監聽器註冊或撤銷註冊，任意多的併發通知都可以同時執行，而不會引發對註冊的監聽器列表的資源爭奪。當然，其他情況下的資源爭奪現象存在已 久，爲了解決這一問題，設計了ReadWriteLock用以分開管理讀寫操作的資源鎖定。Zoo類的線程安全ThreadSafeZoo實現代碼如下：
public class ThreadSafeZoo {
private final ReadWriteLock readWriteLock = new ReentrantReadWriteLock(); protected final Lock readLock = readWriteLock.readLock(); protected final Lock writeLock = readWriteLock.writeLock(); private List<animal> animals = new ArrayList<>(); private List<animaladdedlistener> listeners = new ArrayList<>(); public void addAnimal (Animal animal) { // Add the animal to the list of animals
this.animals.add(animal); // Notify the list of registered listeners
this.notifyAnimalAddedListeners(animal);
} public AnimalAddedListener registerAnimalAddedListener (AnimalAddedListener listener) { // Lock the list of listeners for writing
this.writeLock.lock(); try { // Add the listener to the list of registered listeners
this.listeners.add(listener);
} finally { // Unlock the writer lock
this.writeLock.unlock();
} return listener;
} public void unregisterAnimalAddedListener (AnimalAddedListener listener) { // Lock the list of listeners for writing
this.writeLock.lock(); try { // Remove the listener from the list of the registered listeners
this.listeners.remove(listener);
} finally { // Unlock the writer lock
this.writeLock.unlock();
}
} public void notifyAnimalAddedListeners (Animal animal) { // Lock the list of listeners for reading
this.readLock.lock(); try { // Notify each of the listeners in the list of registered listeners
this.listeners.forEach(listener -> listener.updateAnimalAdded(animal));
} finally { // Unlock the reader lock
this.readLock.unlock();
}
}
}通過這樣部署，Subject的實現能確保線程安全並且多個線程可以同時發佈通知。但儘管如此，依舊存在兩個不容忽略的資源競爭問題：
對每個監聽器的併發訪問。多個線程可以同時通知監聽器要新增動物了，這意味着一個監聽器可能會同時被多個線程同時調用。
對animal list的併發訪問。多個線程可能會同時向animal list添加對象，如果通知的先後順序存在影響，那就可能導致資源競爭，這就需要一個併發操作處理機制來避免這一問題。如果註冊的監聽器列表在收到通知添 加animal2後，又收到通知添加animal1，此時就會產生資源競爭。但是如果animal1和animal2的添加由不同的線程執行，也是有可能 在animal2前完成對animal1添加操作，具體來說就是線程1在通知監聽器前添加animal1並鎖定模塊，線程2添加animal2並通知監聽 器，然後線程1通知監聽器animal1已經添加。雖然在不考慮先後順序時，可以忽略資源競爭，但問題是真實存在的。
對監聽器的併發訪問
併發訪問監聽器可以通過保證監聽器的線程安全來實現。秉承着類的“責任自負”精神，監聽器有“義 務”確保自身的線程安全。例如，對於前面計數的監聽器，多線程的遞增或遞減動物數量可能導致線程安全問題，要避免這一問題，動物數的計算必須是原子操作 （原子變量或方法同步），具體解決代碼如下：
public class ThreadSafeCountingAnimalAddedListener implements AnimalAddedListener {
private static AtomicLong animalsAddedCount = new AtomicLong(0); @Override
public void updateAnimalAdded (Animal animal) { // Increment the number of animals
animalsAddedCount.incrementAndGet(); // Print the number of animals
System.out.println("Total animals added: " + animalsAddedCount);
}
}方法同步解決方案代碼如下：
public class CountingAnimalAddedListener implements AnimalAddedListener {
private static int animalsAddedCount = 0; @Override
public synchronized void updateAnimalAdded (Animal animal) { // Increment the number of animals
animalsAddedCount++; // Print the number of animals
System.out.println("Total animals added: " + animalsAddedCount);
}
}要強調的是監聽器應該保證自身的線程安全，subject需要理解監聽器的內部邏輯，而不是簡單確保對監聽器的訪問和 修改的線程安全。否則，如果多個subject共用同一個監聽器，那每個subject類都要重寫一遍線程安全的代碼，顯然這樣的代碼不夠簡潔，因此需要 在監聽器類內實現線程安全。
監聽器的有序通知
當要求監聽器有序執行時，讀寫鎖就不能滿足需求了，而需要引入一個新的機 制，可以保證notify函數的調用順序和animal添加到zoo的順序一致。有人嘗試過用方法同步來實現，然而根據Oracle文檔中的方法同步介 紹，可知方法同步並不提供操作執行的順序管理。它只是保證原子操作，也就是說操作不會被打斷，並不能保證先來先執行(FIFO)的線程順序。 ReentrantReadWriteLock可以實現這樣的執行順序，代碼如下：
public class OrderedThreadSafeZoo {
private final ReadWriteLock readWriteLock = new ReentrantReadWriteLock(true); protected final Lock readLock = readWriteLock.readLock(); protected final Lock writeLock = readWriteLock.writeLock(); private List<animal> animals = new ArrayList<>(); private List<animaladdedlistener> listeners = new ArrayList<>(); public void addAnimal (Animal animal) { // Add the animal to the list of animals
this.animals.add(animal); // Notify the list of registered listeners
this.notifyAnimalAddedListeners(animal);
} public AnimalAddedListener registerAnimalAddedListener (AnimalAddedListener listener) { // Lock the list of listeners for writing
this.writeLock.lock(); try { // Add the listener to the list of registered listeners
this.listeners.add(listener);
} finally { // Unlock the writer lock
this.writeLock.unlock();
} return listener;
} public void unregisterAnimalAddedListener (AnimalAddedListener listener) { // Lock the list of listeners for writing
this.writeLock.lock(); try { // Remove the listener from the list of the registered listeners
this.listeners.remove(listener);
} finally { // Unlock the writer lock
this.writeLock.unlock();
}
} public void notifyAnimalAddedListeners (Animal animal) { // Lock the list of listeners for reading
this.readLock.lock(); try { // Notify each of the listeners in the list of registered listeners
this.listeners.forEach(listener -> listener.updateAnimalAdded(animal));
} finally { // Unlock the reader lock
this.readLock.unlock();
}
}
}這樣的實現方式，register, unregister和notify函數將按照先進先出(FIFO)的順序獲得讀寫鎖權限。例如，線程1註冊一個監聽器，線程2在開始執行註冊操作後試圖 通知已註冊的監聽器，線程3在線程2等待只讀鎖的時候也試圖通知已註冊的監聽器，採用fair-ordering方式，線程1先完成註冊操作，然後線程2 可以通知監聽器，最後線程3通知監聽器。這樣保證了action的執行順序和開始順序一致。
如果採用方法同步，雖然線程2先排隊等待佔用資 源，線程3仍可能比線程2先獲得資源鎖，而且不能保證線程2比線程3先通知監聽器。問題的關鍵所在：fair-ordering方式可以保證線程按照申請 資源的順序執行。讀寫鎖的順序機制很複雜，應參照ReentrantReadWriteLock的官方文檔以確保鎖的邏輯足夠解決問題。
截止目前實現了線程安全，在接下來的章節中將介紹提取主題的邏輯並將其mixin類封裝爲可重複代碼單元的方式優缺點。
主題邏輯封裝到Mixin類
把 上述的觀察者模式設計實現封裝到目標的mixin類中很具吸引力。通常來說，觀察者模式中的觀察者包含已註冊的監聽器的集合；負責註冊新的監聽器的 register函數；負責撤銷註冊的unregister函數和負責通知監聽器的notify函數。對於上述的動物園的例子，zoo類除動物列表是問題 所需外，其他所有操作都是爲了實現主題的邏輯。
Mixin類的案例如下所示，需要說明的是爲使代碼更爲簡潔，此處去掉關於線程安全的代碼：
public abstract class ObservableSubjectMixin<listenertype> {
private List<listenertype> listeners = new ArrayList<>(); public ListenerType registerListener (ListenerType listener) { // Add the listener to the list of registered listeners
this.listeners.add(listener); return listener;
} public void unregisterAnimalAddedListener (ListenerType listener) { // Remove the listener from the list of the registered listeners
this.listeners.remove(listener);
} public void notifyListeners (Consumer<!--? super ListenerType--> algorithm) { // Execute some function on each of the listeners
this.listeners.forEach(algorithm);
}
}正因爲沒有提供正在註冊的監聽器類型的接口信息，不能直接通知某個特定的監聽器，所以正需要保證通知功能的通用性，允許客戶端添加一些功能，如接受泛型參數類型的參數匹配，以適用於每個監聽器，具體實現代碼如下：
public class ZooUsingMixin extends ObservableSubjectMixin<animaladdedlistener> {
private List<animal> animals = new ArrayList<>(); public void addAnimal (Animal animal) { // Add the animal to the list of animals
this.animals.add(animal); // Notify the list of registered listeners
this.notifyListeners((listener) -> listener.updateAnimalAdded(animal));
}
}Mixin類技術的最大優勢是把觀察者模式的Subject封裝到一個可重複調用的類中，而不是在每個subject類中都重複寫這些邏輯。此外，這一方法使得zoo類的實現更爲簡潔，只需要存儲動物信息，而不用再考慮如何存儲和通知監聽器。
然 而，使用mixin類並非只有優點。比如，如果要存儲多個類型的監聽器怎麼辦？例如，還需要存儲監聽器類型AnimalRemovedListener。 mixin類是抽象類，Java中不能同時繼承多個抽象類，而且mixin類不能改用接口實現，這是因爲接口不包含state，而觀察者模式中state 需要用來保存已經註冊的監聽器列表。
其中的一個解決方案是創建一個動物增加和減少時都會通知的監聽器類型ZooListener，代碼如下所示:
public interface ZooListener {
public void onAnimalAdded (Animal animal); public void onAnimalRemoved (Animal animal);
}這樣就可以使用該接口實現利用一個監聽器類型對zoo狀態各種變化的監聽了：
public class ZooUsingMixin extends ObservableSubjectMixin<zoolistener> {
private List<animal> animals = new ArrayList<>(); public void addAnimal (Animal animal) { // Add the animal to the list of animals
this.animals.add(animal); // Notify the list of registered listeners
this.notifyListeners((listener) -> listener.onAnimalAdded(animal));
} public void removeAnimal (Animal animal) { // Remove the animal from the list of animals
this.animals.remove(animal); // Notify the list of registered listeners
this.notifyListeners((listener) -> listener.onAnimalRemoved(animal));
}
}將多個監聽器類型合併到一個監聽器接口中確實解決了上面提到的問題，但仍舊存在不足之處，接下來的章節會詳細討論。
Multi-Method監聽器和適配器
在 上述方法，監聽器的接口中實現的包含太多函數，接口就過於冗長，例如，Swing MouseListener就包含5個必要的函數。儘管可能只會用到其中一個，但是隻要用到鼠標點擊事件就必須要添加這5個函數，更多可能是用空函數體來 實現剩下的函數，這無疑會給代碼帶來不必要的混亂。
其中一種解決方案是創建適配器(概念來自GoF提出的適配器模式)，適配器中以抽象函數 的形式實現監聽器接口的操作，供具體監聽器類繼承。這樣一來，具體監聽器類就可以選擇其需要的函數，對adapter不需要的函數採用默認操作即可。例如 上面例子中的ZooListener類，創建ZooAdapter(Adapter的命名規則與監聽器一致，只需要把類名中的Listener改爲 Adapter即可)，代碼如下：
public class ZooAdapter implements ZooListener {
@Override
public void onAnimalAdded (Animal animal) {} @Override
public void onAnimalRemoved (Animal animal) {}
}乍一看，這個適配器類微不足道，然而它所帶來的便利卻是不可小覷的。比如對於下面的具體類，只需選擇對其實現有用的函數即可：
public class NamePrinterZooAdapter extends ZooAdapter {
@Override
public void onAnimalAdded (Animal animal) { // Print the name of the animal that was added
System.out.println("Added animal named " + animal.getName());
}
}有兩種替代方案同樣可以實現適配器類的功能：一是使用默認函數；二是把監聽器接口和適配器類合併到一個具體類中。默認函數是Java8新提出的，在接口中允許開發者提供默認（防禦）的實現方法。
Java 庫的這一更新主要是方便開發者在不改變老版本代碼的情況下，實現程序擴展，因此應該慎用這個方法。部分開發者多次使用後，會感覺這樣寫的代碼不夠專業，而 又有開發者認爲這是Java8的特色，不管怎樣，需要明白這個技術提出的初衷是什麼，再結合具體問題決定是否要用。使用默認函數實現的 ZooListener接口代碼如下示：
public interface ZooListener {
default public void onAnimalAdded (Animal animal) {} default public void onAnimalRemoved (Animal animal) {}
}通過使用默認函數，實現該接口的具體類，無需在接口中實現全部函數，而是選擇性實現所需函數。雖然這是接口膨脹問題一個較爲簡潔的解決方案，開發者在使用時還應多加註意。
第二種方案是簡化觀察者模式，省略了監聽器接口，而是用具體類實現監聽器的功能。比如ZooListener接口就變成了下面這樣：
public class ZooListener {
public void onAnimalAdded (Animal animal) {} public void onAnimalRemoved (Animal animal) {}
}這一方案簡化了觀察者模式的層次結構，但它並非適用於所有情況，因爲如果把監聽器接口合併到具體類中，具體監聽器就不 可以實現多個監聽接口了。例如，如果AnimalAddedListener和AnimalRemovedListener接口寫在同一個具體類中，那麼 單獨一個具體監聽器就不可以同時實現這兩個接口了。此外，監聽器接口的意圖比具體類更顯而易見，很顯然前者就是爲其他類提供接口，但後者就並非那麼明顯 了。
如果沒有合適的文檔說明，開發者並不會知道已經有一個類扮演着接口的角色，實現了其對應的所有函數。此外，類名不包含adapter，因爲類並不適配於某一個接口，因此類名並沒有特別暗示此意圖。綜上所述，特定問題需要選擇特定的方法，並沒有哪個方法是萬能的。
在 開始下一章前，需要特別提一下，適配器在觀察模式中很常見，尤其是在老版本的Java代碼中。Swing API正是以適配器爲基礎實現的，正如很多老應用在Java5和Java6中的觀察者模式中所使用的那樣。zoo案例中的監聽器或許並不需要適配器，但需 要了解適配器提出的目的以及其應用，因爲我們可以在現有的代碼中對其進行使用。下面的章節，將會介紹時間複雜的監聽器，該類監聽器可能會執行耗時的運算或 進行異步調用，不能立即給出返回值。
Complex & Blocking監聽器
關於觀察者模式的一個假設是： 執行一個函數時，一系列監聽器會被調用，但假定這一過程對調用者而言是完全透明的。例如，客戶端代碼在Zoo中添加animal時，在返回添加成功之前， 並不知道會調用一系列監聽器。如果監聽器的執行需要時間較長（其時間受監聽器的數量、每個監聽器執行時間影響），那麼客戶端代碼將會感知這一簡單增加動物 操作的時間副作用。
本文不能面面俱到的討論這個話題，下面幾條是開發者調用複雜的監聽器時應該注意的事項：
監聽器啓動新線程。新線程啓動後，在新線程中執行監聽器邏輯的同時，返回監聽器函數的處理結果，並運行其他監聽器執行。
2. Subject啓動新線程。與傳統的線性迭代已註冊的監聽器列表不同，Subject的notify函數重啓一個新的線程，然後在新線程中迭代監聽器列 表。這樣使得notify函數在執行其他監聽器操作的同時可以輸出其返回值。需要注意的是需要一個線程安全機制來確保監聽器列表不會進行併發修改。
3. 隊列化監聽器調用並採用一組線程執行監聽功能。將監聽器操作封裝在一些函數中並隊列化這些函數，而非簡單的迭代調用監聽器列表。這些監聽器存儲到隊列中 後，線程就可以從隊列中彈出單個元素並執行其監聽邏輯。這類似於生產者-消費者問題，notify過程產生可執行函數隊列，然後線程依次從隊列中取出並執 行這些函數，函數需要存儲被創建的時間而非執行的時間供監聽器函數調用。例如，監聽器被調用時創建的函數，那麼該函數就需要存儲該時間點，這一功能類似於 Java中的如下操作：
public class AnimalAddedFunctor {
private final AnimalAddedListener listener; private final Animal parameter; public AnimalAddedFunctor (AnimalAddedListener listener, Animal parameter) { this.listener = listener; this.parameter = parameter;
} public void execute () { // Execute the listener with the parameter provided during creation
this.listener.updateAnimalAdded(this.parameter);
}
}函數創建並保存在隊列中，可以隨時調用，這樣一來就無需在遍歷監聽器列表時立即執行其對應操作了。一旦每個激活監聽器 的函數都壓入隊列中，“消費者線程”就會給客戶端代碼返回操作權。之後某個時間點“消費者線程”將會執行這些函數，就像在監聽器被notify函數激活時 執行一樣。這項技術在其他語言中被叫作參數綁定，剛好適合上面的例子，技術的實質是保存監聽器的參數，execute()函數再直接調用。如果監聽器接收 多個參數，處理方法也類似。
需要注意的是如果要保存監聽器的執行順序，則需要引入綜合排序機制。方案一中，監聽器按照正常的順序激活新線 程，這樣可以確保監聽器按照註冊的順序執行。方案二中，隊列支持排序，其中的函數會按照進入隊列的順序執行。簡單來說就是，開發者需要重視監聽器多線程執 行的複雜程度，加以小心處理以確保實現所需的功能。
結束語
觀察者模式在1994年被寫進書中以前，就已經是主流的軟件設 計模式了，爲軟件設計中經常出現的問題提供了很多令人滿意的解決方案。Java一直是使用該模式的引領者，在其標準庫中封裝了這一模式，但是鑑於Java 更新到了版本8，十分有必要重新考查經典模式在其中的使用。隨着lambda表達式和其他新結構的出現，這一“古老的”模式又有了新的生機。無論是處理舊 程序還是使用這一歷史悠久的方法解決新問題，尤其對經驗豐富的Java開發者來說，觀察者模式都是開發者的主要工具。
原文：http://geek.csdn.net/news/detail/58362