Understanding Deadlocks: Prevention, Recovery, and Resolution

 Deadlocks are a critical issue in database management systems, operating systems, and distributed computing. They occur when two or more transactions wait for each other to release resources, resulting in a state of indefinite waiting. In this article, we’ll explore the concept of deadlocks, Coffman’s conditions, strategies for prevention, and methods for recovery. By the end, you'll have practical knowledge to identify and mitigate deadlocks in your systems.

---

What is a Deadlock?

A deadlock arises when two or more transactions are stuck in a circular waiting scenario, each holding a resource and waiting to acquire a resource held by another transaction. This leads to an infinite waiting loop where no transaction can proceed.

Example:

Imagine two transactions in a banking system:

1. Transaction A locks Account X and wants Account Y.

2. Transaction B locks Account Y and wants Account X.

Neither transaction can proceed because both are waiting for resources held by the other.

---

Coffman Conditions

Edward G. Coffman, Jr., in 1971, outlined four necessary conditions that must simultaneously exist for a deadlock to occur:

1. Mutual Exclusion: At least one resource must be held in a non-shareable mode.

2. Hold and Wait: A transaction holding one resource can request additional resources.

3. No Preemption: Resources cannot be forcibly taken; they must be released voluntarily by the transaction holding them.

4. Circular Wait: A set of transactions form a circular chain where each transaction is waiting for a resource held by the next.

---

Deadlock Prevention Strategies

To prevent deadlocks, you can ensure that one or more of the Coffman conditions are not satisfied. Below are practical strategies:

1. Resource Ordering

Impose a total ordering on resource types and enforce transactions to request resources in a strictly increasing order. For example, a transaction must acquire Resource A before Resource B, regardless of execution order.

2. Timeouts

Set timeouts for resource requests. If a process waits too long, it’s rolled back to free up resources and avoid deadlocks.

3. Banker’s Algorithm

This deadlock avoidance algorithm ensures a system never enters an unsafe state by simulating resource allocation before granting requests. It checks whether resources will be available in the future to prevent deadlocks.

---

Deadlock Recovery Techniques

If deadlocks are detected, the system must resolve them by terminating or rolling back one or more transactions.

1. Selecting a Victim

Sophisticated algorithms help select a victim transaction based on:

• Resource utilization

• Transaction priority

• Rollback cost

Modern DBMSs often allow you to configure victim selection criteria for optimal performance.

2. Rollback

The system rolls back either:

• Entire Transaction: This ensures the deadlock is resolved completely.

• Partial Transaction: Only specific operations causing the deadlock are rolled back, minimizing the impact.

Rolled-back transactions are typically restarted automatically by the system.

---

Code Example: Detecting and Preventing Deadlocks

Here’s a simple Java example for deadlock detection and resolution:

public class DeadlockExample {
    private final Object resource1 = new Object();
    private final Object resource2 = new Object();

    public void processA() {
        synchronized (resource1) {
            System.out.println("Transaction A locked Resource 1");
            try { Thread.sleep(100); } catch (InterruptedException e) {}

            synchronized (resource2) {
                System.out.println("Transaction A locked Resource 2");
            }
        }
    }

    public void processB() {
        synchronized (resource2) {
            System.out.println("Transaction B locked Resource 2");
            try { Thread.sleep(100); } catch (InterruptedException e) {}

            synchronized (resource1) {
                System.out.println("Transaction B locked Resource 1");
            }
        }
    }

    public static void main(String[] args) {
        DeadlockExample example = new DeadlockExample();

        Thread t1 = new Thread(example::processA);
        Thread t2 = new Thread(example::processB);

        t1.start();
        t2.start();
    }
}

Output:

This program demonstrates a potential deadlock scenario where two threads lock resources in opposite order. To prevent this, implement resource ordering or timeout mechanisms.

---

Frequently Asked Questions (FAQ)

1. What are the Coffman conditions for deadlocks?

The Coffman conditions are:

• Mutual Exclusion

• Hold and Wait

• No Preemption

• Circular Wait These conditions must exist simultaneously for a deadlock to occur.

2. How can you prevent deadlocks in a multi-threaded environment?

You can prevent deadlocks by using resource ordering, implementing timeouts, or applying the Banker’s Algorithm to avoid unsafe resource states.

3. What is the Banker’s Algorithm?

