Mysql 锁机制 -- 乐观锁 & 悲观锁（mysql乐观锁与悲观锁）

25-04-26 2

对于想了解Mysql锁机制--乐观锁&悲观锁的读者，本文将是一篇不可错过的文章，我们将详细介绍mysql乐观锁与悲观锁，并且为您提供关于HibernateJPA悲观锁,乐观锁、Hibernate学习_

对于想了解Mysql 锁机制 -- 乐观锁 & 悲观锁的读者，本文将是一篇不可错过的文章，我们将详细介绍mysql乐观锁与悲观锁，并且为您提供关于Hibernate JPA 悲观锁,乐观锁、Hibernate学习_021_Hibernate中的事务控制+乐观锁+悲观锁、JAVA 乐观锁、悲观锁、Java 并发行级锁 / 字段锁 / 表级锁乐观锁 / 悲观锁共享锁 / 排他锁死锁的有价值信息。

本文目录一览：

Mysql 锁机制 -- 乐观锁 & 悲观锁（mysql乐观锁与悲观锁）
Hibernate JPA 悲观锁,乐观锁
Hibernate学习_021_Hibernate中的事务控制+乐观锁+悲观锁
JAVA 乐观锁、悲观锁
Java 并发行级锁 / 字段锁 / 表级锁乐观锁 / 悲观锁共享锁 / 排他锁死锁

Mysql 锁机制 -- 乐观锁 & 悲观锁（mysql乐观锁与悲观锁）

[TOC]

前言

mysql 的并发操作时而引起的数据的不一致性（数据冲突）：

丢失更新：两个用户（或以上）对同一个数据对象操作引起的数据丢失。

　　　　解决方案：1. 悲观锁，假设丢失更新一定存在；sql 后面加上 for update；这是数据库的一种机制。

　　　　　　　　　2. 乐观锁，假设丢失更新不一定发生。update 时候存在版本，更新时候按版本号进行更新。

第一部分悲观锁

1 概念

悲观锁，正如其名，它指的是对数据被外界（包括当前系统的其它事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排它性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

2 命令行演示

2.1 准备数据

复制代码

DROP DATABASE IF EXISTS cyhTest;
CREATE DATABASE cyhTest;

USE cyhTest;

DROP TABLE IF EXISTS employee;

CREATE TABLE IF NOT EXISTS employee (
  id      INTEGER NOT NULL,
  money   INTEGER,
  version INTEGER,
  PRIMARY KEY (id)
)
  ENGINE = INNODB;

INSERT INTO employee VALUE (1, 0, 1);

SELECT * FROM employee;

复制代码

目前数据库中只有一条记录，且初始 Money=0

2.2 测试

测试准备：

还是两个会话（终端），左边会话是白色背景、右边会话是黑色背景
关闭自动提交：set autocommit = 0;

现在开始测试：

第一步：两个终端均关闭自动提交

左边：

右边：

第二步：左边利用 select .... for update 的悲观锁语法锁住记录

select * from employee where id = 1 for update;

第三步：右边也尝试利用 select .... for update 的悲观锁语法锁住记录

可以看到，Sql 语句被挂起（被阻塞）！

提示：如果被阻塞的时间太长，会提示如下：

第四步：左边执行更新操作并提交事务

Sql 语句：

update employee set money = 0 + 1 where id = 1;
commit;

结果：

分析：

Money 的旧值为 0，所以更新时 Money=0+1
一执行 commit 后，注意查看右边 Sql 语句的变化

第五步：查看右边 Sql 语句的变化

分析：

被左边悲观锁阻塞了 11.33 秒
Money=1，这是左边更新后的结果

2.3 结论

可以看到，当左边（事务 A）使用了 select ... for update 的悲观锁后，右边（事务 B）再想使用将被阻塞，同时，阻塞被解除后事务 B 能看到事务 A 对数据的修改，所以，这就可以很好地解决并发事务的更新丢失问题啦（诚然，这也是人家悲观锁的分内事）

第二部分乐观锁

1 概念

1.1 理解方式一（来自网上其它小伙伴的博客）

乐观锁认为一般情况下数据不会造成冲突，所以在数据进行提交更新时才会对数据的冲突与否进行检测。如果没有冲突那就 OK；如果出现冲突了，则返回错误信息并让用户决定如何去做。

1.2 理解方式二（来自网上其它小伙伴的博客）

乐观锁的特点是先进行业务操作，不到万不得已不会去拿锁。乐观地认为拿锁多半会是成功的，因此在完成业务操作需要实际更新数据的最后一步再去拿一下锁。

1.3 我的理解

理解一：就是 CAS 操作

