qq_53999369的博客

而在m2里有尝试获取锁，在m1调用m2，所以他们是在一个线程里，一个线程两次的来获取锁，这就是锁的重入。刚才解决了我们自定义redis分布式锁的不可重入问题，但是还存在着锁时不可重试的，而且超时释放的隐患也没能得到解决，最后就是主从一致性的问题。我们源码里面的tryLock时可以提供参数的，在给定的参数时间内如果没有获取到锁时可以不停的重新尝试获取锁，成功与否返回true和false。，这个thread1也就是锁的标识，其目的就是将来在释放锁时会判断避免误删，只有锁时自己的才会去删除。

这时候如果锁时不可重入的，那么在a()里获取的锁，在b()时又想获取这把锁，显然是无法获取的，所以这时候就回去等待a()锁的释放，而锁时无法释放的，于是就会出现死锁。虽然这些问题多多少少都存在隐患，但是概率小到可以忽略不计，自己去实现代价太多，但是不实现心里总不踏实，所以我们来找找有没有什么成熟的框架可以让我们直接调用。这是一个风险，但是如果设置的太长，万一出现了故障，在很长的一段时间里都要等待这个锁的释放，这样的锁的阻塞周期就过长。所以这个超时释放问题还是要解决，如果这个时间设置的太短，

单体架构上，乐观锁和悲观锁可以锁住并发情况下的同步代码块，我们多使用synchronized来对方法加锁。但是在配上负载均衡的集群模式下，普通的synchronized是无法锁住从两台服务器同时进入的请求。JVM内部的锁监视器直接作废。所以锁的监视器一定要在JVM的外部，让所有JVM都去找独一无二的锁监视器来获取锁，这样也就只有一个线程获取锁，也就实现了多JVM的线程互斥。分布式锁核心是实现多进程之间的互斥，而满足这一点的方式有很多，常见的有三种：Mysql、Redis。