概述
这是一个比较经典的问题，在面试和工作中也是常常会涉及到，所以今天我把它们的区别和相应的应用场景说明一下。
介绍
Synchronized是Java语言的关键字，可以在方法、代码块、对象等进行加锁，当它锁定的时候，同一时刻最多只有一个线程执行这段代码。
ReentrantLock实现了JUC中的Lock，Lock 框架是锁定的一个抽象，它允许把锁定的实现作为 Java 类，而不是作为语言的特性来实现。
两者对比
性能
在JDK1.6以前Synchronized要比ReentrantLock性能差能多，但在JDK1.6之后引入了偏向锁、轻量级锁（自旋锁）、锁升级机制等在性能上ReentrantLock并没有太大的优势。
如果两种都可用的情况下，甚至官方也给出优先使用Synchronized的建议。
其实Synchronized的优化借鉴了ReentrantLock中的CAS技术。尝试在用户态时把加锁问题解决，从而避免进入内核态的线程阻塞。
因为Synchronized使用简单，ReentrantLock虽然操作灵活，但是如果没有对锁进行释放，很容易造成死锁现象，所以如果对性能上没有极致的要求还是优先使用简单方便的Synchronized来解决并发。
重入性
我们从字面意思上就能看出(Reentrant)可重入的意思，其实它也就是可重入锁，Synchronized也是具有可重入性，它也是可重入锁。
具体的实现原理也都是当前同一线程进入一次锁计数器进行+1，当锁计数器为0时锁释放。
锁实现
Synchronized java的关键字，它的锁机制是依赖jvm实现的，是原生语法层面上的互斥，最底层是mutex。
而ReentrantLock则是通过提供的api层面的锁，需要在代码中显示调用lock、unlock等方法来完成。
直白的说就是Synchronized 由jvm调用操作系统控制而ReentrantLock则是由用户自己编写代码来控制。
ReentrantLock特性
公平锁/非公平锁
ReenTrantLock可以指定是公平锁还是是非公平锁。而synchronized只能是非公平锁，因为它不能像ReentrantLock是通过AQS（自旋锁）来实现线程调度。
[if !supportLists]l [endif]公平锁：多个线程根据申请锁的顺序来获取锁。
[if !supportLists]l [endif]非公平锁：多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能，会造成优先级反转或者饥饿现象，但优点在于吞吐量比公平锁大。
可中断锁等候
持有锁的线程长期不释放的时候，正在等待的线程可以选择放弃等待，这相当于Synchronized来说可以避免出现死锁的情况。通过lock.lockInterruptibly()来实现这个机制。
锁绑定多个条件
一个ReentrantLock对象可以同时绑定对个对象。ReenTrantLock提供了一个Condition（条件）类，用来实现分组唤醒需要唤醒的线程们，而不是像Synchronized要么随机唤醒一个线程要么唤醒全部线程。
使用场景
如果在使用的场景中没有涉及到ReentrantLock独有的特性时，都建议使用Synchronized。
结论
虽然ReentrantLock能够实现比Synchronized更细粒度的控制，也有一些针对使用 ReentrantLock “性能会更好”的说法，但其实我们在开发的过程中，还是要更多的去注意是否够用，是否做好了，之后我们再去考虑是否有必要去提升那点性能，再说前面也有提到JDK1.6之后Synchronized的效率并不比ReentrantLock要低，所以我们更加有理由去选择简单易懂的方法用Synchronized来解决并发。
