ReentraantLock是通过一个FIFO的等待队列来管理获取该锁所有线程的。在“公平锁”的机制下，线程依次排队获取锁（先等待的线程先获得锁）；而“非公平锁”在锁是可获取状态时，不管自己是不是在队列的开头都会获取锁。
ReentrantLock和synchronized的相同点
①ReentrantLock和synchronized一样都具有可重入性
ReentrantLock和synchronized的不同点
①性能方面
在Synchronized优化以前，synchronized的性能是比ReenTrantLock差很多的，但是自从Synchronized引入了偏向锁，轻量级锁（自旋锁）后，两者的性能就差不多了，在两种方法都可用的情况下，官方甚至建议使用synchronized
②使用时的区别
Synchronized的使用比较方便简洁，并且由编译器去保证锁的加锁和释放，而ReenTrantLock需要手工声明来加锁和释放锁，为了避免忘记手工释放锁造成死锁，所以最好在finally中声明释放锁。所以锁的细粒度和灵活度：很明显ReenTrantLock优于Synchronized
③ReenTrantLock独有的能力
（1）synchronized的锁是非公平锁。ReentrantLock默认情况下也是非公平锁，但可以通过带布尔值的构造函数要求使用公平锁。new RenentrantLock(boolean fair)
（2）等待可中断（等待可中断是指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情。可等待特性对处理执行时间非常长的同步块很有帮助。）
使用synchronized。如果Thread1不释放，Thread2将一直等待，不能被中断。使用ReentrantLock。如果Thread1不释放，Thread2等待了很长时间以后，可以中断等待，转而去做别的事情。
