Synchronization.

Hook: Interviewers love this because synchronization is the difference between a program that works once and one that stays correct under load.

Question: What is synchronization in Java?

Answer: Synchronization is how Java makes sure only one thread at a time can run a critical section of code that touches shared mutable data. It prevents race conditions, which happen when two threads interleave in a bad way and corrupt the result. In Java, the common tool is the synchronized keyword, which uses an object's intrinsic lock, also called a monitor.

Interview-Ready Answer: In Java, synchronization is the mechanism I use to protect shared mutable state from race conditions. I usually do that with synchronized, which acquires an intrinsic lock on an object so only one thread can enter the critical section at a time. A useful detail is that it also gives memory visibility guarantees, so updates made inside the synchronized block are seen by the next thread that acquires the same lock.

What synchronization really means

Detailed Explanation: Synchronization is a rule for shared mutable state: one thread enters the protected code, everyone else waits, and the state changes become visible to the next thread that enters through the same lock. A monitor is the JVM's built-in lock attached to every object. Think of it as a room key: if you hold the key, you are the only one allowed inside that room.

How it works under the hood

1. A thread reaches a synchronized method or block.
2. The JVM chooses a target monitor: instance methods lock this, static methods lock the Class object, and blocks lock the object inside synchronized(lock).
3. If no other thread owns that monitor, the JVM grants it and the thread enters the critical section.
4. If the same thread already owns the monitor, Java lets it re-enter it. This is called reentrancy, which means the same thread can safely take the same lock again without deadlocking itself.
5. If another thread owns the monitor, the current thread blocks until the lock is released.
6. When the thread leaves the block normally or by throwing an exception, the JVM releases the monitor automatically. That release acts like a memory fence: writes done inside become visible to the next thread that acquires the same lock.

What to use it for

Use synchronization when you need to protect a critical section: a small region where a shared field, collection, or invariant must not be observed half-finished. Classic examples are counters, bank balances, lazy initialization, and check-then-act logic such as “if stock is available, decrement it now.”

Prefer a small synchronized block over a whole method when possible, because a shorter critical section means less waiting and better throughput. Also prefer a private lock object for library code, so outside callers cannot accidentally lock on your public object and create surprises.

Comparison with alternatives

AtomicInteger is great for a single numeric value, but it does not replace a lock when several fields must change together. For example, a bank transfer needs both accounts updated as one unit, so a lock is often the clearer tool.

Performance and edge cases

Acquiring and releasing an uncontended monitor is effectively O(1), and modern JVMs optimize it heavily. The expensive part is contention: if many threads want the same lock, they may block, context-switch, and wait milliseconds instead of nanoseconds. There is no fairness guarantee, no built-in timeout, and no interruptible lock acquisition with synchronized.

Important edge cases: static synchronized locks the class, not an instance; calling wait() or notify() requires holding the same monitor; and synchronizing only getters and setters does not make a multi-step operation safe if the logic spans multiple calls. Also, do not synchronize on public strings, boxed numbers, or other shared objects that code outside your class can accidentally reuse.

Memory model note: The big interview point is that synchronization is not only about exclusion. It also creates a happens-before relationship, which means the next thread that acquires the same lock sees the latest values written by the previous owner.

Real-World Example: In a checkout service for an online store, a method reserves inventory when an order is placed. If two threads read the same last item at the same time and the check plus decrement is not protected by one lock, both requests can succeed and oversell the product. In production, that shows up as duplicate confirmations, negative stock counts, and support tickets saying that a customer paid, but the item was later canceled. The logs often look suspiciously normal at first: two lines like reserved sku=123 remaining=0 appear back to back, which is a clue that the check-and-update was split across threads. The fix is to keep the whole invariant change inside one synchronized critical section, or use a database transaction / atomic compare-and-set if the state lives outside one JVM.

What goes wrong: The outage usually looks like a race, because it is one: threads interleave between the stock check and the decrement. Customers see oversells, payment capture may succeed, but fulfillment later fails.

Follow-up & Tricky Questions:

• Why does synchronization also solve visibility? Because a successful lock release and the next lock acquire on the same monitor create a happens-before edge, so the next thread sees the latest writes, not stale cached values.
• What is the difference between a synchronized method and a synchronized block? A method locks the whole object or class for the whole method body, while a block lets you lock only the small section that truly needs protection, which usually improves throughput.
• When would you choose ReentrantLock instead? Use it when you need tryLock(), timed lock attempts, fairness options, or multiple Condition queues; for simple cases, synchronized is easier and safer because it unlocks automatically.
• Can synchronization protect multiple fields at once? Yes, as long as every field in the invariant is guarded by the same lock. That is exactly why it is useful for transfers, balances, and cache state that must change together.
• What is wait() and why is it related? wait() temporarily releases the same monitor and suspends the thread until another thread calls notify() or notifyAll(); the waiting thread must re-acquire the monitor before continuing.
• Does synchronized make collections thread-safe automatically? Only if every access to that collection uses the same lock. If some code touches it without the lock, the collection is still unsafe.
• Can two synchronized methods on the same object run at the same time? No. They both need the same intrinsic lock, so only one can enter at a time.
• Is synchronized fair? No. Java does not promise first-come-first-served ordering, so a thread may wait longer than another thread that arrives later.
• Gotcha: does synchronized make an object immutable? No. It only serializes access. The object can still change; it is just changed one thread at a time.

Common Mistakes:

• Locking the wrong object. Correction: use one private final lock for one invariant, instead of locking different objects for the same state.
• Synchronizing only getters and setters. Correction: protect the whole check-and-act sequence, because the bug is usually in the gap between operations.
• Holding a lock while doing slow I/O. Correction: keep the critical section short, copy what you need, release the lock, then do the slow work outside.
• Using public or shared objects as locks. Correction: avoid interned strings, boxed integers, or exposed this references, because outside code can accidentally interfere.

Memory Hook: Think of synchronization as one bathroom key in a busy office: only one person can enter, and when they leave, the key is available to the next person. That picture also reminds you that the key is returned automatically when the method ends, even if an exception happens.

Cheat Sheet:

• synchronized = mutual exclusion + visibility.
• Instance method locks this; static method locks the Class object.
• Use one lock for one shared invariant.
• Prefer a small synchronized block over a large synchronized method.
• Choose ReentrantLock for timeout/try-lock features.
• Choose AtomicInteger for a single counter, not for multi-field state.

Practice Tasks:

• Wrap a plain counter increment in synchronized and compare the result with an unsynchronized version.
• Refactor the bank account example to use a private final lock object instead of synchronizing on this.
• Replace the safe counter with AtomicInteger and explain why it works for counting but not for a two-field invariant.