单点应用下,并发场景相对还比较好控制,可以借助java.util下的并发包工具能够解决大部分问题。但是在多节点分布式场景下，java.util.locks.ReentrantLock可能就并不能发挥多大作用了,此时我们需要借助分布式锁来控制并发。

解决思路

分布式场景下之所以不能够使用并发包下的锁解决并发问题，那是因为多节点是每个应用都有相互独立的进程,他们没有共享内存资源内存因此很难控制并发。要想控制分布式应用并发问题：

1、内存共享(同一台数据库服务器mysql、同一台缓存数据库memcached/redis)
2、彼此进行消息通信/彼此可见(zookeeper)

备注：其实分布式问题最终都要把它简化成单点问题来解决。

在实际应用中，我们需要的分布式锁应该是什么样的呢？

1、可以保证在分布式部署的应用集群中，同一个方法/资源在同一时间只能被一台机器上的一个线程执行/占用；
2、这把锁要是一把可重入锁（避免死锁）；
3、这把锁最好是一把阻塞锁（根据业务需要考虑要不要这条）；
4、有高可用的获取锁和释放锁功能；
5、获取锁和释放锁的性能要好；

补充一点：可重入锁与不可重入锁

不可重入锁：

public class Lock {
        
      private boolean isLocked = false;

      //加锁
      public synchronized void tryLock() throws InterruptedException{
            if (isLocked) {
                  wait();
            }
            isLocked = true;
      }

      //释放锁
      public synchronized void unLock(){
            isLocked = false;
            notify();
      }
}

可重入锁：

public class Lock {
    

      private boolean isLocked = false;
      Thread lockBy = null;
      int lockNum = 0;

      //加锁
      public synchronized void tryLock() throws InterruptedException{
            Thread thread = Thread.currentThread();//当前线程
            while (isLocked && lockBy != thread) {
                  wait();//持有锁的线程不是当前线程的话就等待
            }
            //如果持有锁的线程是当前线程，则可以继续加锁
            isLocked = true;
            lockBy = thread;
            lockNum++;
      }

      //释放锁
      public synchronized void unLock(){

if (Thread.currentThread() == lockBy) {
   //持有锁的线程是当前线程
                  lockNum--;
                  if (lockNum == 0) {
                        isLocked = false;
                        notify();
                  }
            }
      }
}

测试程序：

public class Test {
      Lock lock = new Lock();

      public static void main(String[] args) {
          print();
      }

      public void print() throws InterruptedException{
            lock.tryLock();
            doAdd();
            lock.unLock();
      }
      public void doAdd() throws InterruptedException {
            lock.tryLock();
            //do something
            lock.unLock();
      }
}

相对来说，可重入就意味着：线程可以进入任何一个它已经拥有的锁所同步着的代码块。

不可重入锁的Lock：当调用print()方法时，获得了锁，这时就无法再调用doAdd()方法，这时必须先释放锁才能调用，所以称这种锁为不可重入锁，也叫自旋锁。

可重入锁Lock：第一个线程执行print()方法，得到了锁，使lockBy等于当前线程，也就是说，执行print()方法 的线程获得了这个锁，执行doAdd()方法时，同样要先获得锁，因不满足while循环的条件（while循环的条件 ：持有锁的线程不是当前线程），就不等待，继续执行，将此时当前获得锁的数量lockedNum变量+1。当释放了所有的锁，才执行notify()。如果在执行这个方法时，有第二个线程想要执行这个方法，因为lockBy不等于第二个线程，导致这个线程进入等待状态，不断执行wait()方法。只有当第一个线程释放了所有的锁，执行notify()方法后，第二个线程才得以跳出循环，继续执行。

针对分布式锁的实现，目前比较常用的方案有三种：

1、基于数据库实现分布式锁
http://blog.csdn.net/lmb55/article/details/78495629

2、基于缓存（Redis、memcached）实现分布式锁

相比较于基于数据库实现分布式锁的方案来说，基于缓存来实现在性能方面会表现的更好一点。而且很多缓存是可以集群部署的，可以解决单点问题。

总的来说，可以使用缓存来代替数据库来实现分布式锁，这个可以提供更好的性能，同时，很多缓存服务都是集群部署的，可以避免单点问题。并且很多缓存服务都提供了可以用来实现分布式锁的方法，比如redis的setnx方法等。并且，这些缓存服务也都提供了对数据的过期自动删除的支持，可以直接设置超时时间来控制锁的释放。不过有一点，通过超时时间来控制锁的失效时间并不是十分的靠谱。

目前有很多成熟的缓存产品，包括Redis，memcached等。请参考以下基于Redis实现的分布式锁：

http://blog.csdn.net/lmb55/article/details/78235768
http://blog.csdn.net/lmb55/article/details/78266905

3、基于Zookeeper实现分布式锁