【多线程】：Synchronized和ReentrantLock的对比

相同点：

　　两者都是可重入锁，同一个线程每进入一次，锁的计数器都自增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更方便快捷，且不容易出错。