理解二：类似于 SVN、GIt 这些版本管理系统，当修改了某个文件需要提交的时候，它会检查文件的当前版本是否与服务器上的一致，如果一致那就可以直接提交，如果不一致，那就必须先更新服务器上的最新代码然后再提交（也就是先将这个文件的版本更新成和服务器一样的版本）

乐观锁不是数据库自带的，需要我们自己去实现。

2 如何实现乐观锁呢

首先说明一点的是：乐观锁在数据库上的实现完全是逻辑的，数据库本身不提供支持，而是需要开发者自己来实现。

常见的做法有两种：版本号控制及时间戳控制。

版本号控制的原理：

为表中加一个 version 字段；
当读取数据时，连同这个 version 字段一起读出；
数据每更新一次就将此值加一；
当提交更新时，判断数据库表中对应记录的当前版本号是否与之前取出来的版本号一致，如果一致则可以直接更新，如果不一致则表示是过期数据需要重试或者做其它操作（PS：这完完全全就是 CAS 的实现逻辑呀～）

至于时间戳控制，其原理和版本号控制差不多，也是在表中添加一个 timestamp 的时间戳字段，然后提交更新时判断数据库中对应记录的当前时间戳是否与之前取出来的时间戳一致，一致就更新，不一致就重试。

特点

乐观并发控制相信事务之间的数据竞争概率是较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁

Hibernate JPA 悲观锁,乐观锁

1.悲观锁

它指的是对数据被外界修改持保守态度。假定任何时刻存取数据时，都可能有另一个客户也正在存取同一笔数据，为了保持数据被操作的一致性，于是对数据采取了数据库层次的锁定状态，依靠数据库提供的锁机制来实现。
基于jdbc实现的数据库加锁如下：

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

在更新的过程中，数据库处于加锁状态，任何其他的针对本条数据的操作都将被延迟。本次事务提交后解锁。
而hibernate悲观锁的具体实现如下：

String sql="查询语句";
Query query=session.createQuery(sql);
query.setLockMode("对象"，LockModel.UPGRADE);

说到这里，就提到了hibernate的加锁模式：

LockMode.NONE：无锁机制。
LockMode.WRITE：Hibernate在Insert和Update记录的时候会自动获取。
LockMode.READ：Hibernate在读取记录的时候会自动获取。

这三种加锁模式是供hibernate内部使用的，与数据库加锁无关：
LockMode.UPGRADE：利用数据库的for update字句加锁。
在这里我们要注意的是：只有在查询开始之前（也就是hiernate生成sql语句之前）加锁，才会真正通过数据库的锁机制加锁处理。否则，数据已经通过不包含for updata子句的sql语句加载进来，所谓的数据库加锁也就无从谈起。
但是，从系统的性能上来考虑，对于单机或小系统而言，这并不成问题，然而如果是在网络上的系统，同时间会有许多联机，假设有数以百计或上千甚至更多的并发访问出现，我们该怎么办？如果等到数据库解锁我们再进行下面的操作，我们浪费的资源是多少？–这也就导致了乐观锁的产生。

2.乐观锁

乐观锁定（optimistic locking）则乐观的认为资料的存取很少发生同时存取的问题，因而不作数据库层次上的锁定，为了维护正确的数据，乐观锁定采用应用程序上的逻辑实现版本控制的方法。
例如若有两个客户端，A客户先读取了账户余额100元，之后B客户也读取了账户余额100元的数据，A客户提取了50元，对数据库作了变更，此时数据库中的余额为50元，B客户也要提取30元，根据其所取得的资料，100-30将为70余额，若此时再对数据库进行变更，最后的余额就会不正确。
在不实行悲观锁定策略的情况下，数据不一致的情况一但发生，有几个解决的方法，一种是先更新为主，一种是后更新的为主，比较复杂的就是检查发生变动的数据来实现，或是检查所有属性来实现乐观锁定。
Hibernate 中透过版本号检查来实现后更新为主，这也是Hibernate所推荐的方式，在数据库中加入一个VERSON栏记录，在读取数据时连同版本号一同读取，并在更新数据时递增版本号，然后比对版本号与数据库中的版本号，如果大于数据库中的版本号则予以更新，否则就回报错误。
以刚才的例子，A客户读取账户余额1000元，并连带读取版本号为5的话，B客户此时也读取账号余额1000元，版本号也为5，A客户在领款后账户余额为500，此时将版本号加1，版本号目前为6，而数据库中版本号为5，所以予以更新，更新数据库后，数据库此时余额为500，版本号为6，B客户领款后要变更数据库，其版本号为5，但是数据库的版本号为6，此时不予更新，B客户数据重新读取数据库中新的数据并重新进行业务流程才变更数据库。
以Hibernate实现版本号控制锁定的话，我们的对象中增加一个version属性，例如：

