相同点：
两者都是可重入锁，同一个线程每进入一次，锁的计数器都自增1，等到锁的计数器下降为0时才能释放锁。
底层实现对比：
Synchronized是依赖于JVM实现的，而ReentrantLock是JDK实现的。
性能对比：
Synchronized优化以前，性能比ReenTrantLock差很多，但是自从Synchronized引入了偏向锁，轻量级锁（自旋锁）后，两者的性能就差不多了。
在两种方法都可用的情况下，官方甚至建议使用synchronized。
Synchronized的优化借鉴了ReentrantLock中的CAS技术。都是试图在用户态就把加锁问题解决，避免进入内核态的线程阻塞。
使用便利性对比：
Synchronized的使用比较方便简洁，并且由编译器去保证锁的加锁和释放；
而ReentrantLock需要手工声明来加锁和释放锁，为了避免忘记手工释放锁造成死锁，所以最好在finally中声明释放锁。
ReenTrantLock独有的能力：
1. ReentrantLock可以指定是公平锁还是非公平锁。而Synchronized只能是非公平锁。PS：公平锁就是先等待的线程先获得锁。
2. ReentrantLock提供了一个Condition类，用来实现分组唤醒需要唤醒的线程们，而Synchronized只能随机唤醒一个线程，或者唤醒全部线程。
3. ReentrantLock提供了一种能够中断等待锁的线程的机制，通过lock.lockInterruptibly()来实现这个机制。
总结：
ReentrantLock比Synchronized锁控制粒度更细，更底层，更灵活，但使用不当或不熟悉出错可能性更高些。所以个人觉得如果涉及上述3种特殊诉求，使用ReentrantLock，否则直接使用Synchronized更方便快捷，且不容易出错。