synchronized：是java内置的关键字，它提供了一种独占的加锁方式。synchronized的获取和释放锁由JVM实现，用户不需要显示的释放锁，非常方便。然而synchronized也有一些问题： 当线程尝试获取锁的时候，如果获取不到锁会一直阻塞。 如果获取锁的线程进入休眠或者阻塞，除非当前线程异常，否则其他线程尝试获取锁必须一直等待。

ReentrantLock： ReentrantLock是Lock的实现类，是一个互斥的同步锁。ReentrantLock是JDK 1.5之后提供的API层面的互斥锁，需要lock()和unlock()方法配合try/finally语句块来完成，等待可中断避免，出现死锁的情况（如果别的线程正持有锁，会等待参数给定的时间，在等待的过程中，如果获取了锁定，就返回true，如果等待超时，返回false）。 

公平锁与非公平锁多个线程等待同一个锁时，必须按照申请锁的时间顺序获得锁，Synchronized锁非公平锁，ReentrantLock默认的构造函数是创建的非公平锁，可以通过参数true设为公平锁，但公平锁表现的性能不是很好。

从功能角度：ReentrantLock 比 Synchronized的同步操作更精细（因为可以像普通对象一样使用），甚至实现 Synchronized没有的高级功能。

l 等待可中断当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待,对处理执行时间非常长的同步块很有用。

l 带超时的获取锁尝试在指定的时间范围内获取锁，如果时间到了仍然无法获取则返回。

l 可以判断是否有线程在排队等待获取锁。

l 可以响应中断请求与Synchronized不同，当获取到锁的线程被中断时,能够响应中断,中断异常将会被抛出,同时锁会被释放。

l 可以实现公平锁。

从锁释放角度： Synchronized在JVM层面上实现的，不但可以通过一些监控工具监控 Synchronized的锁定，而且在代码执行出现异常时，JVM会自动释放锁定，但是使用Lock则不行，Lock是通过代码实现的，要保证锁定一定会被释放，就必须将 unLock()放到 finally{}中

从性能角度：Synchronized早期实现比较低效，对比 ReentrantLock，大多数场景性能都相差较大。但是在Java6中对其进行了非常多的改进：

l 在竞争不激烈时：Synchronized的性能要优于 ReetrantLock

l 在高竞争情况下：Synchronized的性能会下降几十倍,但是 ReetrantLock的性能能维持常态。

Synchronized和ReentrantLock的异同？java面试基本问题。关注成都Java培训机构，带你了解更多相关问题。