public class Account {
private int version;
....
public void setVersion(int version) {
this.version = version;
}
public int getVersion() {
return version;
}
....
}

而在映像文件中，我们使用optimistic-lock属性设定version控制，属性栏之后增加一个标签，如下：

<hibernate-mapping>
<class name="onlyfun.caterpillar.Account" talble="ACCOUNT" optimistic-lock="version">
<id...../>
<version name="version" column="VERSION"/>
....
</class>
</hibernate-mapping>

设定好版本控制之后，在上例中如果B 客户试图更新数据，将会引发StableObjectStateException例外，我们可以捕捉这个例外，在处理中重新读取数据库中的数据，同时将 B客户目前的数据与数据库中的数据秀出来，让B客户有机会比对不一致的数据，以决定要变更的部份，或者您可以设计程式自动读取新的资料，并重复扣款业务流程，直到数据可以更新为止，这一切可以在背景执行，而不用让您的客户知道。
但是乐观锁也有不能解决的问题存在：上面已经提到过乐观锁机制的实现往往基于系统中的数据存储逻辑，在我们的系统中实现，来自外部系统的用户余额更新不受我们系统的控制，有可能造成非法数据被更新至数据库。因此我们在做电子商务的时候，一定要小心的注意这项存在的问题，采用比较合理的逻辑验证，避免数据执行错误。
也可以在使用Session的load()或是lock()时指定锁定模式以进行锁定。
如果数据库不支持所指定的锁定模式，Hibernate会选择一个合适的锁定替换，而不是丢出一个例外。

悲观锁与乐观锁的比较:

悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受;
相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。乐观锁机制往往基于系统中的数据存储逻辑，因此也具备一定的局限性，如在上例中，由于乐观锁机制是在我们的系统中实现，来自外部系统的更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整（如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开）。
Hibernate 在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数据库的更新操作，利用Hibernate提供的透明化乐观锁实现，将大大提升我们的生产力。

Hibernate中可以通过class描述符的optimistic-lock属性结合version描述符指定。
optimistic-lock属性有如下可选取值：
- none 无乐观锁
- version 通过版本机制实现乐观锁
- dirty 通过检查发生变动过的属性实现乐观锁
- all 通过检查所有属性实现乐观锁

其中通过version实现的乐观锁机制是Hibernate官方推荐的乐观锁实现，同时也是Hibernate中，目前唯一在数据对象脱离Session发生修改的情况下依然有效的锁机制。因此，一般情况下，我们都选择version方式作为Hibernate乐观锁实现机制。

JPA 2.0 锁机制

锁是处理数据库事务并发的一种技术，当两个或更多数据库事务并发地访问相同数据时，锁可以保证同一时间只有一个事务可以修改数据。
锁的方法通常有两种：乐观锁和悲观锁。乐观锁认为多个并发事务之间很少出现冲突，也就是说不会经常出现同一时间读取或修改相同数据，在乐观锁中，其目标是让并发事务自由地同时得到处理，而不是发现或预防冲突。两个事务在同一时刻可以访问相同的数据，但为了预防冲突，需要对数据执行一次检查，检查自上次读取数据以来发生的任何变化。
悲观锁认为事务会经常发生冲突，在悲观锁中，读取数据的事务会锁定数据，在前面的事务提交之前，其它事务都不能修改数据。
JPA 1.0只支持乐观锁，你可以使用EntityManager类的lock()方法指定锁模式的值，可以是READ或WRITE，如：

EntityManagerem = ... ;
em.lock (p1, READ);

