作为关键字synchronized的替代品（或者说是增强版），重入锁是synchronized的功能扩展。在JDK 1.5的早期版本中，重入锁的性能远远好于synchronized，但从JDK 1.6开始，JDK优化了synchronized，使两者性能差距不大。重入锁使用java.util.concurrent.locks.ReentrantLock类来实现。
使用重入锁可以指定何时加锁和何时释放锁，对逻辑控制的灵活性远远好于synchronized，退出临界区时必须释放锁。之所以称为重入锁，是因为一个线程可以连续获得这种锁。
简单的重入锁使用例子如下：
修改上述代码第7-12行：
在这种情况下，一个线程连续两次获得同一把锁。如果不允许该操作，那么同一个线程在第2次请求获得锁时，会和自己产生死锁，程序卡死在第2次申请锁的过程中。如果同一个线程多次获得锁，那么释放锁的次数与其相同。如果释放锁的次数多，那么会有java.lang.IllegalMonitorStateException异常；反之，如果释放锁的次数少了，那么该线程依然持有这个锁。
除了使用上的灵活性之外，重入锁还提供了一些高级功能：
1 中断响应
对于synchronized来说，如果一个线程在等待锁，那么结果只有两种可能：要么获得这把锁继续执行，要么保持等待。而使用重入锁可以提供另外一种可能：线程可以被中断。也就是说，线程在等待锁的过程中，程序可以根据需要取消对锁的请求。例如，小王与小明一起去打球，如果小王等了10分钟，小明还没到，接到小明的电话了解到由于突发情况不能如约了，那么小王就扫兴地打道回府了。对于线程而言，如果一个线程正在等待锁，那么它可以收到一个通知，被告知无需再等待，可以停止工作了。这种情况对于处理死锁是有一定帮助的。
2 锁申请等待限时
除了等待外部通知之外，避免死锁还有另外一种方法：限时等待。继续上面的例子，如果小王等了半个小时，小明还不来，那么小王就扫兴离去了。对于线程而言，如果给定一个等待时间，让线程自动放弃，那么可以避免线程持续等待。
3 公平锁
在大多数情况下，锁的申请都是非公平的。也就是说，线程1首先申请了锁A，接着线程2也申请了锁A，那么当锁A可用时，哪个线程获得锁是不一定的，系统会从锁A的等待队列中随机选择一个，不能保证公平性。如同买票不排队，大家乱哄哄地围在售票窗口前，售票员忙得焦头烂额，顾不得谁先谁后，随便找个人出票就完事了。而公平锁保证先到先得，不会产生饥饿现象。只要排好队，最终可以获得资源。synchronized产生的锁是非公平的，而重入锁可以设置是否公平。重入锁要求系统维护一个有序队列，实现成本比较高，性能较低。所以，默认情况下的锁是非公平的。
ReentrantLock类常见方法如下：
1 public ReentrantLock(boolean fair)
当参数fair是true时，表示该重入锁是公平的。
2 lock()
获取锁，如果锁已被占用，则等待。
3 lockInterruptibly()
获取锁，但优先响应中断。
4 tryLock()
尝试获取锁，如果成功，返回true；否则，返回false。该方法不等待，立即返回。
5 tryLock(long time, TimeUnit unit)
在给定时间内尝试获取锁。
6 unlock()
释放锁。
重入锁的实现包含3个要素：
1 原子状态
原子状态使用CAS操作来存储当前锁的状态，判断锁是否已被其他线程持有。
2 等待队列
所有没有获取到锁的线程会进入等待队列进行等待。当有线程释放锁后，系统就从等待队列中唤醒一个线程，继续工作。
3 阻塞原语park()和unpark()
挂起和恢复线程，没有获取到锁的线程会被挂起。
参考资料
《实战Java高并发程序设计》 P71-80
原文地址：https://www.cnblogs.com/WJQ2017/p/8276326.html