java乐观锁与悲观锁

 jdk1.5之前,同步中一直使用的就是悲观锁,也就是synchronized,不过这个锁不能满足某些性能上的需要,原因在于

         在使用悲观锁时,加锁与解锁操作消耗较多的资源,并且未竞争到锁的线程被挂起,线程的挂起与唤醒操作同样消耗资源,对一些追求响应时间或者同步代码块执行时间短的情况,使用悲观锁就会很尴尬。

     可能也是因为这个原因,synchronized关键字声明的锁也叫重量级锁。

为了解决这个问题,jdk1.6后就可以针对这种情况使用乐观锁,乐观锁的实现机制就是cascompare and swap),为什么乐观锁可以克服上面提到的那些缺点呢;

  上边提到,悲观锁是假设我在同步区工作时一定会有冲突,所以我要把同步资源完全的锁起来,导致性能低下,而乐观锁不同,乐观锁假设同步工作区很少有冲突,或者说同步区没有冲突,线程去访问同步资源,如果同步操作失败,那么重试直到成功为止。在这里,重试这个动作是不断进行的,也就是说线程没有被挂起,而是进入了一个自旋状态(因此这种锁也叫自旋锁),线程忙等,不肯放弃自己的时间片,而是以一种轮询的方式(个人理解)不断测试锁的状态,直到获取成功。

    那么问题来了,乐观锁一直轮询,不会消耗大量cpu资源吗?不会,不要忘记使用乐观锁的前提是追求响应时间或者同步代码块执行时间很短的情况,冲突很少,即使遇到了冲突,另一个线程也会很快执行完并且释放锁,乐观锁不会让线程等太久的。

那么得出一个结论,锁的选择要分情况而定,一般追求吞吐量,同步代码块执行时间很长要使用重量级锁,也就是悲观锁,追求相应时间,同步代码块执行时间短的选用轻量级锁,也就是乐观锁。


  • 3
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 4
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值