Oberver mode is often "advertised" to quickly respond to the change of Client, timely distributing Message to subscribers, kao ...
In fact, the default JDK API will not meet the so-called fast response, even less as traditional processes: (
Take a look at what JDK's Oberver has done something ...
This is the code of the OBSERVABLE class to notify OBServer
IF (! Changed) return; arrlocal = obs.toArray (); clearchanged ();} for (int i = arrlocal.length-1; i> = 0; i -) (OBServer) arrlocal [i]). Update (this, arg);
This UPDATE method notifies the registered observer. If the previous observer will take a long time, the second thing needs to wait ..... Khan ...
Look carefully of JDK's instructions
The order in which notifications will be delivered is unspecified. The default implementation provided in the Observerable class will notify Observers in the order in which they registered interest, but subclasses may change this order, use no guaranteed order, deliver notifications on separate threads, or May Guarantee That Their Subclass Follows this Order, as They choose.
It's very clear, we only go to the multi-thread to solve this problem ........
