{"title":"Synchronization Basics","description":null,"content":"# Synchronization Basics\n\nTwo threads updating the same bank account balance. Two processes writing to the same file. Two servers modifying the same database row.\n\nWithout **synchronization**, these concurrent operations lead to corrupted data, lost updates, and bugs that are impossible to reproduce consistently.\n\nSynchronization is the coordination of multiple threads to ensure correct behavior when accessing shared resources. It's one of the most important concepts in concurrent programming.\n\nIn this article, we'll explore:\n\n- Why synchronization is necessary\n- Race conditions and data races\n- Critical sections\n- Mutual exclusion and locks\n- Synchronization mechanisms\n- Common patterns and pitfalls\n\n---\n\nIf you're enjoying this newsletter and want to get even more value, consider becoming a **[paid subscriber](https://blog.algomaster.io/subscribe)**.\n\nAs a paid subscriber, you'll unlock all **premium articles** and gain full access to all **[premium courses](https://algomaster.io/newsletter/paid/resources)** on **[algomaster.io](https://algomaster.io)**.\n\n[Unlock Full Access](undefined)\n\n---\n\n## 1. The Problem: Shared Mutable State\n\nWhen multiple threads access the same data and at least one of them modifies it, you have **shared mutable state**. This is where concurrency bugs originate.\n\nConsider a simple counter:\n\n\n```java\npublic class Counter {\n private int count = 0;\n\n public void increment() {\n count++;\n }\n\n public int getCount() {\n return count;\n }\n}\n```\n\n\nThis looks harmless. But `count++` is not a single operation. It's actually three operations:\n\n1. **Read** the current value of count\n2. **Add** 1 to that value\n3. **Write** the new value back to count\n\n\n```mermaid\nflowchart LR\n subgraph Increment[\"count++ (Not Atomic)\"]\n R[\"1. Read count\"]\n A[\"2. Add 1\"]\n W[\"3. Write count\"]\n R --> A --> W\n end\n\n style Increment fill:#ffa94d,stroke:#000,color:#000\n style R fill:#00ceff,stroke:#000,color:#000\n style A fill:#69db7c,stroke:#000,color:#000\n style W fill:#9775fa,stroke:#000,color:#000\n```\n\n\nWhen two threads execute this \"simultaneously,\" their operations can **interleave** in unexpected ways.\n\n---\n\n## 2. Race Conditions\n\nA **race condition** occurs when the correctness of a program depends on the relative timing of events in different threads.\n\nLet's trace what happens when two threads increment our counter from 0:\n\n\n```mermaid\nsequenceDiagram\n participant T1 as Thread 1\n participant Mem as Memory (count)\n participant T2 as Thread 2\n\n Note over Mem: count = 0\n\n T1->>Mem: Read count (gets 0)\n T2->>Mem: Read count (gets 0)\n T1->>T1: Add 1 (result = 1)\n T2->>T2: Add 1 (result = 1)\n T1->>Mem: Write 1\n T2->>Mem: Write 1\n\n Note over Mem: count = 1 (should be 2!)\n```\n\n\nBoth threads read 0, both compute 1, both write 1. One increment is lost.\n\nThis is called a **lost update** problem. The final value depends on which thread writes last, not on the actual number of increments performed.\n\n### Demonstrating the Race Condition\n\n\n```java\nCounter counter = new Counter();\n\n// Create 1000 threads, each incrementing 1000 times\nThread[] threads = new Thread[1000];\nfor (int i = 0; i < 1000; i++) {\n threads[i] = new Thread(() -> {\n for (int j = 0; j < 1000; j++) {\n counter.increment();\n }\n });\n threads[i].start();\n}\n\n// Wait for all threads to complete\nfor (Thread t : threads) {\n t.join();\n}\n\nSystem.out.println(counter.getCount());\n// Expected: 1,000,000\n// Actual: Some number less than 1,000,000 (varies each run)\n```\n\n\nThe result is unpredictable. You might get 987,432 one time and 991,876 another. This non-determinism makes race conditions extremely difficult to debug.\n\n---\n\n## 3. Critical Sections\n\nA **critical section** is a piece of code that accesses shared resources and must not be executed by more than one thread at a time.\n\n\n```mermaid\nflowchart TB\n subgraph Code[\"Program Flow\"]\n NonCrit1[\"Non-critical code
(can run in parallel)\"]\n Crit[\"Critical Section
(shared resource access)\"]\n NonCrit2[\"Non-critical code
(can run in parallel)\"]\n end\n\n NonCrit1 --> Crit\n Crit --> NonCrit2\n\n style NonCrit1 fill:#69db7c,stroke:#000,color:#000\n style Crit fill:#ff8787,stroke:#000,color:#000\n style NonCrit2 fill:#69db7c,stroke:#000,color:#000\n```\n\n\nIn our counter example, the critical section is the `count++` operation. To prevent race conditions, we need to ensure only one thread executes the critical section at a time.\n\nThis property is called **mutual exclusion**.\n\n---\n\n## 4. Mutual Exclusion\n\n**Mutual exclusion** (mutex) ensures that only one thread can execute a critical section at any given time. Other threads must wait until the first thread exits the critical section.\n\n\n```mermaid\nsequenceDiagram\n participant T1 as Thread 1\n participant Lock as Lock\n participant CS as Critical Section\n participant T2 as Thread 2\n\n T1->>Lock: Acquire lock\n Lock-->>T1: Lock granted\n T1->>CS: Enter critical section\n\n T2->>Lock: Acquire lock\n Note over T2: Blocked (waiting)\n\n T1->>CS: Exit critical section\n T1->>Lock: Release lock\n\n Lock-->>T2: Lock granted\n T2->>CS: Enter critical section\n```\n\n\nThe **lock** (also called mutex or monitor) is the mechanism that enforces mutual exclusion. A thread must acquire the lock before entering the critical section and release it when done.\n\n---\n\n## 5. The synchronized Keyword\n\nMost languages provide built-in synchronization mechanisms. In Java, the `synchronized` keyword provides mutual exclusion.\n\n### Synchronized Methods\n\n\n```java\npublic class Counter {\n private int count = 0;\n\n public synchronized void increment() {\n count++; // Only one thread can execute this at a time\n }\n\n public synchronized int getCount() {\n return count;\n }\n}\n```\n\n\nWhen a thread calls a synchronized method:\n\n1. It acquires the lock on the object (`this`)\n2. Executes the method\n3. Releases the lock (even if an exception occurs)\n\nOther threads calling synchronized methods on the same object must wait.\n\n\n```mermaid\nflowchart TB\n subgraph Object[\"Counter Object\"]\n Lock[\"Intrinsic Lock
(Monitor)\"]\n Inc[\"increment()\"]\n Get[\"getCount()\"]\n end\n\n T1[\"Thread 1\"] -->|\"acquires\"| Lock\n Lock -->|\"protects\"| Inc\n Lock -->|\"protects\"| Get\n\n T2[\"Thread 2\"] -.->|\"waits for\"| Lock\n\n style Object fill:#00ceff,stroke:#000,color:#000\n style Lock fill:#ff8787,stroke:#000,color:#000\n style Inc fill:#69db7c,stroke:#000,color:#000\n style Get fill:#69db7c,stroke:#000,color:#000\n style T1 fill:#ffa94d,stroke:#000,color:#000\n style T2 fill:#9775fa,stroke:#000,color:#000\n```\n\n\n### Synchronized Blocks\n\nFor finer control, you can synchronize specific blocks of code:\n\n\n```java\npublic class Counter {\n private int count = 0;\n private final Object lock = new Object();\n\n public void increment() {\n // Non-critical code can run here...\n\n synchronized (lock) {\n count++; // Critical section\n }\n\n // More non-critical code...\n }\n}\n```\n\n\nSynchronized blocks let you:\n\n- Protect only the critical section (better performance)\n- Use different locks for different resources\n- Use any object as a lock\n\n---\n\n## 6. Lock Objects\n\nFor more flexibility, most languages provide explicit lock classes. In Java, the `ReentrantLock` class offers additional features.\n\n\n```java\nimport java.util.concurrent.locks.Lock;\nimport java.util.concurrent.locks.ReentrantLock;\n\npublic class Counter {\n private int count = 0;\n private final Lock lock = new ReentrantLock();\n\n public void increment() {\n lock.lock();\n try {\n count++;\n } finally {\n lock.unlock(); // Always release in finally block\n }\n }\n}\n```\n\n\n### synchronized vs Lock Objects\n\n\n| ##### Feature | ##### synchronized | ##### Lock (ReentrantLock) |\n| --- | --- | --- |\n| Syntax | Built-in keyword | Explicit API |\n| Release | Automatic | Manual (must call unlock) |\n| Try to acquire | No | Yes (tryLock) |\n| Timeout | No | Yes (tryLock with timeout) |\n| Interruptible | No | Yes (lockInterruptibly) |\n| Fairness | No | Optional (fair lock) |\n| Multiple conditions | No | Yes (multiple Condition objects) |\n\n\n### Try Lock (Non-blocking)\n\n\n```java\nif (lock.tryLock()) {\n try {\n // Critical section\n } finally {\n lock.unlock();\n }\n} else {\n // Lock not available, do something else\n}\n```\n\n\n### Lock with Timeout\n\n\n```java\nif (lock.tryLock(1, TimeUnit.SECONDS)) {\n try {\n // Critical section\n } finally {\n lock.unlock();\n }\n} else {\n // Couldn't acquire lock within 1 second\n}\n```\n\n\n---\n\n## 7. What Synchronization Guarantees\n\nSynchronization provides three guarantees:\n\n### 7.1 Mutual Exclusion\n\nOnly one thread can hold the lock at a time. This prevents race conditions in critical sections.\n\n### 7.2 Visibility\n\nChanges made by one thread are visible to other threads. Without synchronization, threads might see stale values due to CPU caching.\n\n\n```mermaid\nflowchart TB\n subgraph T1[\"Thread 1 (CPU 1)\"]\n C1[\"CPU Cache\"]\n end\n\n subgraph T2[\"Thread 2 (CPU 2)\"]\n C2[\"CPU Cache\"]\n end\n\n Mem[\"Main Memory
count = 5\"]\n\n C1 <-->|\"May be stale\"| Mem\n C2 <-->|\"May be stale\"| Mem\n\n Note1[\"Without sync: Thread 2 might
see count = 0 (stale cache)\"]\n\n style T1 fill:#00ceff,stroke:#000,color:#000\n style T2 fill:#ffa94d,stroke:#000,color:#000\n style Mem fill:#69db7c,stroke:#000,color:#000\n style C1 fill:#38d9a9,stroke:#000,color:#000\n style C2 fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nWhen a thread releases a lock, all its writes are flushed to main memory. When another thread acquires the same lock, it sees those updates.\n\n### 7.3 Ordering\n\nOperations before releasing a lock **happen-before** operations after acquiring the same lock. The compiler and CPU cannot reorder operations across lock boundaries in ways that would affect correctness.\n\n---\n\n## 8. Common Synchronization Patterns\n\n### Pattern 1: Guarded Blocks\n\nWait for a condition to become true:\n\n\n```java\npublic class BoundedBuffer {\n private Queue queue = new LinkedList<>();\n private int capacity;\n\n public synchronized void put(T item) throws InterruptedException {\n while (queue.size() == capacity) {\n wait(); // Release lock and wait\n }\n queue.add(item);\n notifyAll(); // Wake up waiting consumers\n }\n\n public synchronized T take() throws InterruptedException {\n while (queue.isEmpty()) {\n wait(); // Release lock and wait\n }\n T item = queue.poll();\n notifyAll(); // Wake up waiting producers\n return item;\n }\n}\n```\n\n\n\n```mermaid\nflowchart TB\n subgraph Producer[\"Producer Thread\"]\n P1[\"Check: buffer full?\"]\n P2[\"wait()\"]\n P3[\"Add item\"]\n P4[\"notifyAll()\"]\n end\n\n subgraph Consumer[\"Consumer Thread\"]\n C1[\"Check: buffer empty?\"]\n C2[\"wait()\"]\n C3[\"Take item\"]\n C4[\"notifyAll()\"]\n end\n\n P1 -->|\"Yes\"| P2\n P1 -->|\"No\"| P3\n P3 --> P4\n\n C1 -->|\"Yes\"| C2\n C1 -->|\"No\"| C3\n C3 --> C4\n\n P4 -.->|\"wakes\"| C2\n C4 -.->|\"wakes\"| P2\n\n style P1 fill:#00ceff,stroke:#000,color:#000\n style P2 fill:#ff8787,stroke:#000,color:#000\n style P3 fill:#69db7c,stroke:#000,color:#000\n style P4 fill:#ffa94d,stroke:#000,color:#000\n style C1 fill:#00ceff,stroke:#000,color:#000\n style C2 fill:#ff8787,stroke:#000,color:#000\n style C3 fill:#69db7c,stroke:#000,color:#000\n style C4 fill:#ffa94d,stroke:#000,color:#000\n```\n\n\n### Pattern 2: Lock Ordering\n\nPrevent deadlock by always acquiring locks in the same order:\n\n\n```java\n// Always lock account with lower ID first\npublic void transfer(Account from, Account to, int amount) {\n Account first = from.getId() < to.getId() ? from : to;\n Account second = from.getId() < to.getId() ? to : from;\n\n synchronized (first) {\n synchronized (second) {\n from.withdraw(amount);\n to.deposit(amount);\n }\n }\n}\n```\n\n\n### Pattern 3: Double-Checked Locking\n\nLazy initialization with minimal synchronization:\n\n\n```java\npublic class Singleton {\n private static volatile Singleton instance;\n\n public static Singleton getInstance() {\n if (instance == null) { // First check (no lock)\n synchronized (Singleton.class) {\n if (instance == null) { // Second check (with lock)\n instance = new Singleton();\n }\n }\n }\n return instance;\n }\n}\n```\n\n\nNote: The `volatile` keyword is essential here to prevent instruction reordering.\n\n---\n\n## 9. The volatile Keyword\n\nThe `volatile` keyword provides visibility guarantees without mutual exclusion. It's useful for simple flags and single-variable state.\n\n\n```java\npublic class TaskRunner {\n private volatile boolean running = true;\n\n public void run() {\n while (running) { // Always reads from main memory\n doWork();\n }\n }\n\n public void stop() {\n running = false; // Immediately visible to other threads\n }\n}\n```\n\n\n\n```mermaid\nflowchart LR\n subgraph Without[\"Without volatile\"]\n T1a[\"Thread 1
running = true (cached)\"]\n T2a[\"Thread 2
sets running = false\"]\n Note1[\"Thread 1 never sees
the change!\"]\n end\n\n subgraph With[\"With volatile\"]\n T1b[\"Thread 1
reads from main memory\"]\n T2b[\"Thread 2
writes to main memory\"]\n Note2[\"Thread 1 sees
change immediately\"]\n end\n\n style Without fill:#ff8787,stroke:#000,color:#000\n style With fill:#69db7c,stroke:#000,color:#000\n```\n\n\n### volatile vs synchronized\n\n\n| ##### Aspect | ##### volatile | ##### synchronized |\n| --- | --- | --- |\n| Mutual exclusion | No | Yes |\n| Visibility | Yes | Yes |\n| Atomicity | Only for reads/writes | Yes (for entire block) |\n| Use case | Flags, single variables | Compound operations |\n| Performance | Faster | Slower |\n\n\n**Important:** `volatile` does NOT make `count++` atomic. You still need synchronization for compound operations.\n\n---\n\n## 10. Atomic Variables\n\nFor simple atomic operations, use atomic classes instead of synchronization:\n\n\n```java\nimport java.util.concurrent.atomic.AtomicInteger;\n\npublic class Counter {\n private AtomicInteger count = new AtomicInteger(0);\n\n public void increment() {\n count.incrementAndGet(); // Atomic operation\n }\n\n public int getCount() {\n return count.get();\n }\n}\n```\n\n\nAtomic classes use hardware-level atomic instructions (like Compare-And-Swap) that are faster than locks.\n\n\n```mermaid\nflowchart LR\n subgraph CAS[\"Compare-And-Swap (CAS)\"]\n R[\"Read current value\"]\n C[\"Compute new value\"]\n Swap[\"Atomic: if current unchanged,
swap to new value\"]\n Retry[\"Retry if failed\"]\n end\n\n R --> C --> Swap\n Swap -->|\"Failed\"| Retry\n Retry --> R\n Swap -->|\"Success\"| Done[\"Done\"]\n\n style CAS fill:#69db7c,stroke:#000,color:#000\n style R fill:#00ceff,stroke:#000,color:#000\n style C fill:#ffa94d,stroke:#000,color:#000\n style Swap fill:#9775fa,stroke:#000,color:#000\n style Retry fill:#ff8787,stroke:#000,color:#000\n```\n\n\nCommon atomic classes:\n\n- `AtomicInteger`, `AtomicLong`, `AtomicBoolean`\n- `AtomicReference`\n- `AtomicIntegerArray`, `AtomicLongArray`\n\n---\n\n## 11. Common Pitfalls\n\n### Pitfall 1: Synchronizing on Wrong Object\n\n\n```java\n// Bad: Each thread synchronizes on different object\npublic void increment() {\n synchronized (new Object()) { // New object each time!\n count++;\n }\n}\n\n// Good: Synchronize on shared object\nprivate final Object lock = new Object();\n\npublic void increment() {\n synchronized (lock) {\n count++;\n }\n}\n```\n\n\n### Pitfall 2: Holding Locks Too Long\n\n\n```java\n// Bad: Lock held during slow I/O\nsynchronized (lock) {\n processData();\n saveToDatabase(); // Slow!\n sendNotification(); // Also slow!\n}\n\n// Good: Minimize critical section\nData data;\nsynchronized (lock) {\n data = processData(); // Only protect shared state\n}\nsaveToDatabase(data); // Outside critical section\nsendNotification(data);\n```\n\n\n### Pitfall 3: Inconsistent Locking\n\n\n```java\n// Bad: Only some methods are synchronized\npublic class Account {\n private int balance;\n\n public synchronized void deposit(int amount) {\n balance += amount;\n }\n\n public int getBalance() { // Not synchronized!\n return balance; // May see stale value\n }\n}\n```\n\n\nAll access to shared state must be synchronized, not just writes.\n\n### Pitfall 4: Deadlock from Lock Ordering\n\n\n```java\n// Thread 1 // Thread 2\nsynchronized (lockA) { synchronized (lockB) {\n synchronized (lockB) { synchronized (lockA) {\n // ... // ...\n } }\n} }\n// Deadlock! Each thread holds one lock and waits for the other\n```\n\n\nAlways acquire multiple locks in a consistent order.\n\n### Pitfall 5: Using notify() Instead of notifyAll()\n\n\n```java\n// Risky: May wake wrong thread\nsynchronized (lock) {\n condition = true;\n lock.notify(); // Only wakes one thread\n}\n\n// Safe: Wakes all waiting threads\nsynchronized (lock) {\n condition = true;\n lock.notifyAll();\n}\n```\n\n\n---\n\n## 12. Choosing the Right Approach\n\n\n```mermaid\nflowchart TD\n Start[\"Need thread safety?\"]\n Q1[\"Single read/write
operation?\"]\n Q2[\"Simple flag or
status?\"]\n Q3[\"Need to wait
for condition?\"]\n Q4[\"Need advanced
features?\"]\n\n Atomic[\"Use Atomic classes\"]\n Volatile[\"Use volatile\"]\n Sync[\"Use synchronized\"]\n Lock[\"Use Lock/Condition\"]\n\n Start --> Q1\n Q1 -->|\"Yes\"| Atomic\n Q1 -->|\"No\"| Q2\n Q2 -->|\"Yes\"| Volatile\n Q2 -->|\"No\"| Q3\n Q3 -->|\"No\"| Sync\n Q3 -->|\"Yes\"| Q4\n Q4 -->|\"No\"| Sync\n Q4 -->|\"Yes\"| Lock\n\n style Start fill:#00ceff,stroke:#000,color:#000\n style Q1 fill:#ffa94d,stroke:#000,color:#000\n style Q2 fill:#ffa94d,stroke:#000,color:#000\n style Q3 fill:#ffa94d,stroke:#000,color:#000\n style Q4 fill:#ffa94d,stroke:#000,color:#000\n style Atomic fill:#69db7c,stroke:#000,color:#000\n style Volatile fill:#69db7c,stroke:#000,color:#000\n style Sync fill:#69db7c,stroke:#000,color:#000\n style Lock fill:#69db7c,stroke:#000,color:#000\n```\n\n\n\n| ##### Scenario | ##### Recommended Approach |\n| --- | --- |\n| Counter, simple numeric ops | `AtomicInteger` |\n| Boolean flag, status | `volatile` |\n| Compound operations | `synchronized` |\n| Need timeout/tryLock | `ReentrantLock` |\n| Multiple wait conditions | `Lock` + `Condition` |\n| High read, low write | `ReadWriteLock` |\n\n\n---\n\n## 13. Summary\n\n**Synchronization** coordinates thread access to shared resources, preventing race conditions and ensuring data consistency.\n\n\n```mermaid\nflowchart LR\n subgraph Problem[\"The Problem\"]\n Race[\"Race Conditions\"]\n Lost[\"Lost Updates\"]\n Stale[\"Stale Data\"]\n end\n\n subgraph Solution[\"The Solutions\"]\n Sync[\"synchronized\"]\n Lock[\"Lock objects\"]\n Atomic[\"Atomic classes\"]\n Vol[\"volatile\"]\n end\n\n Problem -->|\"Solved by\"| Solution\n\n style Problem fill:#ff8787,stroke:#000,color:#000\n style Solution fill:#69db7c,stroke:#000,color:#000\n```\n\n\n**Key Concepts:**\n\n\n| ##### Concept | ##### Description |\n| --- | --- |\n| Race Condition | Bug where outcome depends on thread timing |\n| Critical Section | Code accessing shared resources |\n| Mutual Exclusion | Only one thread in critical section at a time |\n| Lock/Monitor | Mechanism enforcing mutual exclusion |\n| Visibility | Ensuring threads see latest values |\n\n\n**Best Practices:**\n\n1. Minimize shared mutable state\n2. Keep critical sections short\n3. Always release locks (use try-finally)\n4. Use consistent lock ordering\n5. Prefer higher-level concurrency utilities\n6. Use `volatile` for simple flags, `synchronized` for compound operations\n7. Consider atomic classes for simple counters\n\nSynchronization is the foundation of correct concurrent programming. Master these basics before moving to advanced patterns like read-write locks, semaphores, and concurrent collections.\n\n---\n\nThank you for reading!\n\nIf you found it valuable, hit a like and consider subscribing for more such content every week.\n\nIf you have any questions or suggestions, leave a comment.\n\nThis post is public so feel free to share it.\n\n[Share](undefined)\n\n---\n\n**P.S.** If you're enjoying this newsletter and want to get even more value, consider becoming a **[paid subscriber](https://blog.algomaster.io/subscribe)**.\n\nAs a paid subscriber, you'll unlock all **premium articles** and gain full access to all **[premium courses](https://algomaster.io/newsletter/paid/resources)** on **[algomaster.io](https://algomaster.io)**.\n\n[Unlock Full Access](undefined)\n\n**There are [group discounts](https://blog.algomaster.io/subscribe?group=true), [gift options](https://blog.algomaster.io/subscribe?gift=true), and [referral bonuses](https://blog.algomaster.io/leaderboard) available.**\n\n---\n\nCheckout my **[Youtube channel](https://www.youtube.com/@ashishps_1/videos)** for more in-depth content.\n\nFollow me on **[LinkedIn](https://www.linkedin.com/in/ashishps1/)** and **[X](https://twitter.com/ashishps_1)** to stay updated.\n\nCheckout my **[GitHub repositories](https://github.com/ashishps1)** for free interview preparation resources.\n\nI hope you have a lovely day!\n\nSee you soon, Ashish\n\n---\n\n## References\n\n- [Java Concurrency in Practice (Brian Goetz)](undefined) - The definitive guide to Java concurrency\n- [Java Language Specification: Threads and Locks](undefined)\n- [Oracle Java Tutorials: Synchronization](undefined)\n- [The Art of Multiprocessor Programming (Herlihy & Shavit)](undefined)\n\n---\n\n## Images Needed\n\n[IMAGE 1: Race Condition Timeline] \n\n[IMAGE 2: Critical Section Diagram] \n\n[IMAGE 3: Lock Acquisition Sequence] \n\n[IMAGE 4: Memory Visibility Problem] \n\n[IMAGE 5: Synchronization Mechanisms Comparison] \n\n[IMAGE 6: Decision Flowchart] ","pageType":"lld-interviews"}

Synchronization Basics

Ashish Pratap Singh

Get Premium