【Java基础】Java中synchronized锁和lock锁的比较

转载仅供学习，原文来自：https://baijiahao.baidu.com/s?id=1664090632564134140&wfr=spider&for=pc

 

Table of Contents

一：底层实现不同

二：使用方式不同

三：等待是否可中断

四：加锁的时候是否可以公平

五：锁绑定多个条件来condition

 六：从性能比较

---

在面试的过程中有可能会问到：

在Java并发编程中，隐式锁和显示锁分别是什么？两者的区别是什么？

所谓的显式锁和隐式锁的区别也就是说说Synchronized(下文简称：sync)和lock(下文就用ReentrantLock来代之lock)的区别。

 

Java中隐式锁：synchronized；显式锁：lock

sync和lock的区别

一：底层实现不同

Sync:Java中的关键字，是由JVM来维护的。是JVM层面的锁。

Lock：是JDK5以后才出现的具体的类。使用lock是调用对应的API，是API层面的锁。

 

sync是底层是通过monitorenter进行加锁（底层是通过monitor对象来完成的，其中的wait/notify等方法也是依赖于monitor对象的。只有在同步块或者是同步方法中才可以调用wait/notify等方法的。因为只有在同步块或者是同步方法中，JVM才会调用monitory对象的）；通过monitorexit来退出锁的。

 

 

lock是通过调用对应的API方法，通过AQS(AbstractQueuedSynchronizer) +LockSupport来实现锁的请求和释放。

请求锁时，先检查是否可以直接获取锁，若不能则通过AQS排队，使用LockSupport.park方法来阻塞线程。

释放锁时，先检查AQS队列获取需要唤醒的对象，然后通过LockSupport.unpark来唤醒对象。

详情查看ReentrantLock源码分析：https://blog.csdn.net/adorechen/article/details/107919256

 

 

二：使用方式不同

Sync是隐式锁。Lock是显示锁

所谓的显示和隐式就是在使用的时候，使用者要不要手动写代码去获取锁和释放锁的操作。

我们大家都知道，在使用sync关键字的时候，我们使用者根本不用写其他的代码，然后程序就能够获取锁和释放锁了。那是因为当sync代码块执行完成之后，系统会自动的让程序释放占用的锁。Sync是由系统维护的，如果非逻辑问题的话话，是不会出现死锁的。

在使用lock的时候，我们使用者需要手动的获取和释放锁。如果没有释放锁，就有可能导致出现死锁的现象。手动获取锁方法：lock.lock()。释放锁：unlock方法。需要配合tyr/finaly语句块来完成。

两者用法对比如下：

 

三：等待是否可中断

Sync是不可中断的。除非抛出异常或者正常运行完成

Lock可以中断的。中断方式：

1：调用设置超时方法tryLock(long timeout ,timeUnit unit)

2：调用lockInterruptibly()放到代码块中，然后调用interrupt()方法可以中断

 

四：加锁的时候是否可以公平

Sync;非公平锁

lock：两者都可以的。默认是非公平锁。在其构造方法的时候可以传入Boolean值。

true：公平锁

false：非公平锁

Lock的公平锁和非公平锁：

 

五：锁绑定多个条件来condition

Sync:没有。要么随机唤醒一个线程；要么是唤醒所有等待的线程。

Lock:用来实现分组唤醒需要唤醒的线程，可以精确的唤醒，而不是像sync那样，不能精确唤醒线程。

 

 六：从性能比较

全网扒了下Java锁的性能测试基准。比较靠谱的文章如下：

https://blog.csdn.net/wanghao112956/article/details/96835726  【2019-07-22， JDK8】

仅引用increment操作下的结果，无论是写多还是读多场景下，都是ReentrantLock操作占优势。

 

另外一篇测试文章：https://blog.csdn.net/weixin_34392843/article/details/85653584

这个仅测试的全部写入的情况，也是ReentrantLock占优势。

 

参考文章：

https://baijiahao.baidu.com/s?id=1664090632564134140&wfr=spider&for=pc

https://blog.csdn.net/wanghao112956/article/details/96835726 

https://blog.csdn.net/weixin_34392843/article/details/85653584