重入锁（ReentrantLock）和synchroinzed区别

重入锁（ReentrantLock）和synchronized区别：

重入锁（ReentrantLock）完全可以替代synchronized,在jdk5.0以前，重入锁的性能远远高于synchronized，但是在jdk6.0后，synchronized上做了大量的优化，使得两者的性能差距不是很大。

区别：

1：灵活，重入锁是手动加锁，然后手动解锁。可以对一个方法叠加锁，前提是在一个线程之内，解锁的次数必须和加锁的次数一样，不然就会报java.lang.IllegalMonitorStateException异常，反之，如果解锁次数少于加锁次数，说明线程还保持着锁，其他线程就无法进入。

2：中断响应，对于synchroinzed来说，如果一个线程在等待锁，那么他的结果就只有两种，要么继续等待锁，要么获取到锁继续执行。而使用重入锁，提供了另一可能，那就是线程可以被中断，就是说线程在等待锁的过程中，可以根据需要取消对锁的获取，lock.lockInterruptibly().

3：锁申请等待时限，除了上面的外部通知外，避免死锁的另一个方法就是限制等待时间，即超过设置的时间，就取消对所的获取，lock.tryLock(number,TimeUnit.SECONDS),number单位是秒，返回值是一个boolean，true表示获取到锁，反之false。lock.tryLock也可以不带参数，在这种情况下，当前线程会尝试获取锁，如果锁获取成功则会立即返回true,反之false。

4：公平锁。在大部分情况下，锁是不公平的。比如说，线程1申请了锁A，接着线程2也申请了锁A，而当锁A可用时，到底是线程1获取了锁还是线程2就不得而知了。synchroinzed进行锁控制，就是非公平锁，重入锁默认也是非公平锁，但是它有一个构造方法允许对其公平性进行设置

public ReentrantLock(boolean fair)，当fair为true时，表示锁就是公平的。公平锁看起来很优美，但是实现公平锁就需要维护一个有序的队列，成本较高，性能相对非常低下，因此，慎用。

对上面ReentrantLock的几个重要方法整理如下：

》lock()：获得锁，如果锁已经被占用，则等待

》lockInterruptibly()：获得锁，但优先响应中断

》tryLock()：尝试获取锁，如果成功，返回true，失败返回false。改方法不等待，立即返回

》tryLock(long time,TimeUnit unit)：在给定的时间内尝试获得锁

》unLock()：释放锁