Common Pitfalls and Best Practices of Redis Distributed Locks

In distributed systems, Redis distributed locks are popular because they are simple and efficient, but they must be used correctly to avoid subtle bugs.

1. Non‑Atomic Operation

Using SETNX followed by EXPIRE is not atomic; if setting the expiration fails, the lock may never release, leading to memory exhaustion.

The atomic alternative is the SET command with NX and PX options:

String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
if ("OK".equals(result)) {
    return true;
}
return false;

2. Forgetting to Release the Lock

Even with the atomic SET, the lock must be released in a finally block to guarantee release regardless of business‑logic success or failure.

try {
    String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
    if ("OK".equals(result)) {
        return true;
    }
    return false;
} finally {
    unlock(lockKey);
}

3. Releasing Someone Else's Lock

When multiple threads use the same lockKey, a thread may release a lock that it did not acquire. To prevent this, store a unique requestId as the lock value and verify it before deletion:

if (jedis.get(lockKey).equals(requestId)) {
    jedis.del(lockKey);
    return true;
}
return false;

A Lua script can perform the check‑and‑delete atomically:

if redis.call('get', KEYS[1]) == ARGV[1] then
    return redis.call('del', KEYS[1])
else
    return 0
end

4. Massive Failed Requests

When many clients contend for a single lock (e.g., in a flash‑sale scenario), most requests fail. A spin lock with retry and timeout can improve success rates:

try {
    long start = System.currentTimeMillis();
    while (true) {
        String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
        if ("OK".equals(result)) {
            // critical section
            return true;
        }
        if (System.currentTimeMillis() - start >= timeout) {
            return false;
        }
        Thread.sleep(50);
    }
} finally {
    unlock(lockKey, requestId);
}

5. Lock Re‑entrancy

Recursive methods that acquire the same lock multiple times will fail on the second acquisition. Use a re‑entrant lock provided by Redisson:

RLock lock = redisson.getLock(lockKey);
lock.lock(5, TimeUnit.SECONDS);
// ... recursive calls ...
lock.unlock();

6. Lock Competition

To reduce contention, consider read‑write locks and lock segmentation. Redisson offers RReadWriteLock for shared reads and exclusive writes:

RReadWriteLock rwLock = redisson.getReadWriteLock("readWriteLock");
RLock rLock = rwLock.readLock();
RLock wLock = rwLock.writeLock();
// use rLock.lock() for reads, wLock.lock() for writes

Lock segmentation (e.g., sharding a large lock into 100 smaller locks) can also improve throughput in high‑concurrency scenarios such as inventory deduction.

7. Lock Timeout

If a lock expires while business logic is still running, subsequent code executes without protection. Automatic lock renewal (watch‑dog) solves this, either via Redisson’s built‑in feature or a custom TimerTask that periodically extends the TTL:

Timer timer = new Timer();
timer.schedule(new TimerTask() {
    @Override
    public void run() {
        // extend lock TTL
    }
}, 10000, TimeUnit.MILLISECONDS);

8. Master‑Slave Replication Issues

In a master‑slave setup, if the master crashes after a lock is acquired but before replication, the lock may be lost, causing other nodes to acquire the same lock. Redisson’s RedissonRedLock implements the Redlock algorithm across multiple independent Redis instances to mitigate this risk.

Overall, while Redis distributed locks are powerful, developers must handle atomicity, proper release, re‑entrancy, contention, timeout renewal, and multi‑node consistency to avoid the common pitfalls described above.