The Banker’s Algorithm is a deadlock avoidance strategy that ensures resources are allocated only if the system remains in a safe state after allocation.

4. What’s the difference between deadlock prevention and recovery?

• Prevention: Ensures deadlocks don’t occur by design (e.g., resource ordering, timeouts).

• Recovery: Detects and resolves deadlocks after they occur by rolling back or terminating transactions.

5. What tools can detect deadlocks?

Modern DBMSs like MySQL, PostgreSQL, and Oracle have built-in deadlock detection mechanisms. For Java applications, thread dump analyzers like VisualVM can help identify deadlocks.

---

Suggested Topics for Further Reading

• Concurrency in Java: Managing Threads Safely

• Database Locking Mechanisms and Isolation Levels

• Real-Time Deadlock Detection Algorithms

• Optimizing Transaction Design in Relational Databases

---

Future-Proofing Your System

Deadlocks can severely impact system performance and user experience. To future-proof your systems:

• Regularly analyze logs for potential deadlock patterns.

• Use monitoring tools to detect and resolve deadlocks in real-time.

• Design transactions with minimal locking and hold times.

---

Deadlocks are inevitable in complex systems, but with careful design and proactive strategies, you can minimize their occurrence and impact. Have you encountered tricky deadlocks in your projects? Share your experience in the comments below!

Story of Tim the Toy Store Owner

Once upon a time, there was a toy store owner named Tim. Tim loved his toy store, but he had a big problem. Every day, many customers came to buy toys, and some customers tried to grab the same toy at the same time. Sometimes, they even fought over who should get it!

To solve this, Tim hired a helper called Spring Boot. Spring Boot was very smart and had a magical book called the Transaction Book, which helped manage all the buying and selling.

---

What’s a Transaction?

Tim’s helper explained:
"A transaction is like a deal we promise to complete fully or not at all. If something goes wrong in the middle, I will undo everything so that nobody gets confused."

For example:

• If a customer wants to buy a teddy bear but forgets to pay, Spring Boot ensures the teddy bear goes back to the shelf.
• If Tim takes money but doesn’t deliver the toy, the money is returned.

This promise was called ACID (like a magic spell):

• Atomicity: All or nothing happens.
• Consistency: The rules are always followed.
• Isolation: No two customers mess up each other’s transactions.
• Durability: Once a deal is done, it stays done!

---

The Problem with Customers Fighting

One day, two customers, Anna and Ben, saw the last blue robot toy on the shelf. Both ran to grab it. If Anna grabbed it first, Ben should wait, right? But sometimes, Ben would grab it halfway, and they both got upset. Tim called this a dirty read because Ben read something Anna hadn’t finished yet.

Spring Boot said, “I have an idea! I’ll make rules about who can touch the toys and when.”

---

Rules of Isolation

Spring Boot introduced different levels of toy rules (isolation levels):

1. READ_COMMITTED (Polite Rule):
   Anna can pick the robot and decide whether to buy it or not. Ben waits until Anna is done before touching it. No dirty fights!

2. REPEATABLE_READ (Careful Rule):
   If Anna touches the robot, Ben can't even peek at it until Anna finishes her decision. This ensures no confusion, even if Anna changes her mind.

3. SERIALIZABLE (Strict Rule):
   Only one person is allowed in the toy aisle at a time. Anna picks, decides, and leaves. Then Ben can enter. Nobody can fight, but it’s slow because only one customer is allowed.

---

Row Lock: Protecting One Toy

One day, another problem happened. Anna wanted a toy car, but Ben also wanted to buy it. To avoid this, Spring Boot said:
"I will lock the toy car while Anna decides. Ben will have to wait until Anna finishes buying it."

This was called a row lock. It protected just one toy.

---

Table Lock: Protecting All Toys

One Saturday, Tim wanted to rearrange all the toys in the store. He didn’t want anyone to touch the toys while he was working. Spring Boot said:
"No problem! I will lock the entire toy store until you're done."

This was called a table lock.

---

Example 1: Single Toy Lock

Anna wants to buy a toy car. Spring Boot locks that car for Anna so no one else can grab it until she finishes.

@Transactional
public void buyToy(Long toyId, int quantity) {
    Toy toy = toyRepository.findByIdWithLock(toyId); // Lock the toy
    toy.setQuantity(toy.getQuantity() - quantity);   // Update the quantity
    toyRepository.save(toy);
}

