Synchronized和ReentrantLock的区别

最新推荐文章于 2024-08-14 17:03:12 发布

浮华饰浮华

最新推荐文章于 2024-08-14 17:03:12 发布

阅读量2.5k

点赞数 1

分类专栏：多线程文章标签： synchronized 多线程 ReentrantLock

本文链接：https://blog.csdn.net/qq_33300026/article/details/79235017

版权

多线程专栏收录该内容

5 篇文章 0 订阅

订阅专栏

Synchronized和ReentrantLock关键字,都可以保证多线程下数据的一致性,但是他们的实现方式却是不同的?那么是怎么样的呢?现在来逐一分析一下咯!

Synchronized

synchronized是我们在多线程环境下首选的同步方案,也是使用得最多的同步方案.他的实现是基于jvm的两个字节码指令,分别是monitorenter和monitorexit,这两个字节码都需要一个reference类型的参数来指明要锁定和解锁的对象.如果Java程序明确了这个对象,那么就是这个对象的reference,如果没有确定,那就根据synchronized修饰的是实例方法还是类方法,去取对应的对象实例或者Class对象来作为锁对象.

执行原理:根据jvm规范要求,在执行monitorenter指令时,首先要尝试获取对象的锁.如果这个对象没有被锁定,或者当前线程已经拥有了那个对象的锁,把锁的计数器加1,相应的,执行monitorexit指令时会将锁计数器减1,当计数器为0时,锁就被释放.如果获取对象锁失败,那当前线程就要阻塞等待,直到对象锁被另外一个线程释放为止.

悲观锁--synchronized.在Java语言中,线程是映射到操作系统的原生线程之上的,如果要阻塞或唤醒一个线程,都需要操作系统来帮忙完成,这就需要从用户态转换到核心态,因此状态的转换需要耗费很多的处理器时间.对于代码简单的同步块(例如被synchronized修饰的setter()和getter()方法),状态转换消耗的时间有可能比用户代码执行的时间还要长.所以synchronized是java语言中一个重量级的操作.相对悲观锁的存在,还有一种乐观锁--CAS,我在后面分享.

ReentrantLock

相对于synchronized表现为原生语法层面的互斥锁,ReentrantLocl表现为API层面的互斥锁(lock和unlock方法配合try/finally语句块来完成).ReentrantLock增加了一些更为高级的功能:等待可中断,可实现公平锁,以及锁可绑定多个条件;

等待可中断是指当持有锁的线程长时间不释放锁的时候,正在等待的线程可以选择放弃等待,改为处理其他事情,可中断特性对于处理时间非常长的同步块很有帮助.

可实现公平锁是指可以根据申请锁对象的时间顺序来获取锁对象.synchronized是非公平的,ReentrantLock默认也是非公平的,可以通过带布尔值的构造函数来要求使用公平锁.

锁绑定多个条件是指一个ReentrantLock对象可以同时绑定多个Condition对象.如果synchronized要实现多个条件就必须多加一个锁,而ReentrantLock只需要多次调用newCondition()方法即可.

Condition的特性:

1.Condition中的await()方法相当于Object的wait()方法，Condition中的signal()方法相当于Object的notify()方法，Condition中的signalAll()相当于Object的notifyAll()方法。不同的是，Object中的这些方法是和同步锁捆绑使用的；而Condition是需要与互斥锁/共享锁捆绑使用的。

2.Condition它更强大的地方在于：能够更加精细的控制多线程的休眠与唤醒。对于同一个锁，我们可以创建多个Condition，在不同的情况下使用不同的Condition。

　　　　例如，假如多线程读/写同一个缓冲区：当向缓冲区中写入数据之后，唤醒"读线程"；当从缓冲区读出数据之后，唤醒"写线程"；并且当缓冲区满的时候，"写

线程"需要等待；当缓冲区为空时，"读线程"需要等待。

　　　　如果采用Object类中的wait(), notify(), notifyAll()实现该缓冲区，当向缓冲区写入数据之后需要唤醒"读线程"时，不可能通过notify()或notifyAll()明确的指

定唤醒"读线程"，而只能通过notifyAll唤醒所有线程(但是notifyAll无法区分唤醒的线程是读线程，还是写线程)。但是，通过Condition，就能明确的指定唤醒读线程。

不加锁: