悲观锁 订阅
悲观锁,正如其名,具有强烈的独占和排他特性。它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据)。 展开全文
悲观锁,正如其名,具有强烈的独占和排他特性。它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据)。
信息
处    于
数据处于锁定状态
具    有
强烈的独占和排他特性
中文名
悲观锁
是    指
数据被外界修改持保守态度
悲观锁简介
一个典型的倚赖数据库的悲观锁调用:select * from account where name="Erica" for update这条 sql 语句锁定了 account 表中所有符合检索条件( name="Erica" )的记录。 本次事务提交之前(事务提交时会释放事务过程中的锁),外界无法修改这些记录。Hibernate 的悲观锁,也是基于数据库的锁机制实现。下面的代码实现了对查询记录的加锁:String hqlStr = "from TUser as user where user.name='Erica'";Query query = session.createQuery(hqlStr);query.setLockMode("user",LockMode.UPGRADE); // 加锁List userList = query.list();// 执行查询,获取数据query.setLockMode 对查询语句中,特定别名所对应的记录进行加锁(我们为TUser 类指定了一个别名"user"),这里也就是对返回的所有 user 记录进行加锁。观察运行期 Hibernate 生成的 SQL 语句:select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex from t_user tuser0_ where (tuser0_.name='Erica' ) for update这里 Hibernate 通过使用数据库的 for update 子句实现了悲观锁机制。Hibernate 的加锁模式有:Ø LockMode.NONE : 无锁机制。Ø LockMode.WRITE : Hibernate 在 Insert 和 Update 记录的时候会自动 获取。Ø LockMode.READ : Hibernate 在读取记录的时候会自动获取。 以上这三种锁机制一般由 Hibernate 内部使用,如 Hibernate 为了保证 Update过程中对象不会被外界修改,会在 save 方法实现中自动为目标对象加上 WRITE 锁。Ø LockMode.UPGRADE :利用数据库的 for update 子句加锁。Ø LockMode. UPGRADE_NOWAIT : Oracle 的特定实现,利用 Oracle 的 forupdate nowait 子句实现加锁。
收起全文
精华内容
下载资源
问答
  • 悲观锁
    2022-03-29 07:52:07

    悲观锁和乐观锁并不是某个具体的“锁”而是一种并发编程的基本概念,是根据看待并发同步的角度。乐观锁和悲观锁最早出现在数据库的设计当中,后来逐渐被 Java 的并发包所引入。

    悲观锁

    悲观锁认为对于同一个数据的并发操作一定是会发生修改的,采取加锁的形式,悲观地认为,不加锁的并发操作一定会出问题。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。Java中Synchronized和ReentrantLock等独占锁就是悲观锁思想实现的。

    乐观锁

    乐观锁正好和悲观锁相反,它获取数据的时候,并不担心数据被修改,每次获取数据的时候也不会加锁,只是在更新数据的时候,通过判断现有的数据是否和原数据一致来判断数据是否被其他线程操作,如果没被其他线程修改则进行数据更新,如果被其他线程修改则不进行数据更新。Lock 是乐观锁的典型实现案例。

    典型案例

    (1)悲观锁:synchronized 关键字和 Lock 接口相关类

    Java 中悲观锁的实现包括 synchronized 关键字和 Lock 相关类等,我们以 Lock 接口为例,例如 Lock 的实现类 ReentrantLock,类中的 lock() 等方法就是执行加锁,而 unlock() 方法是执行解锁。处理资源之前必须要先加锁并拿到锁,等到处理完了之后再解开锁,这就是非常典型的悲观锁思想。

    (2)乐观锁:原子类

    乐观锁的典型案例就是原子类,例如 AtomicInteger 在更新数据时,就使用了乐观锁的思想,多个线程可以同时操作同一个原子变量。

    (3)大喜大悲:数据库

    数据库中同时拥有悲观锁和乐观锁的思想。例如,我们如果在 MySQL 选择 select for update 语句,那就是悲观锁,在提交之前不允许第三方来修改该数据,这当然会造成一定的性能损耗,在高并发的情况下是不可取的。相反,我们可以利用一个版本 version 字段在数据库中实现乐观锁。在获取及修改数据时都不需要加锁,但是我们在获取完数据并计算完毕,准备更新数据时,会检查版本号和获取数据时的版本号是否一致,如果一致就直接更新,如果不一致,说明计算期间已经有其他线程修改过这个数据了,那我就可以选择重新获取数据,重新计算,然后再次尝试更新数据。

    数据库的悲观锁示例:

    select * from account where name="Erica" for update

    这条 sql 语句锁定了 account 表中所有符合检索条件( name="Erica" )的记录。本次事务提交之前(事务提交时会释放事务过程中的锁),外界无法修改这些记录.。

    数据库的乐观锁示例:

    假设取出数据的时候 version 为1

    UPDATE student

    SET

    name=‘小李’,

    version= 2WHERE   id= 100AND version= 1

    CAS介绍

    Java中的乐观锁大部分都是通过CAS(CompareAndSwap,比较并交换)操作实现的,CAS是一个多线程同步的原子指令,CAS操作包含三个重要的信息,即内存位置、预期原值和新值。如果内存位置的值和预期的原值相等的话,那么就可以把该位置的值更新为新值,否则不做任何修改。

    补充说明: 虽然ReentrantLock也是通过CAS实现的,但是是悲观锁。

    缺点:ABA问题.

    CAS可能会造成ABA的问题,ABA问题指的是,线程拿到了最初的预期原值A,然而在将要进行CAS的时候,被其他线程抢占了执行权,把此值从A变成了B,然后其他线程又把此值从B变成A,然而此时的 A 值已经并非原来的 A 值了,但最初的线程并不知道这个情况,在它进行 CAS 的时候,就会误认为它从来没有被修改过,只对比了预期原值为 A 就进行了修改,这就造成了 ABA 的问题。

    以警匪剧为例,假如某人把装了100W现金的箱子放在了家里,几分钟之后要拿它去赎人,然而在趁他不注意的时候,进来了一个小偷,用空箱子换走了装满钱的箱子,当某人进来之后看到箱子还是一模一样的,他会以为这就是原来的箱子,就拿着它去赎人了,这种情况肯定有问题,因为箱子已经是空的了,这就是 ABA 的问题。

    JDK在1.5时提供了AtomicStampedReference类也可以解决ABA的问题,此类维护了一个“版本号”Stamp,每次在比较时不止比较当前值还比较版本号,这样就解决了 ABA 的问题。

    综合分析实例:

    如一个金融系统,当某个操作员读取用户的数据,并在读出的用户数据的基础上进行修改时(如更改用户帐户余额),如果采用悲观锁机制,也就意味着整个操作过程中(从操作员读出数据、开始修改直至提交修改结果的全过程,甚至还包括操作 员中途去煮咖啡的时间),数据库记录始终处于加锁状态,可见,如果面对几百上千个并发,这样的情况将导致怎样的后果。乐观锁机制在一定程度上解决了这个问题。

    乐观锁,大多是基于数据版本( version )记录机制实现。何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时,将此版本号一同读出,之后更新时,对此版本号加一。同时,将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对,如果提交的数据版本号等于数据库表当前版本号,则予以更新,否则认为是过期数据。

    对于上面修改用户帐户信息的例子而言,假设数据库中帐户信息表中有一个 version 字段,当前值为 1 ;而当前帐户余额字段( balance )为 $100 。

    1 操作员 A 此时将其读出( version=1 ),并从其帐户余额中扣除 $50( $100-$50 )。

    2 在操作员 A 操作的过程中,操作员B 也读入此用户信息( version=1 ),并从其帐户余额中扣除 $20 ( $100-$20 )。

    3 操作员 A 完成了修改工作,将 version=1 的数据连同帐户扣除后余额( balance=$50 ),提交至数据库更新,此时由于提交数据版本等于数据库记录当前版本,数据被更新,同时数据库记录 version 更新为 2(set version=version+1 where version=1) 。

    4 操作员 B 完成了数据录入操作,也将 version=1 的数据试图向数据库提交( balance=$80 ),但此时比对数据库记录版本时发现,操作员 B 提交的数据版本号为 1 ,数据库记录当前版本也为 2 ,不满足 “ 提交版本必须等于记录当前版本才能执行更新 “ 的乐观锁策略,因此,操作员 B 的提交被驳回。

    这样,就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。

    悲观锁乐观锁优缺点:

    优点:

    悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。而乐观锁机制避免了长事务中的数据库加锁开销,大大提升了大并发量下的系统整体性能表现。

    缺点:

    需要注意的是,乐观锁机制往往基于系统中的数据存储逻辑,因此也具备一定的局限性,如在上例中,由于乐观锁机制是在我们的系统中实现,来自外部系统的用户余额更新操作不受我们系统的控制,因此可能会造成脏数据被更新到数据库中。在系统设计阶段,我们应该充分考虑到这些情况出现的可能性,并进行相应调整(如将乐观锁策略在数据库存储过程中实现,对外只开放基于此存储过程的数据更新途径,而不是将数据库表直接对外公开)。

    使用场景

    有一种说法认为,悲观锁由于它的操作比较重量级,不能多个线程并行执行,而且还会有上下文切换等动作,所以悲观锁的性能不如乐观锁好,应该尽量避免用悲观锁,这种说法是不正确的。因为虽然悲观锁确实会让得不到锁的线程阻塞,但是这种开销是固定的。悲观锁的原始开销确实要高于乐观锁,但是特点是一劳永逸,就算一直拿不到锁,也不会对开销造成额外的影响。反观乐观锁虽然一开始的开销比悲观锁小,但是如果一直拿不到锁,或者并发量大,竞争激烈,导致不停重试,那么消耗的资源也会越来越多,甚至开销会超过悲观锁。所以,同样是悲观锁,在不同的场景下,效果可能完全不同。

    (1) 悲观锁适合用于并发写入多、临界区代码复杂、竞争激烈等场景,这种场景下悲观锁可以避免大量的无用的反复尝试等消耗。

    (2) 乐观锁适用于大部分是读取,少部分是修改的场景,也适合虽然读写都很多,但是并发并不激烈的场景。在这些场景下,乐观锁不加锁的特点能让性能大幅提高。

    更多相关内容
  • 主要给大家介绍了关于Mysql悲观锁和乐观锁使用的相关资料,文中通过示例代码介绍的非常详细,对大家学习或者使用Mysql具有一定的参考学习价值,需要的朋友们下面来一起学习学习吧
  • 本文实例讲述了mysql 悲观锁与乐观锁。分享给大家供大家参考,具体如下: 悲观锁与乐观锁是人们定义出来的概念,你可以理解为一种思想,是处理并发资源的常用手段。 不要把他们与mysql中提供的锁机制(表锁,行锁,...
  • 锁的定义:   数据库锁定机制简单来说,就是数据库为了保证数据的一致性,而使各种共享资源在被并发访问变得有序所设计的一种规则。 表级锁:开销小,加锁快;...一、悲观锁   顾名思义,就是对于数
  • 主要介绍了SpringBoot整合MyBatis实现乐观锁和悲观锁的示例,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
  • 主要介绍了thinkPHP框架乐观锁和悲观锁,结合实例形式分析了框架乐观锁和悲观锁的原理及thinkPHP相关实现技巧,需要的朋友可以参考下
  • 在关系型数据库中,悲观锁与乐观锁是解决资源并发场景的解决方案,接下来将详细讲解:magnifying_glass_tilted_right:一下这两个并发解决方案的实际使用及优缺点。 首先定义一下数据库,做一个最简单的库存表,如下...
  • 项目中的常用的锁(乐观锁、悲观锁、基于Redis的分布式锁)乐观锁一般通过使用sql来做如添加版本之类的字段来做控制 例:select * from table where version = ?。保证都是一个线程在做更新。悲观锁锁住操作的资源,...
  • (1) 从数据库系统的角度来看分为以下三种类型: •独占(Exclusive Lock)独占锁定的资源只允许进行锁定操作的程序使用,其它任何对它的操作均不会被接受。执行数据更新命令,即INSERT、 UPDATE 或DELETE ...
  • 乐观锁和悲观锁式并发控制主要采用的技术手段 悲观锁 在关系数据库管理系统中,悲观并发控制(悲观锁,PCC)是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作的每...
  • 通常使用的锁分为乐观锁,悲观锁这两种,简单介绍下这两种锁,作为本文的背景知识,对这类知识已经有足够了解的同学可以跳过这部分。 乐观锁 先来看下百度百科上的解释:大多是基于数据版本( Version )记录机制...
  • 封锁的类型以及粒度,两段锁协议,隐式和显式锁定 封锁类型有两种:读写锁和意向锁 读写锁分类读锁(s锁)和写锁(x锁)。...乐观锁和悲观锁都是为了事务的并发控制。 乐观锁 悲观锁 目的 事务
  • 当前的PPT总共56页,从锁的介绍,到java锁(lock、synchronor、aqs)到分布式锁 redis、zk、数据库的悲观锁和乐观锁都有涉及,算是比较完整的一个PPT,适合涉及到锁相关的专题讲座,以及自学的PPT,后面有机会会开...
  • 主要介绍了Java并发问题之乐观锁与悲观锁,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
  • mysql锁,与事务,以及各种级别锁,和乐观锁悲观锁的研究使用
  • 【mysql】关于悲观锁

    2020-12-14 23:59:59
     MySQLInnoDB对数据行的锁定类型一共有四种:共享(读,S)、排他(写,X)、意向共享(IS)和意向排他(IX),支持三种行锁定方式:  行锁(RecordLock):直接加在索引记录上面。  ...
  • 悲观锁与乐观锁的实现(详情图解)

    万次阅读 多人点赞 2020-05-27 10:26:59
    在了解悲观锁和乐观锁之前,我们先了解一下什么是锁,为什么要用到锁? 技术来源于生活,锁不仅在程序中存在,在现实中我们也随处可见,例如我们上下班打卡的指纹锁,保险柜上的密码锁,以及我们我们登录的用户名...

    一、前言

    • 在了解悲观锁和乐观锁之前,我们先了解一下什么是锁,为什么要用到锁?

    • 技术来源于生活,锁不仅在程序中存在,在现实中我们也随处可见,例如我们上下班打卡的指纹锁,保险柜上的密码锁,以及我们我们登录的用户名和密码也是一种锁,生活中用到锁可以保护我们人身安全(指纹锁)、财产安全(保险柜密码锁)、信息安全(用户名密码锁),让我们更放心的去使用和生活,因为有锁,我们不用去担心个人的财产和信息泄露。

    • 而程序中的锁,则是用来保证我们数据安全的机制和手段,例如当我们有多个线程去访问修改共享变量的时候,我们可以给修改操作加锁(syncronized)。当多个用户修改表中同一数据时,我们可以给该行数据上锁(行锁)。因此,当程序中可能出现并发的情况时,我们就需要通过一定的手段来保证在并发情况下数据的准确性,通过这种手段保证了当前用户和其他用户一起操作时,所得到的结果和他单独操作时的结果是一样的

    • 没有做好并发控制,就可能导致脏读、幻读和不可重复读等问题,如下图所示:
      在这里插入图片描述
      由于并发操作,如果没有加锁进行并发控制,数据库的最终的一条数据可能为3也有可能为5,导致数值不准确

    二、悲观锁和乐观锁

    首先我们需要清楚的一点就是无论是悲观锁还是乐观锁,都是人们定义出来的概念,可以认为是一种思想。

    2.1、悲观锁

    悲观锁(Pessimistic Lock): 就是很悲观,每次去拿数据的时候都认为别人会修改。所以每次在拿数据的时候都会上锁。这样别人想拿数据就被挡住,直到悲观锁被释放,悲观锁中的共享资源每次只给一个线程使用,其它线程阻塞,用完后再把资源转让给其它线程

    但是在效率方面,处理加锁的机制会产生额外的开销,还有增加产生死锁的机会。另外还会降低并行性,如果已经锁定了一个线程A,其他线程就必须等待该线程A处理完才可以处理

    数据库中的行锁,表锁,读锁(共享锁),写锁(排他锁),以及syncronized实现的锁均为悲观锁

    在这里插入图片描述
    悲观并发控制实际上是“先取锁再访问”的保守策略,为数据处理的安全提供了保证,
    在这里插入图片描述

    2.2、乐观锁

    乐观锁(Optimistic Lock): 就是很乐观,每次去拿数据的时候都认为别人不会修改。所以不会上锁,但是如果想要更新数据,则会在更新前检查在读取至更新这段时间别人有没有修改过这个数据。如果修改过,则重新读取,再次尝试更新,循环上述步骤直到更新成功(当然也允许更新失败的线程放弃操作),乐观锁适用于多读的应用类型,这样可以提高吞吐量

    相对于悲观锁,在对数据库进行处理的时候,乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本(version)或者是时间戳来实现,不过使用版本记录是最常用的。

    在这里插入图片描述
    乐观控制相信事务之间的数据竞争(data race)的概率是比较小的,因此尽可能直接做下去,直到提交的时候才去锁定,所以不会产生任何锁和死锁。

    三、锁的实现

    悲观锁阻塞事务、乐观锁回滚重试:它们各有优缺点,不要认为一种一定好于另一种。像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去锁的开销,加大了系统的整个吞吐量。但如果经常产生冲突,上层应用会不断的进行重试,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。

    3.1 悲观锁的实现方式

    场景:

    有用户A和用户B,在同一家店铺去购买同一个商品,但是商品的可购买数量只有一个

    下面是这个店铺的商品表t_goods结构和表中的数据:
    在这里插入图片描述
    在不加锁的情况下,如果用户A和用户B同时下单,就会报错。

    悲观锁的实现,往往依靠数据库提供的锁机制,在数据库中,我们如何用悲观锁去解决这个事情呢?

    1. 加入当用户A对下单购买商品(臭豆腐)的时候,先去尝试对该数据(臭豆腐)加上悲观锁
    2. 加锁失败:说明商品(臭豆腐)正在被其他事务进行修改,当前查询需要等待或者抛出异常,具体返回的方式需要由开发者根据具体情况去定义
    3. 加锁成功:对商品(臭豆腐)进行修改,也就是只有用户A能买,用户B想买(臭豆腐)就必须一直等待。当用户A买好后,用户B再想去买(臭豆腐)的时候会发现数量已经为0,那么B看到后就会放弃购买
    4. 在此期间如果有其他对该数据(臭豆腐)做修改或加锁的操作,都会等待我们解锁后或者直接抛出异常

    在这里插入图片描述

    那么如何加上悲观锁呢?我们可以通过以下语句给id=2的这行数据加上悲观锁,首先关闭MySQL数据库的自动提交属性。因为MySQL默认使用autocommit模式,也就是说,当我们执行一个更新操作后,MySQL会立刻将结果进行提交,(sql语句:set autocommit=0)

    悲观锁加锁sql语句: select num from t_goods where id = 2 for update

    我们通过开启mysql的两个会话,也就是两个命令行来演示:

    事务A:
    我们可以看到数据是立刻马上就可以查询出来,num=1
    在这里插入图片描述
    事务B:
    我们是可以看到,事务B会一直等待事务A释放锁。如果事务A长期不释放锁,那么最终事务B将会报错,报错如下:Lock wait timeout exceeded; try restarting transaction,表示语句已被锁住
    在这里插入图片描述
    现在我们让事务A执行命令去修改数据,让臭豆腐的数量减一,然后查看修改后的数据,最后commit,结束事务

    在这里插入图片描述

    我们可以看到当我们事务A执行完成之后,臭豆腐的库存只有0个了,这个时候我们用户B再来购买这个臭豆腐的时候就会发现,最后一个臭豆腐已经被用户A购买完了,那么用户B只能放弃购买臭豆腐了。
    在这里插入图片描述
    通过悲观锁我们可以解决因为商品库存不足,导致的商品超出库存的售卖。

    3.1 乐观锁的实现方式

    对于上面的应用场景,我们应该怎么用乐观锁去解决呢?在上面的乐观锁中,我们有提到使用版本号(version)来解决,所以我们需要在t_goods加上版本号,调整后的sql表结构如下:
    在这里插入图片描述
    具体操作步骤如下:
    1、首先用户A和用户B同时将臭豆腐(id=2)的数据查出来
    2、然后用户A先买,用户A将(id=1和version=0)作为条件进行数据更新,将数量-1,并且将版本号+1。此时版本号变为1。用户A此时就完成了商品的购买
    3、 用户B开始买,用户B也将(id=1和version=0)作为条件进行数据更新
    4、更新完后,发现更新的数据行数为0,此时就说明已经有人改动过数据,此时就应该提示用户B重新查看最新数据购买

    在这里插入图片描述

    1、首先我们开启两个会话窗口,输入查询语句:select num from t_goods where id = 2
    事务A:
    在这里插入图片描述

    事务B:
    在这里插入图片描述

    这个时候事务A和事务B同时获取相同的数据

    2、此时事务A进行更新数据的操作,然后在查询更新后的数据
    在这里插入图片描述
    这个时候我们可以看到事务A更新成功,并且库存-1 版本号+1成功

    2、此时事务B进行更新数据的操作,然后在查询更新后的数据
    在这里插入图片描述
    可以看到最终修改的时候失败,数据没有改变。此时就需要我们告知用户B重新处理

    3.1.1 CAS

    说到乐观锁,就必须提到一个概念:CAS
    什么是CAS呢?Compare-and-Swap,即比较并替换,也有叫做Compare-and-Set的,比较并设置。
    1、比较:读取到了一个值A,在将其更新为B之前,检查原值是否仍为A(未被其他线程改动)。
    2、设置:如果是,将A更新为B,结束。[1]如果不是,则什么都不做。
    上面的两步操作是原子性的,可以简单地理解为瞬间完成,在CPU看来就是一步操作。
    有了CAS,就可以实现一个乐观锁,允许多个线程同时读取(因为根本没有加锁操作),但是只有一个线程可以成功更新数据,并导致其他要更新数据的线程回滚重试。 CAS利用CPU指令,从硬件层面保证了操作的原子性,以达到类似于锁的效果。

    Java中真正的CAS操作调用的native方法
    因为整个过程中并没有“加锁”和“解锁”操作,因此乐观锁策略也被称为无锁编程。换句话说,乐观锁其实不是“锁”,它仅仅是一个循环重试CAS的算法而已,但是CAS有一个问题那就是会产生ABA问题,什么是ABA问题,以及如何解决呢?

    ABA 问题:
    如果一个变量V初次读取的时候是A值,并且在准备赋值的时候检查到它仍然是A值,那我们就能说明它的值没有被其他线程修改过了吗?很明显是不能的,因为在这段时间它的值可能被改为其他值,然后又改回A,那CAS操作就会误认为它从来没有被修改过。这个问题被称为CAS操作的 "ABA"问题。

    ABA 问题解决:
    我们需要加上一个版本号(Version),在每次提交的时候将版本号+1操作,那么下个线程去提交修改的时候,会带上版本号去判断,如果版本修改了,那么线程重试或者提示错误信息~

    四、如何选择

    悲观锁阻塞事务,乐观锁回滚重试,它们各有优缺点,不要认为一种一定好于另一种。像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去锁的开销,加大了系统的整个吞吐量。

    但如果经常产生冲突,上层应用会不断的进行重试,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。

    注意点:

    1、乐观锁并未真正加锁,所以效率高。一旦锁的粒度掌握不好,更新失败的概率就会比较高,容易发生业务失败。

    2、悲观锁依赖数据库锁,效率低。更新失败的概率比较低。

    五、总结

    这篇文章讲解了悲观锁与乐观锁的区别,以及实现场景,不管是悲观锁还是乐观锁都是人们定义出来的概念,是一种思想,如何有有疑问或者问题的小伙伴可以在下面进行留言,小农看到了会第一时间回复大家,谢谢,大家加油~

    展开全文
  • 36谈谈MySQL支持的事务隔离级别,以及悲观锁和乐观锁的原理和应用场景?
  • NULL 博文链接:https://cdxs2.iteye.com/blog/1938245
  • Java 乐观锁 悲观锁

    2022-05-18 10:46:06
    悲观锁悲观锁在操作数据时比较悲观,认为别人会同时修改数据。因此操作数据时直接把数据锁住,直到操作完成后才会释放锁;上锁期间其他人不能修改数据。 二、实现方式 悲观锁的实现方式是加锁,加锁既可以是对代码...

    一、乐观锁、悲观锁定义

    乐观锁:乐观锁在操作数据时非常乐观,认为别人不会同时修改数据。因此乐观锁不会上锁,只是在执行更新的时候判断一下在此期间别人是否修改了数据:如果别人修改了数据则放弃操作,否则执行操作。

    悲观锁:悲观锁在操作数据时比较悲观,认为别人会同时修改数据。因此操作数据时直接把数据锁住,直到操作完成后才会释放锁;上锁期间其他人不能修改数据。

    二、实现方式

    悲观锁的实现方式是加锁,加锁既可以是对代码块加锁(如Java的synchronized关键字),也可以是对数据加锁。synchronized关键字和Lock的实现类都是悲观锁

    乐观锁的实现方式主要有两种:CAS机制和版本号机制。乐观锁在Java中是通过使用无锁编程来实现,最常采用的是CAS算法,Java原子类中的递增操作就通过CAS自旋实现的。
    请添加图片描述

    1、CAS(Compare And Swap)

    CAS操作包括了3个操作数:

    1. 需要读写的内存位置(V)
    2. 进行比较的预期值(A)
    3. 拟写入的新值(B)
      CAS操作逻辑如下:如果内存位置V的值等于预期的A值,则将该位置更新为新值B,否则不进行任何操作。许多CAS的操作是自旋的:如果操作不成功,会一直重试,直到操作成功为止。

    这里引出一个新的问题,既然CAS包含了Compare和Swap两个操作,它又如何保证原子性呢?答案是:CAS是由CPU支持的原子操作,其原子性是在硬件层面进行保证的。

    下面以Java中的自增操作(i++)为例,看一下悲观锁和CAS分别是如何保证线程安全的。我们知道,在Java中自增操作不是原子操作,它实际上包含三个独立的操作:(1)读取i值;(2)加1;(3)将新值写回i。

    因此,如果并发执行自增操作,可能导致计算结果的不准确。在下面的代码示例中:value1没有进行任何线程安全方面的保护,value2使用了乐观锁(CAS),value3使用了悲观锁(synchronized)。运行程序,使用1000个线程同时对value1、value2和value3进行自增操作,可以发现:value2和value3的值总是等于1000,而value1的值常常小于1000。

    public class suo {
        //value1:线程不安全
        private static int value1 = 0;
        //value2:使用乐观锁
        private static AtomicInteger value2 = new AtomicInteger(0);
        //value3:使用悲观锁
        private static int value3 = 0;
        private static synchronized void increaseValue3(){
            value3++;
        }
    
        public static void main(String[] args) throws Exception {
            //开启1000个线程,并执行自增操作
            for(int i = 0; i < 1000; ++i){
                new Thread(new Runnable() {
                    @Override
                    public void run() {
                        try {
                            Thread.sleep(100);
                        } catch (InterruptedException e) {
                            e.printStackTrace();
                        }
                        value1++;
                        value2.getAndIncrement();
                        increaseValue3();
                    }
                }).start();
            }
            //打印结果
            Thread.sleep(1000);
            System.out.println("线程不安全:" + value1);
            System.out.println("乐观锁(AtomicInteger):" + value2);
            System.out.println("悲观锁(synchronized):" + value3);
        }
    }
    

    输出:

    线程不安全:991
    乐观锁(AtomicInteger):1000
    悲观锁(synchronized):1000
    

    首先来介绍AtomicInteger。AtomicInteger是java.util.concurrent.atomic包提供的原子类,利用CPU提供的CAS操作来保证原子性;除了AtomicInteger外,还有AtomicBoolean、AtomicLong、AtomicReference等众多原子类。
    java是无法实现对底层内存的操作的,C++可以,java使用Unsafe类实现。

    public class AtomicInteger extends Number implements java.io.Serializable {
        private static final long serialVersionUID = 6214790243416807050L;
    
        // setup to use Unsafe.compareAndSwapInt for updates
        private static final Unsafe unsafe = Unsafe.getUnsafe();
        private static final long valueOffset;
    
        static {
            try {
                valueOffset = unsafe.objectFieldOffset
                    (AtomicInteger.class.getDeclaredField("value"));
            } catch (Exception ex) { throw new Error(ex); }
        }
        private volatile int value;
    
    • unsafe: 获取并操作内存的数据。
    • valueOffset: 存储value在AtomicInteger中的偏移量。
    • value: 存储AtomicInteger的int值,该属性需要借助volatile关键字保证其在线程间是可见的。

    我们查看AtomicInteger的自增函数incrementAndGet()的源码时,发现自增函数底层调用的是unsafe.getAndAddInt()。但是由于JDK本身只有Unsafe.class,只通过class文件中的参数名,并不能很好的了解方法的作用,所以我们通过OpenJDK 8 来查看Unsafe的源码:

    // ------------------------- JDK 8 -------------------------
    // AtomicInteger 自增方法
    public final int incrementAndGet() {
      return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
    }
    
    // Unsafe.class
    public final int getAndAddInt(Object var1, long var2, int var4) {
      int var5;
      do {
          var5 = this.getIntVolatile(var1, var2);
      } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
      return var5;
    }
    
    // ------------------------- OpenJDK 8 -------------------------
    // Unsafe.java
    public final int getAndAddInt(Object o, long offset, int delta) {
       int v;
       do {
           v = getIntVolatile(o, offset);
       } while (!compareAndSwapInt(o, offset, v, v + delta));
       return v;
    }
    

    根据OpenJDK 8的源码我们可以看出,getAndAddInt()循环获取给定对象o中的偏移量处的值v,然后判断内存值是否等于v。如果相等则将内存值设置为 v + delta,否则返回false,继续循环进行重试,直到设置成功才能退出循环,并且将旧值返回。整个“比较+更新”操作封装在compareAndSwapInt()中,在JNI里是借助于一个CPU指令完成的,属于原子操作,可以保证多个线程都能够看到同一个变量的修改值。

    其他源码:

     public final boolean compareAndSet(int expect, int update) {
         return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
     }
    public final int getAndIncrement() {
       return unsafe.getAndAddInt(this, valueOffset, 1);
    }
    
    1. getAndIncrement()实现的自增操作是自旋CAS操作:在循环中进行compareAndSet,如果执行成功则退出,否则一直执行。

    2. 其中compareAndSet是CAS操作的核心,它是利用Unsafe对象实现的。

    3. Unsafe又是何许人也呢?Unsafe是用来帮助Java访问操作系统底层资源的类(如可以分配内存、释放内存),通过Unsafe,Java具有了底层操作能力,可以提升运行效率;强大的底层资源操作能力也带来了安全隐患(类的名字Unsafe也在提醒我们这一点),因此正常情况下用户无法使用。AtomicInteger在这里使用了Unsafe提供的CAS功能。

    4. valueOffset可以理解为value在内存中的偏移量,对应了CAS三个操作数(V/A/B)中的V;偏移量的获得也是通过Unsafe实现的。

    5. value域的volatile修饰符:Java并发编程要保证线程安全,需要保证原子性、可视性和有序性;CAS操作可以保证原子性,而volatile可以保证可视性和一定程度的有序性;在AtomicInteger中,volatile和CAS一起保证了线程安全性。关于volatile作用原理的说明涉及到Java内存模型(JMM),这里不详细展开。

    2、版本号机制

    除了CAS,版本号机制也可以用来实现乐观锁。版本号机制的基本思路是在数据中增加一个字段version,表示该数据的版本号,每当数据被修改,版本号加1。当某个线程查询数据时,将该数据的版本号一起查出来;当该线程更新数据时,判断当前版本号与之前读取的版本号是否一致,如果一致才进行操作。

    需要注意的是,这里使用了版本号作为判断数据变化的标记,实际上可以根据实际情况选用其他能够标记数据版本的字段,如时间戳等。

    三、优缺点和适用场景

    1、功能限制

    与悲观锁相比,乐观锁适用的场景受到了更多的限制,无论是CAS还是版本号机制。

    例如,CAS只能保证单个变量操作的原子性,当涉及到多个变量时,CAS是无能为力的,而synchronized则可以通过对整个代码块加锁来处理。再比如版本号机制,如果query的时候是针对表1,而update的时候是针对表2,也很难通过简单的版本号来实现乐观锁。

    2、竞争激烈程度

    如果悲观锁和乐观锁都可以使用,那么选择就要考虑竞争的激烈程度:

    当竞争不激烈 (出现并发冲突的概率小)时,乐观锁更有优势,因为悲观锁会锁住代码块或数据,其他线程无法同时访问,影响并发,而且加锁和释放锁都需要消耗额外的资源。
    当竞争激烈(出现并发冲突的概率大)时,悲观锁更有优势,因为乐观锁在执行更新时频繁失败,需要不断重试,浪费CPU资源。

    • 悲观锁适合写操作多的场景,先加锁可以保证写操作时数据正确。
    • 乐观锁适合读操作多的场景,不加锁的特点能够使其读操作的性能大幅提升。

    四、乐观锁加锁吗?

    (1)乐观锁本身是不加锁的,只是在更新时判断一下数据是否被其他线程更新了;AtomicInteger便是一个例子。

    (2)有时乐观锁可能与加锁操作合作。

    五、CAS有哪些缺点

    1、ABA问题

    假设有两个线程——线程1和线程2,两个线程按照顺序进行以下操作:

    (1)线程1读取内存中数据为A;

    (2)线程2将该数据修改为B;

    (3)线程2将该数据修改为A;

    (4)线程1对数据进行CAS操作

    在第(4)步中,由于内存中数据仍然为A,因此CAS操作成功,但实际上该数据已经被线程2修改过了。这就是ABA问题。

    在AtomicInteger的例子中,ABA似乎没有什么危害。但是在某些场景下,ABA却会带来隐患,例如栈顶问题:一个栈的栈顶经过两次(或多次)变化又恢复了原值,但是栈可能已发生了变化。

    对于ABA问题,比较有效的方案是引入版本号,内存中的值每发生一次变化,版本号都+1;在进行CAS操作时,不仅比较内存中的值,也会比较版本号,只有当二者都没有变化时,CAS才能执行成功。Java中的AtomicStampedReference类便是使用版本号来解决ABA问题的。这样变化过程就从“A-B-A”变成了“1A-2B-3A”。

    2、循环时间长开销大

    CAS操作如果长时间不成功,会导致其一直自旋,给CPU带来非常大的开销。

    3、功能限制

    只能保证一个共享变量的原子操作。对一个共享变量执行操作时,CAS能够保证原子操作,但是对多个共享变量操作时,CAS是无法保证操作的原子性的。

    展开全文
  • 乐观锁和悲观锁

    2018-03-27 23:23:23
    悲观锁,正如其名,它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部 系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状 态。悲观锁的实现,往往依靠数据库提供的锁机制...
  • 数据库悲观锁和乐观锁

    mysql的锁

    mysql中不同的引擎分不同的锁

    行锁表锁页锁
    MyISAM
    BDB
    InnoDB
    • 表锁: 开销小,加锁快;不会出现死锁;锁定力度大,发生锁冲突概率高,并发度最低

    • 行锁: 开销大,加锁慢;会出现死锁;锁定粒度小,发生锁冲突的概率低,并发度高(innodb一般都是用行锁)

    • 页锁: 开销和加锁速度介于表锁和行锁之间;会出现死锁;锁定粒度介于表锁和行锁之间,并发度一般

    因为我们全是用的innodb所以我们忽略页锁

    回顾事务以及acid的属性

    1.事务(Transaction)及其ACID属性 事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性,通常简称为事务的ACID属性。

    原子性(Atomicity):事务是一个原子操作单元,其对数据的修改,要么全都执行,要么全都不执行。 一致性(Consistent):在事务开始和完成时,数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改,以保持数据的完整性;事务结束时,所有的内部数据结构(如B树索引或双向链表)也都必须是正确的。 隔离性(Isolation):数据库系统提供一定的隔离机制,保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的,反之亦然。 持久性(Durable):事务完成之后,它对于数据的修改是永久性的,即使出现系统故障也能够保持。

    并发带来的问题

     相对于串行处理来说,并发事务处理能大大增加数据库资源的利用率,提高数据库系统的事务吞吐量,从而可以支持更多的用户。但并发事务处理也会带来一些问题,主要包括以下几种情况。

      更新丢失(Lost Update):当两个或多个事务选择同一行,然后基于最初选定的值更新该行时,由于每个事务都不知道其他事务的存在,就会发生丢失更新问题--最后的更新覆盖了由其他事务所做的更新。例如,两个编辑人员制作了同一文档的电子副本。每个编辑人员独立地更改其副本,然后保存更改后的副本,这样就覆盖了原始文档。最后保存其更改副本的编辑人员覆盖另一个编辑人员所做的更改。如果在一个编辑人员完成并提交事务之前,另一个编辑人员不能访问同一文件,则可避免此问 题。   脏读(Dirty Reads):一个事务正在对一条记录做修改,在这个事务完成并提交前,这条记录的数据就处于不一致状态;这时,另一个事务也来读取同一条记录,如果不加 控制,第二个事务读取了这些“脏”数据,并据此做进一步的处理,就会产生未提交的数据依赖关系。这种现象被形象地叫做"脏读"。   不可重复读(Non-Repeatable Reads):一个事务在读取某些数据后的某个时间,再次读取以前读过的数据,却发现其读出的数据已经发生了改变、或某些记录已经被删除了!这种现象就叫做“不可重复读”。   幻读(Phantom Reads):一个事务按相同的查询条件重新读取以前检索过的数据,却发现其他事务插入了满足其查询条件的新数据,这种现象就称为“幻读”。

    2、事务并发会产生问题例子:

    1)第一类丢失更新:在没有事务隔离的情况下,两个事务都同时更新一行数据,但是第二个事务却中途失败退出, 导致对数据的两个修改都失效了。

    例如:

    张三的工资为5000,事务A中获取工资为5000,事务B获取工资为5000,汇入100,并提交数据库,工资变为5100,

    随后

    事务A发生异常,回滚了,恢复张三的工资为5000,这样就导致事务B的更新丢失了。

    2)脏读:脏读就是指当一个事务正在访问数据,并且对数据进行了修改,而这种修改还没有提交到数据库中,这时,另外一个事务也访问这个数据,然后使用了这个数据。 例如:   张三的工资为5000,事务A中把他的工资改为8000,但事务A尚未提交。   与此同时,   事务B正在读取张三的工资,读取到张三的工资为8000。   随后,   事务A发生异常,而回滚了事务。张三的工资又回滚为5000。   最后,   事务B读取到的张三工资为8000的数据即为脏数据,事务B做了一次脏读。

    3)不可重复读:是指在一个事务内,多次读同一数据。在这个事务还没有结束时,另外一个事务也访问该同一数据。那么,在第一个事务中的两次读数据之间,由于第二个事务的修改,那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的,因此称为是不可重复读。 例如:   在事务A中,读取到张三的工资为5000,操作没有完成,事务还没提交。   与此同时,   事务B把张三的工资改为8000,并提交了事务。   随后,   在事务A中,再次读取张三的工资,此时工资变为8000。在一个事务中前后两次读取的结果并不致,导致了不可重复读。

    4)第二类丢失更新:不可重复读的特例。有两个并发事务同时读取同一行数据,然后其中一个对它进行修改提交,而另一个也进行了修改提交。这就会造成第一次写操作失效。

    例如:

    在事务A中,读取到张三的存款为5000,操作没有完成,事务还没提交。   与此同时,   事务B,存储1000,把张三的存款改为6000,并提交了事务。   随后,   在事务A中,存储500,把张三的存款改为5500,并提交了事务,这样事务A的更新覆盖了事务B的更新。

    5)幻读:是指当事务不是独立执行时发生的一种现象,例如第一个事务对一个表中的数据进行了修改,这种修改涉及到表中的全部数据行。同时,第二个事务也修改这个表中的数据,这种修改是向表中插入一行新数据。那么,以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行,就好象发生了幻觉一样。 例如:   目前工资为5000的员工有10人,事务A读取所有工资为5000的人数为10人。   此时,   事务B插入一条工资也为5000的记录。   这是,事务A再次读取工资为5000的员工,记录为11人。此时产生了幻读。

    提醒: 不可重复读的重点是修改,同样的条件,你读取过的数据,再次读取出来发现值不一样了 幻读的重点在于新增或者删除,同样的条件,第 1 次和第 2 次读出来的记录数不一样

    事务隔离级别

      在上面讲到的并发事务处理带来的问题中,“更新丢失”通常是应该完全避免的。但防止更新丢失,并不能单靠数据库事务控制器来解决,需要应用程序对要更新的数据加必要的锁来解决,因此,防止更新丢失应该是应用的责任。

    “脏读”、“不可重复读”和“幻读”,其实都是数据库读一致性问题,必须由数据库提供一定的事务隔离机制来解决。数据库实现事务隔离的方式,基本上可分为以下两种。

      一种是在读取数据前,对其加锁,阻止其他事务对数据进行修改。

      另一种是不用加任何锁,通过一定机制生成一个数据请求时间点的一致性数据快照(Snapshot),并用这个快照来提供一定级别(语句级或事务级)的一 致 性读取。从用户的角度来看,好像是数据库可以提供同一数据的多个版本,因此,这种技术叫做数据多版本并发控制(MultiVersion Concurrency Control,简称MVCC或MCC),也经常称为多版本数据库。

    • 当前读 像select lock in share mode(共享锁), select for update ; update, insert ,delete(排他锁)这些操作都是一种当前读,为什么叫当前读?就是它读取的是记录的最新版本,读取时还要保证其他并发事务不能修改当前记录,会对读取的记录进行加锁

      另一种是不用加任何锁,通过一定机制生成一个数据请求时间点的一致性数据快照(Snapshot),并用这个快照来提供一定级别(语句级或事务级)的一 致 性读取。从用户的角度来看,好像是数据库可以提供同一数据的多个版本,因此,这种技术叫做数据多版本并发控制(MultiVersion Concurrency Control,简称MVCC或MCC),也经常称为多版本数据库。

    • 快照读 像不加锁的select操作就是快照读,即不加锁的非阻塞读;快照读的前提是隔离级别不是串行级别,串行级别下的快照读会退化成当前读;之所以出现快照读的情况,是基于提高并发性能的考虑,快照读的实现是基于多版本并发控制,即MVCC,可以认为MVCC是行锁的一个变种,但它在很多情况下,避免了加锁操作,降低了开销;既然是基于多版本,即快照读可能读到的并不一定是数据的最新版本,而有可能是之前的历史版本

      数据库的事务隔离越严格,并发副作用越 小,但付出的代价也就越大,因为事务隔离实质上就是使事务在一定程度上 “串行化”进行,这显然与“并发”是矛盾的。同时,不同的应用对读一致性和事务隔离程度的要求也是不同的,比如许多应用对“不可重复读”和“幻读”并不敏 感,可能更关心数据并发访问的能力。

    为了解决“隔离”与“并发”的矛盾,ISO/ANSI SQL92定义了4个事务隔离级别,每个级别的隔离程度不同,允许出现的副作用也不同,应用可以根据自己的业务逻辑要求,通过选择不同的隔离级别来平衡 “隔离”与“并发”的矛盾。一下是这4个隔离级别的特性。

    读数据一致性及允许的并发副作用 隔离级别读数据一致性脏读不可重复读幻读
    未提交读(Read uncommitted)最低级别,只能保证不读取物理上损坏的数据
    已提交度(Read committed)语句级
    可重复读(Repeatable read)事务级
    可序列化(Serializable)最高级别,事务级

    mysql默认的事务处理级别是'REPEATABLE-READ',也就是可重复读

    设置可序列化transaction-isolation = SERIALIZABLE

    但是为什么我们不用这个可序列化呢,原因是:在这个模式下事务串行化顺序执行,也就是事物a 执行读写操作时,会锁定检索的数据行范围(范围锁),这种锁会阻止其他事物在本范围内的一切操作,这种事务隔离级别效率低下,比较耗数据库性能,对并发也不友好,虽然并发数据准但是速度太慢了。

    悲观锁和乐观锁

    悲观锁和乐观锁两种常见的资源并发锁设计思路,也是并发编程中一个非常基础的概念

    mysql的并发操作时而引起的数据的不一致性(数据冲突):

    解决方案:

    1.悲观锁,假设两个用户(或以上)对同一个数据对象操作引起的数据出问题。一定存在 利用数据库的一种机制。

    2.乐观锁,假设两个用户(或以上)对同一个数据对象操作引起的数据出问题。不一定发生。update时候存在版本,更新时候按版本号进行更新。

    所以说当涉及到并发改数据库的情况,我们这边要去使用悲观锁或者是乐观锁

    什么是悲观锁

    java里面的同步机制synchronized关键字就是一个悲观锁,当一个变量或者是方法使用了synchronized修饰时,其他的线程想要拿到这个变量或者是方法的时候将就需要等到别的线程释放。

    悲观锁就是在操作数据时,认为此操作会出现数据冲突,所以在进行每次操作时都要通过获取锁才能进行对相同数据的操作,这点跟java中的synchronized很相似,所以悲观锁需要耗费较多的时间。另外与乐观锁相对应的,悲观锁是由数据库自己实现了的,要用的时候,我们直接调用数据库的相关语句就可以了

    悲观锁一般分两个

    共享锁,又称之为读锁,简称S锁,当事务对数据加上读锁后,其他事务只能对该数据加读锁,不能做任何修改操作,也就是不能添加写锁。只有当数据上的读锁被释放后,其他事务才能对其添加写锁。共享锁主要是为了支持并发的读取数据而出现的,读取数据时,不允许其他事务对当前数据进行修改操作,从而避免”不可重读”的问题的出现。人话:我读的时候别人能读,但是不能改

    实现方式:SELECT * from city where id = "1" lock in share mode;

    排他锁,又称为写锁、独占锁,简称x锁,在我们开发使用的mysql中 INSERT、UPDATE 或 DELETE会默认进行排它锁但是select并不会加。若事务T对数据对象A加上X锁,则只允许T读取和修改A,其他任何事务都不能再对A加任何类型的锁,直到T释放A上的锁。这就保证了其他事务在T释放A上的锁之前不能再读取锁和修改A。人话:我写的时候别人不能写

    实现方式:但是这个是比较不好理解的,不能加锁并不代表不能读,select xx from xx 并不会加任何类型的锁,所以其他事务也可能读的但是当我们所以我们就使用SELECT * from city where id = "1" for update 就是加写锁,这个时候你读就读不到了,就必须等人家修改完你才能读的到,所以我们开发想使用悲观锁就用for update;

    总结一下 如果你使用共享锁用select的时候别人不能改,但是能普通的读和加共享锁的读,当你是写锁select的时候别人不能改,但是只能普通的读不能加锁的读。反正就是加锁的就不能改,但是你普通的select 是不加锁的 别人能改,并且别人改了虽然事务没有提交你也能select到,但是如果你select for update了就是一但有人改了,你必须事务结束之后你才能读到,所以一般比较重要敏感的数据就要这样去弄,比如金额,但是这样去弄是有缺陷的,你要知道,只要加锁,运行的效率就会出问题,就会等。

    什么是乐观锁

    虽然较乐观锁,但是他是不加锁的

    乐观锁是靠我们程序员去实现的

    mysql的乐观锁实现有方式

    版本号机制

    数据库加version字段 每次更新给这个version+1,条件加上你之前的version,如果version给其他的线程改了,你这个请求就会被驳回。

    mybatis实现这种方式要获取update影响条数,准确的影响条数要在连接地址上写useAffectedRows=true 类似于jdbc:mysql://localhost:3306/kj08?useAffectedRows=true&useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone = GMT

    手动回滚事务:TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();

    还有一种乐观锁概念叫做CAS(compare and swap)

    CAS:CAS是乐观锁技术,当多个线程尝试使用CAS同时更新同一个变量时,只有其中一个线程能更新变量的值,而其它线程都失败,失败的线程并不会被挂起,而是被告知这次竞争中失败,并可以再次尝试。

    CAS 操作中包含三个操作数 —— 需要读写的内存位置(V)、进行比较的预期原值(A)和拟写入的新值(B)。如果内存位置V的值与预期原值A相匹配,那么处理器会自动将该位置值更新为新值B。否则处理器不做任何操作。无论哪种情况,它都会在 CAS 指令之前返回该位置的值。(在 CAS 的一些特殊情况下将仅返回 CAS 是否成功,而不提取当前值。)CAS 有效地说明了“ 我认为位置 V 应该包含值 A;如果包含该值,则将 B 放到这个位置;否则,不要更改该位置,只告诉我这个位置现在的值即可。 ”这其实和乐观锁的冲突检查+数据更新的原理是一样的。这里再强调一下,乐观锁是一种思想。CAS是这种思想的一种实现方式。

     悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据)。

            乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

            两种锁各有优缺点,不可认为一种好于另一种,像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。但如果经常产生冲突,上层应用会不断的进行retry,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。

            本质上,数据库的乐观锁做法和悲观锁做法主要就是解决下面假设的场景,避免丢失更新问题:
            一个比较清楚的场景
            下面这个假设的实际场景可以比较清楚的帮助我们理解这个问题:
    假设当当网上用户下单买了本书,这时数据库中有条订单号为001的订单,其中有个status字段是’有效’,表示该订单是有效的;
    后台管理人员查询到这条001的订单,并且看到状态是有效的
    用户发现下单的时候下错了,于是撤销订单,假设运行这样一条SQL: update order_table set status = ‘取消’ where order_id = 001;
    后台管理人员由于在b这步看到状态有效的,这时,虽然用户在c这步已经撤销了订单,可是管理人员并未刷新界面,看到的订单状态还是有效的,于是点击”发货”按钮,将该订单发到物流部门,同时运行类似如下SQL,将订单状态改成已发货:update order_table set status = ‘已发货’ where order_id = 001

    观点1:只有冲突非常严重的系统才需要悲观锁;“所有悲观锁的做法都适合于状态被修改的概率比较高的情况,具体是否合适则需要根据实际情况判断。”,表达的也是这个意思,不过说法不够准确;的确,之所以用悲观锁就是因为两个用户更新同一条数据的概率高,也就是冲突比较严重的情况下,所以才用悲观锁。


    观点2:最后提交前作一次select for update检查,然后再提交update也是一种乐观锁的做法,的确,这符合传统乐观锁的做法,就是到最后再去检查。但是wiki在解释悲观锁的做法的时候,’It is not appropriate for use in web application development.’, 现在已经很少有悲观锁的做法了,所以我自己将这种二次检查的做法也归为悲观锁的变种,因为这在所有乐观锁里面,做法和悲观锁是最接近的,都是先select for update,然后update

    在实际应用中我们在更新数据的时候,更严谨的做法是带上更新前的“状态”,如

    update order_table set status = ‘取消’ where order_id = 001 and status = ‘待支付’ and ..........; 

    update order_table set status = ‘已发货’ where order_id = 001 and status = ‘已支付’ and ..........;
    然后在业务逻辑代码里判断更新的记录数,为0说明数据库已经被更新了,否则是正常的。

    总结 如果遇到多并发的问题我们再java层也能解决,在mysql层也能解决,看我们的实现方式,你在java上玩锁也行,你在mysql上玩锁也行,我这边给你们提供概念,具体实现方式结合你们的项目,看需求实现

    展开全文
  • 并发编程--锁--悲观锁和乐观锁

    千次阅读 2021-03-16 02:58:44
    悲观锁和乐观锁并不是某个具体的“锁”而是一种并发编程的基本概念,是根据看待并发同步的角度。乐观锁和悲观锁最早出现在数据库的设计当中,后来逐渐被 Java 的并发包所引入。悲观锁悲观锁认为对于同一个数据的并发...
  • 前言 ...如果是Django2.0以下的版本,需要去修改到这个隔离级别,不然乐观操作时无法读取已经被修改的数据 RepeatableRead(可重读) 这是这是Mysql默认的隔离级别,可以到mysql的配置文件中去修改;
  • 各种锁汇总,乐观锁、悲观锁、分布式锁、可重入锁、互斥锁、读写锁、分段锁、类锁、行级锁等

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 78,794
精华内容 31,517
关键字:

悲观锁