ReentrantLock与synchronized对比

1.可重入性

    ReentrantLock和synchronized都具有可重入性，写代码synchronized更简单，ReentrantLock需要将lock()和unlock()进行一一对应否则有死锁的风险，一般和try,finally配置使用

        ReentrantLock reentrantLock = new ReentrantLock(false);
        reentrantLock.lock();
        try {

        } finally {
            reentrantLock.unlock();
        }

      重入就是一个线程获取锁之后，该还可以重复加锁。

      

2.锁的实现方式

Synchronized作为Java关键字是依赖于JVM实现的，而ReenTrantLock是JDK实现的，有什么区别，说白了就类似于操作系统来控制实现和用户自己敲代码实现的区别。

3.公平性

ReentrantLock提供了公平锁和非公平锁两种API，开发人员完全可以根据应用场景选择锁的公平性；
synchronized是作为Java关键字是依赖于JVM实现，Java团队应该是优先考虑性能问题，因此synchronized是非公平锁。

4.二者性能和粒度

Java一直被诟病的就是性能问题，所以这是一个很重要的问题。
在Synchronized优化以前，synchronized的性能是比ReenTrantLock差很多的，但是自从Synchronized引入了偏向锁，轻量级锁（自旋锁）后，两者的性能就差不多了，在两种方法都可用的情况下，官方甚至建议使用synchronized，其实synchronized的优化我感觉就借鉴了ReenTrantLock中的CAS技术。都是试图在用户态就把加锁问题解决，避免进入内核态的线程阻塞；

至于二者的细粒度差别就更明显了，Synchronized只是关键字，而ReentrantLock则提供较为多样的实现方式和更多的功能；

5.编程灵活度和难度

根据上面的介绍估计这个问题已近很明确了；
很明显Synchronized的使用比较方便简洁，并且由编译器去保证锁的加锁和释放，而ReenTrantLock需要手工声明来加锁和释放锁，为了避免忘记手工释放锁造成死锁，所以最好在finally中声明释放锁。其中ReenTrantLock使用不当死锁问题更是让人头痛不已。
灵活度：很明显ReentrantLock优于synchronized；
难度：也很明显ReentrantLock难于synchronized；