---

Example 2: Locking the Whole Store

Tim wants to move all toys around. Spring Boot locks the whole store, so no one can buy toys until Tim finishes.

@Transactional
public void rearrangeStore() {
    entityManager.createNativeQuery("LOCK TABLE toys IN EXCLUSIVE MODE").executeUpdate();
    // Perform the rearrangement
}

---

What Happens If We Don’t Lock?

If Spring Boot didn’t lock the toys:

1. Anna and Ben might both buy the same robot, leading to confusion.
2. Tim might rearrange the toys while customers are shopping, making a mess.

---

How Spring Boot Helps

Spring Boot explained how he kept things in order:

1. Transactions: He made sure deals were all or nothing.
2. Isolation Levels: He stopped customers from seeing unfinished business.
3. Row Locks: He protected one toy at a time.
4. Table Locks: He protected all toys when necessary.

---

Extra Example: Fixing a Robot Issue

One day, a robot toy broke, and Tim wanted to fix it before selling it.

@Transactional(isolation = Isolation.READ_COMMITTED)
public void fixRobotToy(Long toyId) {
    Toy toy = toyRepository.findByIdWithLock(toyId);
    toy.setCondition("Fixed");
    toyRepository.save(toy);
}

---

What Tim Learned

Tim realized that using Spring Boot's magic made everything run smoothly. No more fights between customers, no more broken promises, and no more confusion in his toy store.

---

This story shows how Spring Boot helps manage transactions and locks to keep everything fair and safe, just like in a real toy store! If you’re working on your own "store" (application), Spring Boot is your helpful partner to make sure nothing goes wrong.

Let me know if you want to add more details or examples! 😊

Synchronization Mechanisms in Java: Detailed Guide

 

Synchronization Mechanisms in Java: Detailed Guide

Java provides several synchronization mechanisms to manage thread access to shared resources. Below are detailed examples and a comparison of these mechanisms in terms of performance, time, space, and speed.

---

1. ReentrantLock (The Super Smart Lock)

When to use:
ReentrantLock is ideal when you need fine-grained control over lock acquisition and release. It allows you to interrupt waiting threads, specify fairness policies, and acquire/release locks in a more flexible way compared to synchronized blocks.

Example:

import java.util.concurrent.locks.ReentrantLock;

public class ReentrantLockExample {
    private final ReentrantLock lock = new ReentrantLock(true); // Fair lock

    public void playWithToy(String kidName) throws InterruptedException {
        if (lock.tryLock()) {  // Try to acquire the lock
            try {
                System.out.println(kidName + " is playing with the toy.");
                Thread.sleep(1000);  // Simulating time spent playing
            } finally {
                lock.unlock();  // Release the lock
                System.out.println(kidName + " is done playing.");
            }
        } else {
            System.out.println(kidName + " is waiting for their turn.");
        }
    }

