If an exception is thrown inside a synchronized block or method, the JVM automatically releases the monitor lock held by the current thread as it exits the block, whether that exit happens normally or via an exception.
Key Points: • Lock release on exception is guaranteed by the JVM — it's built into how synchronized is implemented, similar to an implicit finally. • This prevents the failing thread from holding the lock forever and blocking every other thread waiting to acquire it. • The exception still propagates normally up the call stack after the lock is released — synchronized doesn't swallow or alter it. • This is a key advantage over manual explicit locks (like ReentrantLock), where forgetting a try/finally around unlock() can leave the lock held after an exception. • The shared object's state may still be left inconsistent by the partial operation, so business logic often needs its own error handling on top of the guaranteed lock release.
Example: If a synchronized transferFunds() method throws an exception halfway through updating two account balances, the lock on the account object is released immediately as the exception propagates, so other threads aren't blocked — though the transfer logic itself may need additional safeguards to avoid leaving balances inconsistent.
Interview Tip: A concise interview answer is:
"When an exception occurs inside a synchronized block, the JVM automatically releases the lock as part of exiting the block, exactly like an implicit finally — so other threads aren't blocked forever. The exception still propagates normally; only the lock management is handled for you, not the resulting shared-state consistency."