Common Lock Types in Distributed Systems and Their Java Implementations

In the era of distributed systems, thread concurrency and resource contention make locking a crucial technique for ensuring data consistency and performance.

1. Pessimistic Lock – assumes high contention and locks data at the database level (e.g., SELECT * FROM table WHERE id = #{id} FOR UPDATE ) or via Java's synchronized . It guarantees exclusive access but can degrade throughput if held too long.

2. Optimistic Lock – assumes low contention; updates include a version check (e.g., UPDATE table SET ..., version = version + 1 WHERE id = #{id} AND version = #{version} ). If the version mismatches, the operation fails (fail‑fast) and the caller must retry.

3. Distributed Lock – solves mutual exclusion across multiple machines. Common implementations use Redis ( SET key unique_value NX EX seconds ) with Lua scripts for atomic release, or Zookeeper. The Redlock algorithm acquires locks on a majority of Redis nodes to consider the lock successful.

4. Reentrant (Exclusive) Lock – Java's ReentrantLock and synchronized provide exclusive access for a single thread, supporting recursion and optional fairness.

5. Spin Lock – a thread repeatedly checks a condition (busy‑wait) before entering the critical section; suitable when contention is low. It can be limited by a timeout or iteration count to avoid CPU waste.

6. Shared Lock – allows multiple readers simultaneously while writers obtain exclusive access; implemented in Java via ReentrantReadWriteLock (read lock is shared, write lock is exclusive).

7. Fair vs. Non‑Fair Lock – a fair lock grants access in request order, preventing starvation but reducing throughput; a non‑fair lock may let a thread “cut in line,” improving performance at the risk of starvation.

8. Interruptible vs. Non‑Interruptible Lock – synchronized is non‑interruptible, whereas ReentrantLock offers interruptible acquisition via lockInterruptibly() .

9. Segment Lock – used in ConcurrentHashMap where each segment (a ReentrantLock ) protects a subset of buckets, enabling higher concurrency than a single global lock.

10. Lock Upgrade (No‑Lock → Biased → Lightweight → Heavyweight) – the JVM escalates lock state based on contention: no lock (optimistic), biased lock (single‑thread fast path), lightweight lock (spinning), and heavyweight lock (OS‑level blocking).

11. Lock Optimization Techniques – lock coarsening merges multiple fine‑grained lock acquisitions into a single broader lock (e.g., moving a synchronized block outside a loop), while lock elimination removes unnecessary synchronization when escape analysis proves no contention (e.g., replacing StringBuffer with StringBuilder ).

Understanding these lock types and their trade‑offs helps developers choose the appropriate synchronization strategy for both single‑machine and distributed Java applications.