乐观锁与悲观锁的简单区分

1、锁的出现,是因为并发读写同一个数据的时候,需要进行数据完备性的保护,避免脏读、脏写等。

2、乐观锁,需要在事务中加锁,在读取数据的时候,不必在意数据是否已经被修改了(即允许脏读);但是在写入数据的时候,要检查数据是否已经被修改了(可以通过版本号等机制控制),如果被修改那么就通知事务调用者,事务失败了。

3、悲观锁,需要在事务中加锁,在读取写入数据的时候,都需要考虑数据是否已经被修改,如果被修改了,那么就通知事务调用者,事务被阻塞了,进入等待状态。

4、从性能上看,乐观锁性能会高一些,因为悲观锁要检查更多的数据变动情况,而且还会存在阻塞。

5、从使用场景上看,悲观锁一般用于要求很强的数据一致性的系统,读写都不允许“脏”,乐观锁一般用于一致性稍弱的系统,不允许脏写,但是允许脏读。

概念引申:数据库的各种锁,分布式系统的CAP原则。

时间: 2024-11-03 01:16:56

乐观锁与悲观锁的简单区分的相关文章

[数据库事务与锁]详解七: 深入理解乐观锁与悲观锁

注明: 本文转载自http://www.hollischuang.com/archives/934 在数据库的锁机制中介绍过,数据库管理系统(DBMS)中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性. 乐观并发控制(乐观锁)和悲观并发控制(悲观锁)是并发控制主要采用的技术手段. 无论是悲观锁还是乐观锁,都是人们定义出来的概念,可以认为是一种思想.其实不仅仅是关系型数据库系统中有乐观锁和悲观锁的概念,像memcache.hibernate.

Hibernate乐观锁、悲观锁和多态

 乐观锁和悲观锁 悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁.传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁. 乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等

web开发中的两把锁之数据库锁:(高并发--乐观锁、悲观锁)

这篇文章讲了 1.同步异步概念(消去很多疑惑),同步就是一件事一件事的做:sychronized就是保证线程一个一个的执行. 2.我们需要明白,锁机制有两个层面,一种是代码层次上的,如Java中的同步锁,典型的就是同步关键字synchronized ( 线    程级别的).另一个就是数据库层次上的,比较典型的就是悲观锁和乐观锁. 3.常见并发同步案例分析   附原文链接 http://www.cnblogs.com/xiohao/p/4385508.html 对于我们开发的网站,如果网站的访问

事务的乐观锁和悲观锁

Select -forupdate语句是我们经常使用手工加锁语句.通常情况下,select语句是不会对数据加锁,妨碍影响其他的DML和DDL操作.同时,在多版本一致读机制的支持下,select语句也不会被其他类型语句所阻碍. 借助for update子句,我们可以在应用程序的层面手工实现数据加锁保护操作.本篇我们就来介绍一下这个子句的用法和功能. 从for update子句的语法状态图中,我们可以看出该子句分为两个部分:加锁范围子句和加锁行为子句.下面我们分别针对两个方面的进行介绍. 加锁范围子

Yii2.0的乐观锁与悲观锁(转)

原文:Yii2.0的乐观锁与悲观锁 Web应用往往面临多用户环境,这种情况下的并发写入控制, 几乎成为每个开发人员都必须掌握的一项技能. 在并发环境下,有可能会出现脏读(Dirty Read).不可重复读(Unrepeatable Read). 幻读(Phantom Read).更新丢失(Lost update)等情况.具体的表现可以自行搜索. 为了应对这些问题,主流数据库都提供了锁机制,并引入了事务隔离级别的概念. 这里我们都不作解释了,拿这些关键词一搜,网上大把大把的. 但是,就于具体开发过

深入理解乐观锁与悲观锁

在数据库的锁机制中介绍过,数据库管理系统(DBMS)中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性. 乐观并发控制(乐观锁)和悲观并发控制(悲观锁)是并发控制主要采用的技术手段. 无论是悲观锁还是乐观锁,都是人们定义出来的概念,可以认为是一种思想.其实不仅仅是数据库系统中有乐观锁和悲观锁的概念,像memcache.hibernate.tair等都有类似的概念. 针对于不同的业务场景,应该选用不同的并发控制方式.所以,不要把乐观并发控制和悲

mysql中的乐观锁和悲观锁

mysql中的乐观锁和悲观锁的简介以及如何简单运用. 关于mysql中的乐观锁和悲观锁面试的时候被问到的概率还是比较大的. mysql的悲观锁: 其实理解起来非常简单,当数据被外界修改持保守态度,包括自身系统当前的其他事务,以及来自外部系统的事务处理,因此,在整个数据处理过程中,将数据处于锁定状态.悲观锁的实现,往往依靠数据库提供的锁机制,但是也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在自身系统中实现了加锁机制,也无法保证外部系统不会修改数据. 来点实际的,当我们使用悲观

SSM(十五) 乐观锁与悲观锁的实际应用

SSM(十五) 乐观锁与悲观锁的实际应用 前言 随着互联网的兴起,现在三高(高可用.高性能.高并发)项目是越来越流行. 本次来谈谈高并发.首先假设一个业务场景:数据库中有一条数据,需要获取到当前的值,在当前值的基础上+10,然后再更新回去.如果此时有两个线程同时并发处理,第一个线程拿到数据是10,+10=20更新回去.第二个线程原本是要在第一个线程的基础上再+20=40,结果由于并发访问取到更新前的数据为10,+20=30. 这就是典型的存在中间状态,导致数据不正确.来看以下的例子: 并发所带来

乐观锁和悲观锁 你更钟情于哪一个?

链接:http://www.csdn.net/article/2012-12-12/2812708-leguansuo-beiguansuo-couchbase :云计算 对数据库的并发访问一直是应用程序开发者需要面对的问题之一,一个好的解 决方案不仅可以提供高的可靠性还能给应用程序的性能带来提升.下面我们来看一下Couchbase产品市场经理Don Pinto结合Couchbase Server为我们带来的悲观锁和乐观锁的解析. 故事背景:Alice和Joe将共同读取Couchbase Ser

快钱支付与Sql Server的乐观锁和悲观锁

在实际的多用户并发访问的生产环境里边,我们经常要尽可能的保持数据的一致性.而其中最典型的例子就是我们从表里边读取数据,检查验证后对数据进行修改,然后写回到数据库中.在读取和写入的过程中,如果在多用户并发的环境里边,其他用户已经把你要修改的数据进行了修改是非常有可能发生的情况,这样就造成了数据的不一致性. 最近在做快钱支付的时候就碰到了这个问题,原来的代码如下:1. 表Order的结构:    OrderId   int 自增长    Status   nvarchar(10)  //未处理时的状