Shulou(Shulou.com)06/02 Report--

How to correctly use Java event notification, I believe that many inexperienced people do not know what to do. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

It may not seem difficult to provide Java event notification (Java event notification) by implementing the observer pattern, but it is easy to fall into some traps in the process. I introduced some common mistakes I made accidentally in various situations.

Java event notification

Let's start with the simplest Java Bean, called StateHolder, which encapsulates a private int-type property state and common access methods:

Public class StateHolder {private int state; public int getState () {return state;} public void setState (int state) {this.state = state;}}

Now suppose we decide to have Java bean broadcast a state-changed event to a registered observer. Piece of cake! Define the simplest event and listener as soon as you roll up your sleeves.

/ / 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);}

Next, we need to register StatListeners in the instance of StateHolder.

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);}}

* A key point: you need to adjust the StateHolder#setState method to ensure that every time the status changes, the notification indicates that the status has really changed compared with the last time:

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);}}

Got it! That's all you want. In order to be zhuang-specific, we may even have implemented a test-driven approach and are proud of the tight code coverage and the little green bar that indicates that the test has passed. And anyway, isn't that what I learned from those online tutorials?

So here's the problem: this solution is flawed.

Concurrent modification

It is easy to encounter concurrent modification exceptions (ConcurrentModificationException) when writing StateHolder as above, even if it is limited to a single thread. But who caused this anomaly and why did it happen?

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)

At first glance, the error stack contains information that the exception was thrown by a HashMap Iterator we used, but no iterators were used in our code, was it? Well, we actually used it. You know, the for each structure written in the broadcast method is actually transformed into an iterative loop at compile time.

Because during event broadcasting, if a listener tries to remove itself from the StateHolder instance, it may result in ConcurrentModificationException. So instead of operating on the original data structure, one solution is to iterate over the snapshot of this set of listeners.

In this way, the "remove listener" operation no longer interferes with the event broadcast mechanism (but note that the notification still has a slight semantic change, because such a removal is not reflected in the snapshot when the broadcast method is executed):

Private void broadcast (StateEvent stateEvent) {Set snapshot = new HashSet (listeners); for (StateListener listener: snapshot) {listener.stateChanged (stateEvent);}}

But what if StateHolder is used in a multithreaded environment?

Synchronization

To use StateHolder in a multithreaded environment, it must be thread-safe. But it's also easy to implement, adding synchronized to every method in our class, isn't it?

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) {[...]

Now we all have a built-in lock (Intrinsic Lock) as a guarantee when we read and write a StateHolder instance, which makes the public method atomic and ensures that the correct state is visible to different threads. Mission accomplished!

No way. Although such an implementation is thread-safe, once the program wants to call it, it needs to bear the risk of deadlock.

Imagine a situation where thread A changes the state S of the StateHolder, and when broadcasting this state S to each listener (listener), the thread B view accesses state S and is blocked. If B holds a synchronization lock for an object that is about state S and is supposed to be broadcast to one of the many listeners, we will encounter a deadlock.

That's why we need to reduce the synchronization of state access and broadcast this event in a "protection channel":

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);}

The above code is slightly improved on the previous basis, by using the Set instance as the internal lock to provide appropriate (but somewhat outdated) synchronization, and the listener's notification event occurs outside the protection block, thus avoiding the possibility of death waiting.

Note: due to the nature of the system's concurrent operations, this solution does not guarantee that change notifications arrive at listeners in the order in which they are generated. If the observer side has high requirements for the accuracy of the actual state, consider using StateHolder as the source of your event object.

If the sequence of events is critical in your program, one way to consider using a thread-safe first-in, first-out (FIFO) structure, along with snapshots of the listener, is to buffer your objects in the protection block of the setState method. As long as the FIFO structure is not empty, a separate thread can trigger the actual event (producer-consumer mode) from an unprotected area block, thus theoretically ensuring that everything is done in chronological order without risking a deadlock. I say in theory, because I haven't tried it myself so far.

Given what has been implemented earlier, we can write our thread-safe class with things like CopyOnWriteArraySet and AtomicInteger, thus making the solution less complex:

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);}

Now that CopyOnWriteArraySet and AtomicInteger are thread safe, we no longer need a "protection block" like the one mentioned above. But wait a minute! Didn't we just learn that we should broadcast events with a snapshot instead of looping through the original collection (Set) with an invisible iterator?

This may be a bit of a brainstorm, but there is already a "snapshot" in the Iterator (iterator) provided by CopyOnWriteArraySet. Collections like CopyOnWriteXXX are specially designed to work well in such situations-it can be efficient in small-length scenarios, and optimized for scenarios with frequent iterations and only a few changes. This means that our code is secure.

With the release of Java 8, the broadcast method can be made more concise by the combination of Iterable#forEach and lambdas expressions, and the code is, of course, equally secure, because iterations still appear in "snapshots":

Private void broadcast (StateEvent stateEvent) {listeners.forEach (listener-> listener.stateChanged (stateEvent);}

Exception handling

Describes how to handle corrupted listeners that throw RuntimeExceptions. Although I am always strict with the fail-fast error mechanism, it is not appropriate to leave this exception unhandled in this case. Especially considering that this implementation is often used in some multithreaded environments.

A corrupted listener can damage the system in two ways: *, which prevents notification from being communicated to the observer; and second, it harms calling threads that are not ready to deal with such problems. All in all, it can cause a variety of inexplicable failures, and some of them are difficult to trace their causes.

Therefore, it is useful to protect each notification area with a try-catch block.

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... }}

To sum up, there are some basic points you need to keep in mind in Java's event notification. During the event notification process, be sure to iterate in the snapshot of the listener collection, ensure that the event notification is outside the synchronization block, and notify the listener safely at the appropriate time.

After reading the above, have you mastered how to use Java event notification correctly? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.