腾讯后端一面：如果需要实现一个分布式锁，你该如何实现？
分布式锁
如果让你来实现一个分布式锁，该如何实现？
实现分布式锁的话，肯定需要一个地方去存储锁的信息，可以选择 Redis 或者 Zookeeper 来存储，这样所有的节点都可以感知到分布式锁的存在，达到多个节点互斥的效果
一般使用中，就是基于 Redis 或者 ZooKeeper 的分布式锁使用的比较多，这里说一下基于 Redis 如何实现一个分布式锁（也就是 Redis 的客户端工具 Redisson 如何实现的分布式锁）
首先，锁信息存在 Redis 中，要可以看得出来是哪个应用中的哪个线程持有的这把锁，这样是为了之后可以进行 重入锁 的操作，基于这样的考虑，在 Redis 中使用哈希结构来存储，如下：
json
"11_come": {
ffa56698-e0f7-4412-ad5a-00669156d187:1: 1
}-
11_come：哈希结构的名称，也就是我们加的分布式锁的 Name -
ffa56698-e0f7-4412-ad5a-00669156d187:1:：持有锁的线程的唯一标识，由threadId标识，但是多个应用的threadId可能重复，因此前边再加上一个UUID，即组成为：UUID + threadId，这样就可以保证每个线程的标识都是唯一的，这个UUID需要存储下来，因为要保证同一个线程来获取锁的时候拿到的 UUID 都是相同的，这样才可以进行 锁的重入 -
1：哈希结构中，后边的 1 表示当前线程的重入次数
这样锁的存储就已经实现好了
如果多个应用同时去加锁，如果一起查询，锁结构并不存在，因此同时去加锁，这样会不会存在问题？
这里面试官问的意思就是如何去保证多个应用去同时加锁，判断锁结构是否存在以及加锁的操作如何保证原子性
可以通过 lua 脚本来保证这一系列操作的原子性，通过 lua 脚本可以保证命令执行的 原子性 ，即 Redis 在执行 lua 脚本时，不会被其他操作打断
锁的过期时间如何设置呢？
如果加锁的时候，指定了过期时间，就使用指定的时间，如果没有指定，就给一个默认的过期时间，可以设置 30s
会不会导致用户还没有执行完，锁就已经被释放了？
不会的，因为还有一个后台任务去进行一个 锁续期 的操作，比如过期时间为 30s，那么就在 1/3 的时间（10s）之后，就去判断用户线程是否还在执行任务，如果还在执行的话，就去进行一个锁续期的动作，即将锁的过期时间重置为 30s
如何去判断用户线程是否还在执行任务？
这个后台任务是在加锁的时候去启动的，其实就是一个延时任务，延时 10s 的时间去进行锁续期的操作，在执行完锁续期操作执行，再次去启动这个延时任务，进行下一次的锁续期操作
那么如果加锁的这个用户线程已经执行完毕之后，就不会去执行这个延时任务了，当然也就不会进行锁续期操作了
如果在高并发的场景下，用户加锁的机器宕机了，会导致其他线程一直拿不到锁，这个该如何去解决？
面试官问的意思是，想要如何在用户宕机之后，怎么去知道这个用户所在的机器宕机了，主动的去释放掉这个锁
我先回答的是每个锁有一个超时时间，超过这个时间锁就会被释放掉了，但是面试官说默认的超时时间 30s 太长了，在海量任务的场景下会将其他请求都阻塞 30s，这样是不可以接受的
之后我说，那就要感知到这个进程节点是否还存活，可以将这个线程注册一个节点到 ZooKeeper 中，注册为 临时节点 ，当这个机器宕机，线程也就没了，ZooKeeper 中的临时节点就会消失，当监听到这个节点消失，就可以去 Redis 中将这个节点的锁给主动删除掉
如果线程在获取锁之后，一直得不到调度，那么这个线程就不会进行锁续期，导致锁过期了该怎么办？
这个我说的是将执行锁续期的时间点放的靠前一些
因为这个线程可能暂时得不到调度，但是后边迟早要得到调度，因此锁续期的时间点在过期时间的 1/3 处，也就是过期时间为 30s，那么当过了 10s 之后就来执行锁续期的这个操作，而不是等到第 28、29 秒的时候再来执行锁续期，这样可能导致线程没有得到调度，没来得及执行锁续期，锁就已经过期了，但是这个线程的任务还没有执行完毕
如果进程并没有挂掉，而是线程出现问题，比如抢占不到 CPU 资源，此时去监听这个进程是否挂掉就没有用了，该怎么办？
这里问的是，上边我说将线程节点作为临时节点注册到 ZooKeeper 中，但是如果进程没挂，而是线程得不到 CPU 调度，那通过这种方式也无法感知到这个问题
我回答的是，既然要应对这种问题，就要探测这个线程是否在执行，那么就可以在加锁的用户线程中加一个发送心跳的操作，在另外一个服务中去接收这个心跳，如果在一段时间内都收不到用户线程的心跳，那么就说明这个用户线程出现问题了，一直没有得到执行，因此就可以主动的去将这个用户线程加的分布式锁给释放掉，那么这里判断线程出现问题的时间就可以设置的短一些，比如 5s 都没有收到该线程的心跳，那么就判断该线程得不到调度，出现问题，就主动去释放他的锁
面试到这里就结束了，之后出了一道算法题，实现 Compartor 排序就可以完成，比较简单
面试复盘：
问的分布式锁的最后一个问题，感觉还存在一些问题，线程得不到调度之后，我们去主动释放该线程的锁了，那么加入这个线程之后又重新被调度了，那就会出现问题了，所以在释放这个线程锁之后，还要将这个线程任务给杀掉，避免之后又重新得到调度从而出现并发安全问题
我觉得这种情况概率很低，在 Redisson 客户端中也没有进行这样的处理，如果有一些想法的话，可以在留言中指出，一起讨论一下！