对于READ锁模式，JPA实体管理器在事务提交前都会锁定实体，检查实体的版本属性确定实体自上次被读取以来是否有更新，如果版本属性被更新了，实体管理器会抛出一个OptimisticLockException异常，并回滚事务。
对于WRITE锁模式，实体管理器执行和READ锁模式相同的乐观锁操作，但它也会更新实体的版本列。
JPA 2.0增加了6种新的锁模式，其中两个是乐观锁。JPA 2.0也允许悲观锁，并增加了3种悲观锁，第6种锁模式是无锁。
下面是新增的两个乐观锁模式：
1、OPTIMISTIC：它和READ锁模式相同，JPA 2.0仍然支持READ锁模式，但明确指出在新应用程序中推荐使用OPTIMISTIC。
2、OPTIMISTIC_FORCE_INCREMENT：它和WRITE锁模式相同，JPA 2.0仍然支持WRITE锁模式，但明确指出在新应用程序中推荐使用OPTIMISTIC_FORCE_INCREMENT。
下面是新增的三个悲观锁模式：
1、PESSIMISTIC_READ：只要事务读实体，实体管理器就锁定实体，直到事务完成锁才会解开，当你想使用重复读语义查询数据时使用这种锁模式，换句话说就是，当你想确保数据在连续读期间不被修改，这种锁模式不会阻碍其它事务读取数据。
2、PESSIMISTIC_WRITE：只要事务更新实体，实体管理器就会锁定实体，这种锁模式强制尝试修改实体数据的事务串行化，当多个并发更新事务出现更新失败几率较高时使用这种锁模式。
3、PESSIMISTIC_FORCE_INCREMENT：当事务读实体时，实体管理器就锁定实体，当事务结束时会增加实体的版本属性，即使实体没有修改。
你也可以指定新的锁模式NONE，在这种情况下表示没有锁发生。
JPA 2.0也提供了多种方法为实体指定锁模式，你可以使用EntityManager的lock() 和 find()方法指定锁模式。此外，EntityManager.refresh()方法可以恢复实体实例的状态。
下面的代码显示了使用PESSIMISTIC_WRITE锁模式的悲观锁：

    // read
    Part p = em.find(Part.class, pId);
    // lock and refresh before update
    em.refresh(p, PESSIMISTIC_WRITE);
    int pAmount = p.getAmount();
    p.setAmount(pAmount - uCount);

在这个例子中，它首先读取一些数据，然后应用PESSIMISTIC_WRITE锁，在更新数据之前调用EntityManager.refresh()方法，当事务更新实体时，PESSIMISTIC_WRITE锁锁定实体，其它事务就不能更新相同的实体，直到前面的事务提交。

Hibernate学习_021_Hibernate中的事务控制+乐观锁+悲观锁

事务具有ACID(Atomicity+Consistency+Isolation+Durability)特性，在多线程中存在事务并发的情况，如果处理不好的话，会出现以下五中问题：

1：丢失更新

2：脏读：程序读到了其他程序插入到数据库中但还没有正式提交的数据。

3：不可重复读

4：第二类丢失更新

5：幻像读取：牵涉到插入和删除操作，也是不可重复读取的一个特例。

对于数据库的并发事务管理，可以通过查询java.sql.Connection的API得到数据库的事务隔离机制。基本来看有如下四种机制：

1：read-uncommitted（value=1）机制：可以读到其他并发进程没有提交的数据，很不安全。

2：read-committed（value=2)：只可以读到其它进程已经提交的数据。（最佳实践）

3：repeatable-read（value=4)：可重复读取，其实内部实现机制就是给数据库中的对应数据加了一把锁，这样，当前进程用完此数据之前，其他所有的进程都不可以更新此数据。

4：serializable（value=8)：将各个进程序列化，也就是将各个进程先排队，挨个排的执行，这样可以保证事务绝对安全，但是这样效率是最低的。

那么，在Hibernate中如何设置事务隔离级别呢？一般我们可以再hibernate.cfg.xml中设置属性hibernate.connection.isolation来实现。这里一般设置此属性的值为2（read-committed）。但是，这样可能造成不可重复读取。比如一个事务A读取了事务B已经提交的更新数据，但是如果事务B回滚了，这个时候，A第二次读取这个数据，这个时候，前后两次读取结果不一致，造成不可重复读取。面对这个问题，在hibernate中是使用加锁机制来解决这个问题的。加锁又分两种：乐观锁、悲观锁。（程序中一般不考虑幻象读取，因为在一个事务中本身就很少查询两次数据库的，用的少。）

悲观锁：在程序中，悲观的认为本进程把数据读取出来后，一定会有其他进程去修改数据库总已经读取出来的数据。所以就干脆索性给数据库中对应的记录加一把锁，所以，悲观锁的实现依赖于数据库本身的加锁机制。（我们一般的sql：select * ....... for update就是强制数据库给数据记录加锁。）

那么hibernate程序如何实现悲观锁呢？在用get()或者load()方法取对象的时候，可以选择加锁模式：一般而言只可以选择LockMode.UPGRADE这个模式（因为其他加锁模式是Hibernate内部的默认实现，在Hibernate内部使用，不需要用户去理会，比如：LockMode.None、LockMode.Read、LockMode.Write三个）。代码如下：

@Test

public void testQuery() {

隔离级别	脏读（Dirty Read）	不可重复读（NonRepeatable Read）	幻读（Phantom Read）
未提交读（Read uncommitted）	可能	可能	可能
已提交读（Read committed）	不可能	可能	可能
可重复读（Repeatable read）	不可能	不可能	可能
可串行化（Serializable ）	不可能	不可能	不可能

Mysql 锁机制 -- 乐观锁 & 悲观锁（mysql乐观锁与悲观锁）