    public static void main(String[] args) throws InterruptedException {
        ReentrantLockExample toyPlay = new ReentrantLockExample();

        Thread kid1 = new Thread(() -> {
            try {
                toyPlay.playWithToy("Kid1");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });

        Thread kid2 = new Thread(() -> {
            try {
                toyPlay.playWithToy("Kid2");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });

        kid1.start();
        kid2.start();

        kid1.join();
        kid2.join();
    }
}

---

2. Semaphore (The Toy Manager)

When to use:
Semaphore is best used when you have limited resources, such as toys, and need to control how many threads (or kids, in this case) can access the resource simultaneously.

Example:

import java.util.concurrent.Semaphore;

public class SemaphoreExample {
    private final Semaphore semaphore = new Semaphore(3);  // Only 3 kids can play at the same time

    public void playWithToy(String kidName) throws InterruptedException {
        semaphore.acquire();  // Acquire the lock
        try {
            System.out.println(kidName + " is playing with the toy.");
            Thread.sleep(1000);  // Simulating time spent playing
        } finally {
            semaphore.release();  // Release the lock
            System.out.println(kidName + " is done playing.");
        }
    }

    public static void main(String[] args) throws InterruptedException {
        SemaphoreExample toyPlay = new SemaphoreExample();

        Thread kid1 = new Thread(() -> {
            try {
                toyPlay.playWithToy("Kid1");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });

        Thread kid2 = new Thread(() -> {
            try {
                toyPlay.playWithToy("Kid2");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });

        Thread kid3 = new Thread(() -> {
            try {
                toyPlay.playWithToy("Kid3");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });

        Thread kid4 = new Thread(() -> {
            try {
                toyPlay.playWithToy("Kid4");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });

        kid1.start();
        kid2.start();
        kid3.start();
        kid4.start();

        kid1.join();
        kid2.join();
        kid3.join();
        kid4.join();
    }
}

---

3. Condition (The Wait-and-Tell System)

When to use:
Condition variables are useful when you need to wait for a specific condition to be met before proceeding. This is often used in producer-consumer problems or any scenario where one thread must wait for another to signal a condition.

Example:

import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

public class ConditionExample {
    private final Lock lock = new ReentrantLock();
    private final Condition condition = lock.newCondition();
    private boolean isKidReady = false;  // Condition for waiting

    public void playWithToy(String kidName) throws InterruptedException {
        lock.lock();
        try {
            while (!isKidReady) {
                System.out.println(kidName + " is waiting for their turn.");
                condition.await();  // Wait until notified
            }
            System.out.println(kidName + " is playing with the toy.");
            Thread.sleep(1000);  // Simulating time spent playing
            isKidReady = false;  // Reset condition after playing
            condition.signalAll();  // Notify other kids
        } finally {
            lock.unlock();
        }
    }

    public void startTurn() {
        lock.lock();
        try {
            isKidReady = true;
            condition.signalAll();  // Signal the kid that it's their turn
        } finally {
            lock.unlock();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        ConditionExample toyPlay = new ConditionExample();

        Thread kid1 = new Thread(() -> {
            try {
                toyPlay.playWithToy("Kid1");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });

        Thread kid2 = new Thread(() -> {
            try {
                toyPlay.playWithToy("Kid2");
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });

        kid1.start();
        kid2.start();

        Thread.sleep(1000);  // Allow Kid1 to wait first
        toyPlay.startTurn();  // Notify Kid1 that it's their turn

        kid1.join();
        kid2.join();
    }
}

---

4. Synchronized Blocks or Methods (The Simple Lock)

When to use:
Synchronized blocks or methods are the simplest synchronization mechanisms in Java. Use them when you need to ensure only one thread can access a critical section at a time.

Example:

public class SynchronizedExample {

    public synchronized void playWithToy(String kidName) {
        System.out.println(kidName + " is playing with the toy.");
        try {
            Thread.sleep(1000);  // Simulating time spent playing
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        System.out.println(kidName + " is done playing.");
    }

    public static void main(String[] args) throws InterruptedException {
        SynchronizedExample toyPlay = new SynchronizedExample();

        Thread kid1 = new Thread(() -> toyPlay.playWithToy("Kid1"));
        Thread kid2 = new Thread(() -> toyPlay.playWithToy("Kid2"));

        kid1.start();
        kid2.start();

        kid1.join();
        kid2.join();
    }
}

---

Performance Comparison: Time, Space, and Speed

Time Complexity:

• ReentrantLock:
  • Acquiring the lock: O(1)
  • Releasing the lock: O(1)
  • Waiting for lock (with fairness): O(log n)
• Semaphore:
  • Acquiring the lock: O(1)
  • Releasing the lock: O(1)
  • Waiting for a spot: O(1)
• Condition:
  • Acquiring the lock: O(1)
  • Waiting for condition: O(1)
  • Releasing the lock: O(1)
• Synchronized:
  • Acquiring the lock: O(1)
  • Releasing the lock: O(1)
  • Waiting for lock: O(1)

Space Complexity:

All mechanisms have O(1) space complexity as they use a fixed amount of memory to manage the lock state.

Speed:

• ReentrantLock: Slightly slower than synchronized due to overhead from lock management (e.g., fairness, interrupt handling).
• Semaphore: Efficient for limiting access to resources but may degrade if many threads compete for the lock.
• Condition: Best for complex synchronization, but could be slower if conditions are frequently checked.
• Synchronized: Fastest for basic synchronization, but lacks flexibility compared to other mechanisms.

---

Recommendation:

• ReentrantLock: Use when you need fine-grained control over lock behavior, such as fairness and the ability to interrupt waiting threads.
• Semaphore: Ideal when you have limited resources and need to manage how many threads can access them simultaneously.
• Condition: Perfect for scenarios where threads need to wait for specific conditions to be met before proceeding (e.g., producer-consumer).
• Synchronized: Best for simple use cases where you need mutual exclusion, and the performance difference isn't significant.

---

Conclusion:

The right synchronization mechanism depends on your specific use case. For more control, flexibility, and complex thread interactions, consider ReentrantLock or Condition. For simpler, resource-limited scenarios, Semaphore or Synchronized might be sufficient. Always consider the trade-offs between simplicity, flexibility, and performance when making your choice.

Choosing the Right Synchronization Mechanism in Java

 

Choosing the Right Synchronization Mechanism in Java

To enhance the usability of this discussion, a comparison table summarizing the use cases and features of each synchronization mechanism is provided at the end of the blog post. This table serves as a quick reference to help developers choose the right tool for their specific needs.

In concurrent programming, proper synchronization ensures thread safety and prevents issues like race conditions or deadlocks. Java provides several synchronization primitives, each tailored for specific use cases. Let’s explore when to use ReentrantLock, Semaphore, Condition, synchronized blocks or methods, and other synchronization mechanisms.

---

1. ReentrantLock

ReentrantLock is a more flexible alternative to synchronized. It allows fine-grained control over thread synchronization and is especially useful in scenarios requiring advanced locking features. Consider including details about advanced features like fairness policy and interruptibility in the future comparison table to further clarify the distinctions between synchronization mechanisms.

Advantages:

• Fairness Policy: The lock can be made "fair," ensuring that threads acquire the lock in the order they requested it.
• Interruptibility: Threads can be interrupted while waiting for the lock.
• Non-blocking Attempt: Threads can attempt to acquire the lock without waiting indefinitely.
• Multiple Condition Variables: A ReentrantLock can work with multiple Condition objects for finer control over thread communication.

Use Cases:

• Try-Lock with Timeout: When you need to attempt acquiring a lock for a specific period without waiting indefinitely.

  if (lock.tryLock(1, TimeUnit.SECONDS)) {
      try {
          // Critical section
      } finally {
          lock.unlock();
      }
  }
  

• Fairness: Ensuring that the longest-waiting thread gets the lock next, to prevent thread starvation.

  Lock lock = new ReentrantLock(true); // Fair lock
  

• Interruptible Locking: Allowing a thread to be interrupted while waiting for the lock.

  lock.lockInterruptibly();
  try {
      // Critical section
  } finally {
      lock.unlock();
  }
  

• Complex Thread Coordination: When multiple threads need precise coordination beyond what synchronized can handle.

---

2. Semaphore

Semaphore is used to control access to a resource pool by a fixed number of threads. It maintains a set of permits, and threads acquire or release permits as they access or leave the resource.

Advantages:

• Flexible Permits: Semaphores allow more than one thread to access a critical section simultaneously.
• Dynamic Permits Management: Permits can be added or reduced dynamically.

Use Cases:

• Rate Limiting: Restricting the number of concurrent threads accessing a resource.

  Semaphore semaphore = new Semaphore(3); // Allow up to 3 threads
  
  semaphore.acquire();
  try {
      // Critical section
  } finally {
      semaphore.release();
  }
  

• Resource Pool Management: Managing connections to a database or limiting file read/write operations.
• Thread Synchronization: Using a semaphore with zero initial permits to block threads until permits are released.

  Semaphore semaphore = new Semaphore(0);
  
  Thread t1 = new Thread(() -> {
      semaphore.release(); // Signals another thread to proceed
  });
  
  Thread t2 = new Thread(() -> {
      semaphore.acquire(); // Waits for signal
  });
  

---

3. Condition

Condition is associated with ReentrantLock and provides more control over thread communication compared to wait and notify.

Advantages:

• Explicit Signaling: Conditions allow threads to wait and be signaled explicitly, making thread communication more controlled.
• Multiple Conditions: Multiple conditions can be created and managed within the same lock, enabling fine-grained control of thread interactions.

Use Cases:

• Multiple Wait Conditions: When you need different threads to wait for specific conditions in the same critical section.

  Lock lock = new ReentrantLock();
  Condition condition = lock.newCondition();
  
  lock.lock();
  try {
      while (!someCondition) {
          condition.await(); // Wait for signal
      }
      // Proceed after signal
  } finally {
      lock.unlock();
  }
  

• Signaling Between Threads: Explicitly waking up specific waiting threads when a condition changes.

  lock.lock();
  try {
      condition.signal(); // Wakes up one waiting thread
  } finally {
      lock.unlock();
  }
  

• Producer-Consumer Problem: Conditions can simplify solutions to classic problems like producer-consumer by separating waiting conditions for producers and consumers. is associated with ReentrantLock and provides more control over thread communication compared to wait and notify.

Advantages:

• Explicit Signaling: Conditions allow threads to wait and be signaled explicitly, making thread communication more controlled.
• Multiple Conditions: Multiple conditions can be created and managed within the same lock.

Use Cases:

• Multiple Wait Conditions: When you need different threads to wait for specific conditions in the same critical section.

  Lock lock = new ReentrantLock();
  Condition condition = lock.newCondition();
  
  lock.lock();
  try {
      while (!someCondition) {
          condition.await(); // Wait for signal
      }
      // Proceed after signal
  } finally {
      lock.unlock();
  }
  

• Signaling Between Threads: Explicitly waking up specific waiting threads when a condition changes.

  lock.lock();
  try {
      condition.signal(); // Wakes up one waiting thread
  } finally {
      lock.unlock();
  }
  

• Producer-Consumer Problem: Conditions can simplify solutions to classic problems like producer-consumer by separating waiting conditions for producers and consumers.

---

4. Synchronized Block or Method

The synchronized keyword is the simplest way to achieve mutual exclusion and is sufficient for many common use cases.

Advantages:

• Ease of Use: Simple to implement and suitable for most basic synchronization needs.
• Intrinsic Locking: Automatically manages locks for methods or code blocks.

Use Cases:

• Basic Synchronization: Ensuring thread safety for small, critical sections.

  synchronized (lock) {
      // Critical section
  }
  

• Method-Level Locking: Using synchronized methods for thread-safe operations.

  public synchronized void increment() {
      counter++;
  }
  

• Intrinsic Lock: When the locking requirements are simple and you don’t need advanced features like try-lock or interruptible locking.

Note:

• Use synchronized for simplicity when advanced features are not required.
• Avoid using synchronized for long-running operations as it may lead to contention.

---

5. Other Synchronization Mechanisms

ReadWriteLock

• Provides separate locks for read and write operations, allowing multiple readers or a single writer.
• Useful in scenarios where read operations vastly outnumber write operations.

  ReadWriteLock lock = new ReentrantReadWriteLock();
  lock.readLock().lock();
  try {
      // Reading critical section
  } finally {
      lock.readLock().unlock();
  }
  
  lock.writeLock().lock();
  try {
      // Writing critical section
  } finally {
      lock.writeLock().unlock();
  }
  

Atomic Variables

• Classes like AtomicInteger, AtomicReference, and AtomicLong offer lock-free thread-safe operations for counters and references.
• Useful for simple counters or flags where full locking is overkill.

  AtomicInteger counter = new AtomicInteger();
  counter.incrementAndGet();
  

StampedLock

• Similar to ReadWriteLock but with additional optimizations for read locks.
• Allows optimistic locking, which can improve performance in read-dominated scenarios.

  StampedLock lock = new StampedLock();
  long stamp = lock.tryOptimisticRead();
  if (!lock.validate(stamp)) {
      stamp = lock.readLock();
      try {
          // Reading critical section
      } finally {
          lock.unlockRead(stamp);
      }
  }
  

---

When to Choose Which

Scenario	Recommended Primitive
Protecting a shared resource	synchronized
Need advanced locking (fairness, timeout)	ReentrantLock
Limiting concurrent access to a resource	Semaphore
Coordinating threads with conditions	Condition
Read-dominated operations	ReadWriteLock or StampedLock
Simple counters or flags	Atomic Variables

---

Summary

Each synchronization mechanism in Java serves a specific purpose. Use synchronized for simplicity, ReentrantLock for advanced locking control, Semaphore for resource limiting, Condition for sophisticated thread communication, and other tools like ReadWriteLock, Atomic Variables, or StampedLock for specialized use cases. By choosing the right tool for the job, you can write efficient and thread-safe concurrent code.