周全解析Java8不雅察者形式。本站提示廣大學習愛好者：（周全解析Java8不雅察者形式）文章只能為提供參考，不一定能成為您想要的結果。以下是周全解析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）屬性下。這一進程以下面的序列圖所示：
經典形式的專業化
雖然不雅察者形式是通用的，但也有許多專業化的形式，最多見是以下兩種：
1、為State對象供給一個參數，傳給不雅察者挪用的Update辦法。在經典形式下，當不雅察者被告訴Subject狀況產生變更後，會直接從Subject取得其更新後狀況。這請求不雅察者保留指向獲得狀況的對象援用。如許就構成了一個輪回援用，ConcreteSubject的援用指向其不雅察者列表，ConcreteObserver的援用指向能取得主題狀況的ConcreteSubject。除取得更新的狀況，不雅察者和其注冊監聽的Subject間並沒有接洽，不雅察者關懷的是State對象，而非Subject自己。也就是說，許多情形下都將ConcreteObserver和ConcreteSubject強行接洽一路，相反，當ConcreteSubject挪用Update函數時，將State對象傳遞給ConcreteObserver，兩者就無需聯系關系。ConcreteObserver和State對象之間聯系關系減小了不雅察者和State之間的依附水平（聯系關系和依附的更多差別請拜見Martin Fowler's的文章）。
2、將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個類，詳細是：
起首我們創立一個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: 1 Added a new animal with name 'Lion' Total animals added: 2 Added 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時，在前往添加勝利之前，其實不曉得會挪用一系列監聽器。假如監聽器的履行須要時光較長（當時間受監聽器的數目、每一個監聽器履行時光影響），那末客戶端代碼將會感知這一簡略增長植物操作的時光反作用。
本文不克不及八面玲珑的評論辯論這個話題，上面幾條是開辟者挪用龐雜的監聽器時應當留意的事項：
監聽器啟動新線程。新線程啟動後，在新線程中履行監聽器邏輯的同時，前往監聽器函數的處置成果，並運轉其他監聽器履行。
Subject啟動新線程。與傳統的線性迭代已注冊的監聽器列表分歧，Subject的notify函數重啟一個新的線程，然後在新線程中迭代監聽器列表。如許使得notify函數在履行其他監聽器操作的同時可以輸入其前往值。須要留意的是須要一個線程平安機制來確保監聽器列表不會停止並發修正。
隊列化監聽器挪用並采取一組線程履行監聽功效。將監聽器操作封裝在一些函數中並隊列化這些函數，而非簡略的迭代挪用監聽器列表。這些監聽器存儲到隊列中後，線程便可以從隊列中彈出單個元素並履行其監聽邏輯。這相似於臨盆者-花費者成績，notify進程發生可履行函數隊列，然後線程順次從隊列中掏出並履行這些函數，函數須要存儲被創立的時光而非履行的時光供監聽器函數挪用。例如，監聽器被挪用時創立的函數，那末該函數就須要存儲該時光點，這一功效相似於Java中的以下操作：
public class
若何應用Java8 完成不雅察者形式？信任經由過程這篇文章年夜家都有了年夜概的懂得了吧！
