Introduction to Locks

In concurrent programming, when multiple threads or processes attempt to access and modify shared resources simultaneous

In concurrent programming, when multiple threads or processes attempt to access and modify shared resources simultaneously without proper synchronization mechanisms, data corruption and race conditions are bound to occur. Locks serve as the most foundational and vital instrument to resolve these challenges. This article systematically explores the concept of locks, their common classifications, and essential practices for real-world applications.

Consider a classic counter scenario:

public class Counter {
    private int count = 0;

    public void increment() {
        count++; // Non-atomic operation
    }
}

Although count++ appears to be a single statement, it actually breaks down into three distinct steps: read, modify, and write-back. If two threads execute this operation concurrently, both might read the exact same initial value, increment it independently, and write it back, resulting in a lost update where only one increment is successfully recorded.

By introducing a lock, we transform this critical section of code to ensure that only one thread can execute it at any given moment:

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

A well-designed lock typically guarantees the following properties:

  • Mutual Exclusion: At any given time, at most one thread can hold the lock and access the critical section.
  • Visibility: Modifications made to shared variables by a thread before releasing the lock become visible to any subsequent threads that acquire the same lock.
  • Liveness: Preventing issues such as deadlocks, livelocks, and starvation to ensure that threads eventually secure the lock.

Common Types of Locks

Pessimistic and Optimistic Locks

These categories divide locks based on how they approach concurrency conflicts:

  • Pessimistic Lock: Assumes that conflicts are inevitable. It locks data before access, forcing other threads to wait. Typical examples include Java's synchronized and ReentrantLock, as well as database statements like SELECT ... FOR UPDATE. This approach is ideal for write-heavy scenarios with fierce contention.
  • Optimistic Lock: Assumes that conflicts are rare. It performs operations without locking, relying instead on version numbers or Compare-And-Swap (CAS) checks during updates to verify whether the data has been altered. This is best suited for read-heavy workloads.

A standard optimistic locking pattern in databases resembles the following SQL statement:

UPDATE account
SET balance = balance - 100, version = version + 1
WHERE id = 1 AND version = 5;

If another transaction has already updated the version field, the update affects zero rows, prompting the application layer to either retry or throw an exception.

Spin Locks

When a thread fails to acquire a lock, instead of suspending and blocking, it enters a busy-wait loop, repeatedly attempting to secure the lock. The primary advantage is avoiding the performance overhead of thread context switching, making it suitable for scenarios where locks are held for extremely short durations. The downside is that active spinning wastes CPU cycles, degrading performance drastically if the lock is held for long periods.

Read-Write Locks

A read-write lock splits access into two distinct categories:

  • Read Lock (Shared Lock): Can be held simultaneously by multiple threads, allowing concurrent reads without interference.
  • Write Lock (Exclusive Lock): Held exclusively; while a write operation is in progress, all other read and write operations must wait.

Read-write locks are exceptionally well-suited for read-heavy environments, such as caching layers and configuration systems. In Java, this is represented by ReentrantReadWriteLock.

Reentrant Locks

Reentrancy means that the same thread can acquire the same lock multiple times without blocking itself. For instance, recursive methods often require repeated locking; failing to use a reentrant lock in such contexts would cause a self-inflicted deadlock. Both synchronized and ReentrantLock are reentrant.

Database Locks

At the database layer, locks play an equally critical role and can be categorized by their granularity:

  • Table-Level Locks: Lock the entire table, offering low overhead but high contention probability (e.g., the MyISAM storage engine).
  • Row-Level Locks: Lock only the accessed rows, yielding high concurrency at the cost of greater overhead (e.g., InnoDB row locks).
  • Gap Locks: Lock the intervals between index records to prevent phantom reads.

Based on compatibility, they further divide into shared (S) locks and exclusive (X) locks, adhering to the fundamental rule: reads are shared with reads, while reads and writes, as well as writes and writes, are mutually exclusive.

Distributed Locks

Single-machine locks only function within the boundaries of a single JVM process. In distributed environments, multiple service instances may operate on the same resource concurrently, necessitating distributed locks. Common implementation approaches include:

  1. Database-Based: Utilizing unique constraints or pessimistic locking; simple to implement but constrained in performance.
  2. Redis-Based: Leveraging commands like SET key value NX EX alongside expiration times and Lua scripts for release. This offers high performance and stands as the most popular solution.
  3. ZooKeeper-Based: Utilizing ephemeral sequential nodes to guarantee high reliability, where locks are automatically released upon session termination.

Deadlocks and Prevention

A deadlock occurs when two or more threads perpetually wait for each other, each holding a lock that the other requires. A deadlock manifests only when four conditions are met simultaneously: mutual exclusion, hold and wait, no preemption, and circular wait. In practice, deadlocks can be mitigated through several strategies:

  • Acquiring multiple locks in a strict, predefined order to break the circular wait condition.
  • Utilizing tryLock with timeout mechanisms to release held locks if acquisition fails.
  • Minimizing lock granularity and shortening the duration for which locks are held.
  • Avoiding unnecessary lock nesting.

Summary

Locks form the bedrock of concurrent programming. Grasping the applicable scenarios for pessimistic and optimistic locks, recognizing the performance trade-offs between mutual exclusion and read-write locks, and understanding the principles of database and distributed locks are indispensable skills for engineering high-concurrency systems. Software development should generally follow the guiding principle: "Avoid locking unless necessary, and when locking is mandatory, use the finest possible granularity," ensuring correctness while striving for peak concurrency performance.