您好,登錄后才能下訂單哦!
如何正確的使用Java事件通知,相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策,為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法,通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。
通過(guò)實(shí)現(xiàn)觀察者模式來(lái)提供 Java 事件通知(Java event notification)似乎不是件什么難事兒,但這過(guò)程中也很容易就掉進(jìn)一些陷阱。介紹了我自己在各種情形下,不小心制造的一些常見(jiàn)錯(cuò)誤。
Java 事件通知
讓我們從一個(gè)最簡(jiǎn)單的 Java Bean 開始,它叫StateHolder,里面封裝了一個(gè)私有的 int 型屬性 state 和常見(jiàn)的訪問(wèn)方法:
public class StateHolder { private int state; public int getState() { return state; } public void setState( int state ) { this.state = state; } }
現(xiàn)在假設(shè)我們決定要 Java bean 給已注冊(cè)的觀察者廣播一條 狀態(tài)已改變 事件。小菜一碟!!!定義一個(gè)最簡(jiǎn)單的事件和監(jiān)聽器簡(jiǎn)直擼起袖子就來(lái)……
// change event to broadcast public class StateEvent { public final int oldState; public final int newState; StateEvent( int oldState, int newState ) { this.oldState = oldState; this.newState = newState; } } // observer interface public interface StateListener { void stateChanged( StateEvent event ); }
接下來(lái),我們需要在 StateHolder 的實(shí)例里注冊(cè) StatListeners。
public class StateHolder { private final Set listeners = new HashSet<>(); [...] public void addStateListener( StateListener listener ) { listeners.add( listener ); } public void removeStateListener( StateListener listener ) { listeners.remove( listener ); } }
***一個(gè)要點(diǎn),需要調(diào)整一下StateHolder#setState這個(gè)方法,來(lái)確保每次狀態(tài)有變時(shí)發(fā)出的通知,都代表這個(gè)狀態(tài)真的相對(duì)于上次產(chǎn)生變化了:
public void setState( int state ) { int oldState = this.state; this.state = state; if( oldState != state ) { broadcast( new StateEvent( oldState, state ) ); } } private void broadcast( StateEvent stateEvent ) { for( StateListener listener : listeners ) { listener.stateChanged( stateEvent ); } }
搞定了!要的就是這些。為了顯得專(zhuang)業(yè)(bi)一點(diǎn),我們可能還甚至為此實(shí)現(xiàn)了測(cè)試驅(qū)動(dòng),并為嚴(yán)密的代碼覆蓋率和那根表示測(cè)試通過(guò)的小綠條而洋洋自得。而且不管怎么樣,這不就是我從網(wǎng)上那些教程里面學(xué)來(lái)的寫法嗎?
那么問(wèn)題來(lái)了:這個(gè)解決辦法是有缺陷的……
并發(fā)修改
像上面那樣寫 StateHolder 很容易遇到并發(fā)修改異常(ConcurrentModificationException),即使僅僅限制在一個(gè)單線程里面用也不例外。但究竟是誰(shuí)導(dǎo)致了這個(gè)異常,它又為什么會(huì)發(fā)生呢?
java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429) at java.util.HashMap$KeyIterator.next(HashMap.java:1453) at com.codeaffine.events.StateProvider.broadcast(StateProvider.java:60) at com.codeaffine.events.StateProvider.setState(StateProvider.java:55) at com.codeaffine.events.StateProvider.main(StateProvider.java:122)
乍一看這個(gè)錯(cuò)誤堆棧包含的信息,異常是由我們用到的一個(gè) HashMap 的 Iterator 拋出的,可在我們的代碼里沒(méi)有用到任何的迭代器,不是嗎?好吧,其實(shí)我們用到了。要知道,寫在 broadcast 方法里的 for each 結(jié)構(gòu),實(shí)際上在編譯時(shí)是會(huì)被轉(zhuǎn)變成一個(gè)迭代循環(huán)的。
因?yàn)樵谑录V播過(guò)程中,如果一個(gè)監(jiān)聽器試圖從 StateHolder 實(shí)例里面把自己移除,就有可能導(dǎo)致 ConcurrentModificationException。所以比起在原先的數(shù)據(jù)結(jié)構(gòu)上進(jìn)行操作,有一個(gè)解決辦法就是我們可以在這組監(jiān)聽器的快照(snapshot)上進(jìn)行迭代循環(huán)。
這樣一來(lái),“移除監(jiān)聽器”這一操作就不會(huì)再干擾事件廣播機(jī)制了(但要注意的是通知還是會(huì)有輕微的語(yǔ)義變化,因?yàn)楫?dāng) broadcast 方法被執(zhí)行的時(shí)候,這樣的移除操作并不會(huì)被快照體現(xiàn)出來(lái)):
private void broadcast( StateEvent stateEvent ) { Set snapshot = new HashSet<>( listeners ); for( StateListener listener : snapshot ) { listener.stateChanged( stateEvent ); } }
但是,如果 StateHolder 被用在一個(gè)多線程的環(huán)境里呢?
同步
要再多線程的環(huán)境里使用 StateHolder ,它就必須是線程安全的。不過(guò)這也很容易實(shí)現(xiàn),給我們類里面的每個(gè)方法加上 synchronized 就搞定了,不是嗎?
public class StateHolder { public synchronized void addStateListener( StateListener listener ) { [...] public synchronized void removeStateListener( StateListener listener ) { [...] public synchronized int getState() { [...] public synchronized void setState( int state ) { [...]
現(xiàn)在我們讀寫操作 一個(gè) StateHolder 實(shí)例的時(shí)候都有了內(nèi)置鎖(Intrinsic Lock) 做保證,這使得公有方法具有了原子性,也確保了正確的狀態(tài)對(duì)不同的線程都可見(jiàn)。任務(wù)完成!
才怪……盡管這樣的實(shí)現(xiàn)是線程安全的,但一旦程序要調(diào)用它,就需要承擔(dān)死鎖的風(fēng)險(xiǎn)。
設(shè)想一下如下這種情形:線程 A 改變了 StateHolder 的狀態(tài) S,在向各個(gè)監(jiān)聽器(listener)廣播這個(gè)狀態(tài) S 的時(shí)候,線程 B 視圖訪問(wèn)狀態(tài) S ,然后被阻塞。如果 B 持有了一個(gè)對(duì)象的同步鎖,這個(gè)對(duì)象又是關(guān)于狀態(tài) S的,并且本來(lái)是要廣播給眾多監(jiān)聽器當(dāng)中的某一個(gè)的,這種情況下我們就會(huì)遇到一個(gè)死鎖。
這就是為什么我們要縮小狀態(tài)訪問(wèn)的同步性,在一個(gè)“保護(hù)通道”里面來(lái)廣播這個(gè)事件:
public class StateHolder { private final Set listeners = new HashSet<>(); private int state; public void addStateListener( StateListener listener ) { synchronized( listeners ) { listeners.add( listener ); } } public void removeStateListener( StateListener listener ) { synchronized( listeners ) { listeners.remove( listener ); } } public int getState() { synchronized( listeners ) { return state; } } public void setState( int state ) { int oldState = this.state; synchronized( listeners ) { this.state = state; } if( oldState != state ) { broadcast( new StateEvent( oldState, state ) ); } } private void broadcast( StateEvent stateEvent ) { Set snapshot; synchronized( listeners ) { snapshot = new HashSet<>( listeners ); } for( StateListener listener : snapshot ) { listener.stateChanged( stateEvent ); } } }
上面這段代碼是在之前的基礎(chǔ)上稍加改進(jìn)來(lái)實(shí)現(xiàn)的,通過(guò)使用 Set 實(shí)例作為內(nèi)部鎖來(lái)提供合適(但也有些過(guò)時(shí))的同步性,監(jiān)聽者的通知事件在保護(hù)塊之外發(fā)生,這樣就避免了一種死等的可能。
注意: 由于系統(tǒng)并發(fā)操作的天性,這個(gè)解決方案并不能保證變化通知按照他們產(chǎn)生的順序依次到達(dá)監(jiān)聽器。如果觀察者一側(cè)對(duì)實(shí)際狀態(tài)的準(zhǔn)確性有較高要求,可以考慮把 StateHolder 作為你事件對(duì)象的來(lái)源。
如果事件順序這在你的程序里顯得至關(guān)重要,有一個(gè)辦法就是可以考慮用一個(gè)線程安全的先入先出(FIFO)結(jié)構(gòu),連同監(jiān)聽器的快照一起,在 setState 方法的保護(hù)塊里緩沖你的對(duì)象。只要 FIFO 結(jié)構(gòu)不是空的,一個(gè)獨(dú)立的線程就可以從一個(gè)不受保護(hù)的區(qū)域塊里觸發(fā)實(shí)際事件(生產(chǎn)者-消費(fèi)者模式),這樣理論上就可以不必冒著死鎖的危險(xiǎn)還能確保一切按照時(shí)間順序進(jìn)行。我說(shuō)理論上,是因?yàn)榈侥壳盀橹刮乙策€沒(méi)親自這么試過(guò)。。
鑒于前面已經(jīng)實(shí)現(xiàn)的,我們可以用諸如 CopyOnWriteArraySet 和 AtomicInteger 來(lái)寫我們的這個(gè)線程安全類,從而使這個(gè)解決方案不至于那么復(fù)雜:
public class StateHolder { private final Set listeners = new CopyOnWriteArraySet<>(); private final AtomicInteger state = new AtomicInteger(); public void addStateListener( StateListener listener ) { listeners.add( listener ); } public void removeStateListener( StateListener listener ) { listeners.remove( listener ); } public int getState() { return state.get(); } public void setState( int state ) { int oldState = this.state.getAndSet( state ); if( oldState != state ) { broadcast( new StateEvent( oldState, state ) ); } } private void broadcast( StateEvent stateEvent ) { for( StateListener listener : listeners ) { listener.stateChanged( stateEvent ); } } }
既然 CopyOnWriteArraySet 和 AtomicInteger 已經(jīng)是線程安全的了,我們不再需要上面提到的那樣一個(gè)“保護(hù)塊”。但是等一下!我們剛剛不是在學(xué)到應(yīng)該用一個(gè)快照來(lái)廣播事件,來(lái)替代用一個(gè)隱形的迭代器在原集合(Set)里面做循環(huán)嘛?
這或許有些繞腦子,但是由 CopyOnWriteArraySet 提供的 Iterator(迭代器)里面已經(jīng)有了一個(gè)“快照“。CopyOnWriteXXX 這樣的集合就是被特別設(shè)計(jì)在這種情況下大顯身手的——它在小長(zhǎng)度的場(chǎng)景下會(huì)很高效,而針對(duì)頻繁迭代和只有少量?jī)?nèi)容修改的場(chǎng)景也做了優(yōu)化。這就意味著我們的代碼是安全的。
隨著 Java 8 的發(fā)布,broadcast 方法可以因?yàn)镮terable#forEach 和 lambdas表達(dá)式的結(jié)合使用而變得更加簡(jiǎn)潔,代碼當(dāng)然也是同樣安全,因?yàn)榈廊槐憩F(xiàn)為在“快照”中進(jìn)行:
private void broadcast( StateEvent stateEvent ) { listeners.forEach( listener -> listener.stateChanged( stateEvent ) ); }
異常處理
介紹了如何處理拋出 RuntimeExceptions 的那些損壞的監(jiān)聽器。盡管我總是嚴(yán)格對(duì)待 fail-fast 錯(cuò)誤機(jī)制,但在這種情況下讓這個(gè)異常得不到處理是不合適的。尤其考慮到這種實(shí)現(xiàn)經(jīng)常在一些多線程環(huán)境里被用到。
損壞的監(jiān)聽器會(huì)有兩種方式來(lái)破壞系統(tǒng):***,它會(huì)阻止通知向觀察者的傳達(dá)過(guò)程;第二,它會(huì)傷害那些沒(méi)有準(zhǔn)備處理好這類問(wèn)題的調(diào)用線程??偠灾軌?qū)е露喾N莫名其妙的故障,并且有的還難以追溯其原因,
因此,把每一個(gè)通知區(qū)域用一個(gè) try-catch 塊來(lái)保護(hù)起來(lái)會(huì)顯得比較有用。
private void broadcast( StateEvent stateEvent ) { listeners.forEach( listener -> notifySafely( stateEvent, listener ) ); } private void notifySafely( StateEvent stateEvent, StateListener listener ) { try { listener.stateChanged( stateEvent ); } catch( RuntimeException unexpected ) { // appropriate exception handling goes here... } }
綜上所述,Java 的事件通知里面有一些基本要點(diǎn)你還是必須得記住的。在事件通知過(guò)程中,要確保在監(jiān)聽器集合的快照里做迭代,保證事件通知在同步塊之外,并且在合適的時(shí)候再安全地通知監(jiān)聽器。
看完上述內(nèi)容,你們掌握如何正確的使用Java事件通知的方法了嗎?如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容,歡迎關(guān)注億速云行業(yè)資訊頻道,感謝各位的閱讀!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。