这里有三个参数：
- waitTime：等待时间
- leaseTime：超时施放时间
- TimeUnit：时间单位
等待时间
如果 ABC… 多个线程去抢夺一把锁，A 成功了，如果设置的是 -1，那么 BCD... 就不等待，直接返回失败，也就是不再去抢夺锁了，一次失败，直接放弃。
如果不是 -1，假如说是 10（单位是秒）那么 BCD… 失败后会择机再次去抢夺，这里的择机抢夺，就代表着不是与 A 抢夺失败后的立马再次抢夺，因为（明知道 A 抢过锁之后会执行自己的业务，需要一定的时间，那么 BCD... 立马再去抢夺锁的意义在哪里呢？ 除了徒增 CPU 的负担，没有太大意义）所以这里的择机抢夺，其实是利用了 发布 - 订阅机制。
从上面的图片可以看到，A 抢过锁之后，执行业务，结束之后释放锁，释放锁的时候还 publish （发布）了一个信号，而有人发布，就有人订阅，发布人是 A，订阅人是 BCD… 所以说这里的择机再次抢夺是在 BCD… 接收到 A 发布的消息之后再去抢夺。
当然了，从第一次与 A 抢夺失败，到等待 A 完成业务发布消息这段等待时间 + 第一次和 A 抢夺锁的时间 总数不能超过 10s，毕竟 10s 就是硬性规定，10s 之内，不论发生多么复杂的逻辑，只要拿到锁就行，不行就直接放弃。
超时施放时间
就是说 A 拿到了锁之后， 如果发生了一些异常错误，内部业务没能正常的执行，没能正常执行释放锁的操作，这个时候 这个超时施放时间才会起作用，也就是说，在 A 抢到锁之后，即便 A 的业务出现了堵塞，但是只要没发生一些异常情况，这里的超时施放时间是不起作用的，因为只要不发生异常，内部就会有一个 看门狗，每隔超时施放时间/3就会刷新一次锁的过期时间（是一个定时任务），确保 A 能够执行完成业务，当然，A 执行完业务后，会删除刷新有效期的定时任务。所以说，超时释放时间在正常执行业务的时候，是不发挥作用的，只在出现异常的时候才会起作用。
