有些事不是看到了希望才去坚持，而是因为坚持才会看到希望。

——《十宗罪》

• 高频必问源码面试点，重要性不言而喻。
  

  Q：来介绍下ReentrantLock吧？

  > 老问题了。回答都是固定的。

具有与使用 synchronized 方法和语句访问的隐式监视器锁相同的基本行为和语义的可重入互斥锁，但具有扩展功能。

> 点明该类与synchronized生来不同。

ReentrantLock 由最后成功加锁但尚未解锁的线程所拥有。当该锁没有被其它线程获取时，调用该锁的线程将成功获取。如果当前线程已经拥有该锁，则该方法将立即返回。
可以使用

• isHeldByCurrentThread
  返回当前线程是否持有该锁
  
• getHoldCount
  返回当前线程对该锁的持有次数；如果当前线程未持有此锁，则为0
  

方法进行检查。

此类的构造方法接受一个可选的 fair 参数。
设置为true时，在争用下，锁倾向于授予给等待时间最长的线程。否则，此锁不能保证任何特定的访问顺序。使用多线程访问的公平锁的程序可能会比

• 使用默认设置
  

的程序呈现较低的总吞吐量（即较慢；而且通常要慢得多），但获得锁和保证没有饥饿的时间差异较小。但是请注意，锁的公平性并不能保证线程调度的公平性。因此，使用公平锁的多个线程之一可能会连续多次获得它，而其他活动线程没有进行且当前未持有该锁。还要注意，未定时的 tryLock 方法不支持公平性设置。如果锁可用，即使其他线程正在等待，它将成功。

最佳实践

始终立即在调用后使用try块进行锁定，最常见的是在构造之前