Implementing Distributed Locks with Redis and Redisson in Java

In distributed systems a JVM‑level synchronized lock cannot guarantee mutual exclusion across multiple instances, so a Redis‑based lock is needed.

Using setIfAbsent (SETNX) you can attempt to acquire a lock by storing a key only if it does not already exist; if the call returns false the lock acquisition fails.

Simple acquisition without expiration can lead to deadlocks when a server crashes before releasing the lock. Adding an explicit timeout with expire mitigates this, but the timeout and the lock acquisition must be atomic to avoid a window where the lock is held without an expiration.

Redis provides an atomic operation that sets the value and its TTL in a single call:

Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, "product_001_lock", 30, TimeUnit.SECONDS);

To prevent a thread that timed out from releasing another thread's lock, store a unique client identifier with the lock and verify it before deletion:

String clientId = UUID.randomUUID().toString();
Boolean result = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, clientId, 30, TimeUnit.SECONDS);
...finally {
    if (clientId.equals(stringRedisTemplate.opsForValue().get(lockKey))) {
        stringRedisTemplate.delete(lockKey);
    }
}

For more advanced scenarios, Redisson offers a high‑level API. The lock object is obtained with redisson.getLock(lockKey) and can be locked, used, and safely unlocked, while Redisson handles automatic lock renewal (watch‑dog) behind the scenes.

RLock redissonLock = redisson.getLock(lockKey);
try {
    redissonLock.lock();
    // critical section
} finally {
    redissonLock.unlock();
}

In summary, a correct distributed lock implementation must ensure mutual exclusion, avoid deadlocks through expiration, bind lock and unlock to the same logical thread (or client ID), and preferably use atomic operations or libraries like Redisson that encapsulate these concerns.