ReentrantLock与synchronized区别之比较（面试）

背景：

我们Java开发中需要保证数据线程安全时有多重选择，直接使用线程安全的集合类，或者某些变量我们通过ReentrantLock来保证安全，或者使用synchronized关键字，那两者有何区别？

备注：

ReentrantLock和synchronized关键字在服务部署多个副本时，无法在多个副本之间实现分布式锁，这时建议使用Redis或者Zookeeper提供分布式锁，其中redis使用redisson会更加便捷，并且redisson除了提供分布式锁外，还提供队列集合等

官方文档：https://docs.oracle.com/javase/tutorial/essential/concurrency/locksync.html

分析

1，相似点：

这两种同步方式有很多相似之处，它们都是加锁方式同步，而且都是阻塞式的同步，也就是说当如果一个线程获得了对象锁，进入了同步块，其他访问该同步块的线程都必须阻塞在同步块外面等待，而进行线程阻塞和唤醒的代价是比较高的（操作系统需要在用户态与内核态之间来回切换，代价很高，不过可以通过对锁优化进行改善）。

2，功能区别：

两种方式最大区别就是synchronized是java语言的关键字，是原生语法层面的互斥，是jvm实现的。而ReentrantLock它是JDK 1.5之后提供的API层面的互斥锁，需要lock()和unlock()方法配合try/finally语句块来完成

便利性：很明显，synchronized的使用比较方便简洁，并且由编译器去保证锁的加锁和释放，而ReentrantLock需要代码主动调用lock/unlock来加锁和释放锁，为了避免忘记异常时或者忘记释放锁，强烈建议在finally中声明释放锁。以免没有释放释放锁造成DeadLock，

 class X {
   private final ReentrantLock lock = new ReentrantLock();
   // ...

   public void m() {
     lock.lock();  // block until condition holds
     try {
       // ... method body
     } finally {
       lock.unlock();
     }
   }
 }

锁的细粒度和灵活度：很明显ReentrantLock优于synchronized
Synchronized可以对方法，代码块进行同步，实现实例级别，类级别的同步
lock可以根据需要对具体需要同步的变量在改变和读取的部分进行加锁和解锁。 lock种类多，例如有ReentrantLock，ReentrantReadWriteLock。

备注：StampedLock 不是可重入的

由于ReentrantLock是java.util.concurrent包下提供的一套互斥锁，相比synchronized，ReentrantLock类提供了一些高级功能，主要有以下3项：

1.等待可中断

持有锁的线程长期不释放的时候，正在等待的线程可以选择放弃等待，这相当于Synchronized来说可以避免出现死锁的情况。通过lock.lockInterruptibly()来实现这个机制。

2.公平锁

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

3.锁绑定多个条件

一个ReentrantLock对象可以同时绑定多个对象。ReentrantLock提供了一个Condition（条件）类，用来实现分组唤醒需要唤醒的线程们，而不是像synchronized要么随机唤醒一个线程要么唤醒全部线程。

创建公平/非公平锁

    /**
     * Creates an instance of {@code ReentrantLock} with the
     * given fairness policy.
     *
     * @param fair {@code true} if this lock should use a fair ordering policy
     */
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }

3，性能的区别：

在synchronized优化前，synchronized的性能是比ReentrantLock差很多的，但是自从synchronized引入了偏向锁、轻量级锁（自旋锁）后，两者的性能就差不多了，在两种方法都可用的情况下，官方甚至建议使用synchronized。

研究发现锁在大多数情况下不存在多线程竞争情况，总是由同一个线程多次获得。在对象的mark word中进行记录，获取锁的时候先测试是否是偏向锁，

JVM会再当前线程的栈帧中创建用于存储锁记录的空间，并将对象头中的mark word复制到锁记录中，官方称为displaced mark word。 线程尝试使用cas将对象头中的mark word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示其他线程在竞争，当前线程使用自旋锁来获取锁。轻量级锁会自动升级额重量级锁，

synchronized
synchronized关键字经过编译之后，会在同步块的前后分别形成monitorenter和monitorexit两个字节码指令。在执行monitorenter指令时，首先要尝试获取对象锁。如果这个对象没被锁定，或者当前线程已经拥有了那个对象锁，把锁的计数器加1，相应的，在执行monitorexit指令时会将锁计数器减1，当计数器为0时，锁就被释放了。如果获取对象锁失败，那当前线程就要阻塞，直到对象锁被另一个线程释放为止。
monitorexit会插入到方法结束， 异常时也会释放。
synchronized是可重入的，不会出现同一个线程调用的多个方法或者代码块有synchronized自己被自己锁死的状况。

比较表 1

比较项	Lock	synchronized
锁的获取与释放方式	必须手动管理锁的获取与释放。通常在try/finally中使用，如lock.lock()获取锁，lock.unlock()释放锁	Java虚拟机自动管理锁的获取与释放。当进入syncronized修饰的方法或代码块时，自动获取锁；当退出syncronized修饰的方法或代码块或者异常时，自动释放锁。
是否可中断	可中断。如果线程正在等待锁，那么可以被中断，此功能由lock.lockInterruptibly()提供。	不可中断。一旦线程开始等待获取锁，并不能被中断
公平性	默认非公平锁，但可配置为公平锁。如果设置为公平锁，则按照线程等待的顺序来获取锁	非公平锁。它无法保证等待的线程获取锁的顺序。
其他	lock可以创建Condition	无其他功能