In multithreaded environments, the Observer pattern's core assumption of a single, sequential notify-then-react flow breaks down, introducing race conditions and consistency problems that a single-threaded implementation doesn't have to handle.
Key Points: • Multiple threads updating the subject's state concurrently can cause observers to see inconsistent or stale data. • Registering or removing observers while a notification is in progress can cause ConcurrentModificationException or missed/duplicate notifications. • Synchronizing the subject's state and observer list adds locking overhead, which can become a bottleneck under high update frequency. • Observers with different processing speeds can create backpressure or force the subject to block while slow observers finish. • Ensuring "exactly once" delivery to each observer under concurrent notification requires careful design, often using thread-safe collections like CopyOnWriteArrayList or a proper event bus.
Interview Tip: A concise interview answer is:
"In a multithreaded setting the risk is race conditions — multiple threads updating the subject or the observer list at the same time can corrupt state or cause missed updates. You typically need thread-safe collections for the observer list and careful synchronization around notification, but that adds overhead, so for anything at scale I'd lean toward an actual event bus or messaging system instead of a hand-rolled Observer."