请你谈谈Synchronized 和 ReenTrantLock 的对比？

1 两者都是可重入锁
“可重入锁”概念是：自己可以再次获取自己的内部锁。比如一个线程获得了某个对象的锁，此时这个对象锁还没有释放，当其再次想要获取这个对象的锁的时候还是可以获取的，如果不可锁重入的话，就会造成死锁。同一个线程每次获取锁，锁的计数器都自增1，所以要等到锁的计数器下降为0时才能释放锁。

2 synchronized依赖于JVM而ReenTrantLock依赖于API
synchronized是依赖于JVM实现的，前面我们也讲到了 虚拟机团队在JDK1.6为synchronized关键字进行了很多优化，但是这些优化都是在虚拟机层面实现的，并没有直接暴露给我们。ReenTrantLock是JDK层面实现的（也就是API层面，需要lock()和unlock()方法配合try/finally语句块来完成）。

3 ReenTrantLock比synchronized增加了一些高级功能

相比synchronized，ReenTrantLock增加了一些高级功能。主要来说主要有三点：

优点	特点
等待可中断	ReenTrantLock提供了一种能够中断等待锁的线程的机制，通过lock.lockInterruptibly()来实现这个机制。也就是说正在等待的线程可以选择放弃等待，改为处理其他事情。
可实现公平锁	ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁
可实现选择性通知	如下所示

• synchronized关键字与wait()和notify()/notifyAll()方法相结合可以实现等待/通知机制；
• ReentrantLock需要借助于Condition接口与newCondition()方法；
• 一个Lock对象中可以创建多个Condition实例（即对象监视器），线程对象可以注册在指定的Condition中，从而可以有选择性的进行线程通知，在调度线程上更加灵活。
• 用ReentrantLock类结合Condition实例可以实现“选择性通知”。而synchronized关键字就相当于整个Lock对象中只有一个Condition实例，所有的线程都注册在它一个身上。如果执行notifyAll()方法的话就会通知所有处于等待状态的线程这样会造成很大的效率问题，而Condition实例的signalAll()方法只会唤醒注册在该Condition实例中的所有等待线程。