-
支持立即获取锁方式，如果获取到返回true，获取不到则返回false；
-
支持等待获取锁方式，如果获取到，直接返回true，获取不到在等待一小段时间，在这一小段时间内反复尝试，如果尝试成功，则返回true，等待时间过后还获取不到则返回false；
-
不能产生死锁的情况；
-
不能释放非自己加的锁；
下面我们用实例来演示在 Java 中利用 redis 实现分布式锁服务
加锁
通过 redis 来实现分布式锁的加锁逻辑如下所示：
jedis.select(dbIndex); String key = KEY_PRE + key; String value = fetchLockValue(); if(jedis.exists(key)){ jedis.set(key,value); jedis.expire(key,lockExpirseTime); return value; }
表面上看这段代码好像没有什么问题，实际上并不能在分布式环境中正确的实现加锁的操作。要能够正确的实现加锁操作，“判断 key 是否存在”、“保存 key-value”、“设置 key 的过期时间”这三步操作必须是原子操作。如果不是原子操作，那么可能会出现下面两种情况：
-
在“判断 key 是否存在”得出 key 不存在的结果步骤后，“保存 key-value”步骤前，另一个客户端执行同样的逻辑，并且执行到了“判断 key 是否存在”步骤，同样得出了 key 不存在的结果。这样回导致多个客户端获得了同一把锁；
-
在客户端执行完“保存 key-value” 步骤后，需要设置一个 key 的过期时间，防止客户端因为代码质量未解锁，在或者进程崩溃未解锁导致的死锁情况。在“保存 key-value”步骤之后，“设置 key 的过期时间”步骤之前，可能进程崩溃，导致“设置 key 的过期时间”步骤失败；
redis 在2.6.12版本之后，对 set 命令进行了扩充，能够规避上面的两个问题。新版的 redis set 命令的参数如下
SET key value [EX seconds] [PX milliseconds] [NX|XX]
新版的 set 命令增加了 EX 、 PX 、 NX|XX 参数选项。他们的含义如下
-
EX seconds– 设置键 key 的过期时间，单位时秒 -
PX milliseconds– 设置键 key 的过期时间，单位时毫秒 -
NX– 只有键 key 不存在的时候才会设置 key 的值 -
XX– 只有键 key 存在的时候才会设置 key 的值
这样，原来的三步操作就可以在一个 set 的原子操作里面来完成，规避了上面我们提到的两个问题。
新版的 redis 加锁核心代码修改如下所示：
jedis = redisConnection.getJedis(); jedis.select(dbIndex); String key = KEY_PRE + key; String value = fetchLockValue(); if ("OK".equals(jedis.set(key, value, "NX", "EX", lockExpirseTime))) { return value; }
解锁
解锁的基本流程如下：
根据这个逻辑，在 Java 中解锁的核心代码如下所示：
jedis.select(dbIndex); String key = KEY_PRE + key; if(jedis.exists(key) && value.equals(jedis.get(key))){ jedis.del(key); return true; } return false;
和加锁的时候一样，key 是否存在、判断是否自己持有锁、**删除 key-value **这三步操作需要是原子操作，否则当一个客户端执行完“判断是否自己持有锁”步骤后，得出自己持有锁的结论，此时锁的过期时间到了，自动被 redis 释放了，同时另一个客户端又基于这个 key 加锁成功，如果第一个客户端还继续执行删除 key-value的操作，就将不属于自己的锁给释放了。
这显然是不运行的。在这里我们利用 redis 执行 Lua 脚本的能力来解决原子操作的问题。修改后的解锁核心代码如下所示：
jedis.select(dbIndex); String key = KEY_PRE + key; String command = "if redis.call('get',KEYS[1])==ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end"; if (1L.equals(jedis.eval(command, Collections.singletonList(key), Collections.singletonList(value)))) { return true; }
另外，判断是否自己持有锁的机制是用加锁的时候的 key-value 来判断当前的 key 的值是否等于自己持有锁时获得的值。所以加锁的时候的 value 必须是一个全局唯一的字符串。
完整的代码如下所示
从测试结果来看可以看到，9个线程同时给一个 key 加锁，只有一个能够成功获取到锁，其余的客户端都无法获取到锁。