乐观锁

乐观锁（Optimistic Lock），顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在提交更新的时候会判断一下在此期间别人有没有去更新这个数据。乐观锁适用于读多写少的应用场景，这样可以提高吞吐量。

乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。

乐观锁一般来说有以下2种方式：

使用数据版本（Version）记录机制实现，这是乐观锁最常用的一种实现方式。何谓数据版本？即为数据增加一个版本标识，一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。
使用时间戳（timestamp）。乐观锁定的第二种实现方式和第一种差不多，同样是在需要乐观锁控制的table中增加一个字段，名称无所谓，字段类型使用时间戳（timestamp）, 和上面的version类似，也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳进行对比，如果一致则OK，否则就是版本冲突。

数据库设置乐观锁--作用

Hibernate支持乐观锁。当多个事务同时对数据库表中的同一条数据操作时，如果没有加锁机制的话，就会产生脏数据（duty data）。Hibernate有2种机制可以解决这个问题：乐观锁和悲观锁。这里我们只讨论乐观锁。

Hibernate乐观锁，能自动检测多个事务对同一条数据进行的操作，并根据先胜原则，提交第一个事务，其他的事务提交时则抛出org.hibernate.StaleObjectStateException异常。
Hibernate乐观锁是怎么做到的呢？
我们先从Hibernate乐观锁的实现说起。
要实现Hibenate乐观锁，我们首先要在数据库表里增加一个版本控制字段，字段名随意，比如就叫version，对应hibernate类型只能为long,integer,short,timestamp,calendar，也就是只能为数字或timestamp类型。然后在hibernate mapping里作如下类似定义：

view plain copy to clipboard print ?

<version name="version"
column="VERSION"
type="integer"
/>

[java] view plain copy

<version name="version"
column="VERSION"
type="integer"
/>

告诉Hibernate version作为版本控制用，交由它管理。
当然在entity class里也需要给version加上定义，定义的方法跟其他字段完全一样。

view plain copy to clipboard print ?

private Integer version;
…
// setVersion() && getVersion(Integer)

[java] view plain copy

private Integer version;
…
// setVersion() && getVersion(Integer)

Hibernate乐观锁的的使用：

view plain copy to clipboard print ?

<DIV class=tf_edit_html_lineno id=tf_edit_html_lineno>1Session session1 = sessionFactory.openSession();
2Session session2 = sessionFactory.openSession();
3
4MyEntity et1 = session1.load(MyEntity.class, id);
5MyEntity et2 = session2.load(MyEntity.class, id);
6//这里 et1, et2为同一条数据
7
8Transaction tx1 = session1.beginTransaction();
9//事务1开始
10et1.setName(“Entity1”);
11//事务1中对该数据修改
12
13tx1.commit();
14session1.close();
15//事务1提交
16
17Transaction tx2 = session2.beginTransaction();
18//事务2开始
19et2.setName(“Entity2”);
20//事务2中对该数据修改
21
22tx2.commit();
23session2.close();
24//事务2提交
25
</DIV>

[java] view plain copy

<div id="tf_edit_html_lineno" class="tf_edit_html_lineno">1Session session1 = sessionFactory.openSession();
2Session session2 = sessionFactory.openSession();
3
4MyEntity et1 = session1.load(MyEntity.class, id);
5MyEntity et2 = session2.load(MyEntity.class, id);
6//这里 et1, et2为同一条数据
7
8Transaction tx1 = session1.beginTransaction();
9//事务1开始
10et1.setName(“Entity1”);
11//事务1中对该数据修改
12
13tx1.commit();
14session1.close();
15//事务1提交
16
17Transaction tx2 = session2.beginTransaction();
18//事务2开始
19et2.setName(“Entity2”);
20//事务2中对该数据修改
21
22tx2.commit();
23session2.close();
24//事务2提交
25
</div>

在事务2提交时，因为它提交的数据比事务1提交后的数据旧，所以hibernate会抛出一个org.hibernate.StaleObjectStateException异常。

回到前面的问题，Hibernate怎么知道事务2提交的数据比事务1提交后的数据旧呢？
因为MyEntity有个version版本控制字段。
回头看看上面的源代码中的：
MyEntity et1 = session1.load(MyEntity.class, id);
MyEntity et2 = session2.load(MyEntity.class, id);
这里，et1.version==et2.version，比如此时version=1，

当事务1提交后，该数据的版本控制字段version=version+1=2，而事务2提交时version=1<2所以Hibernate认为事务2提交的数据为过时数据，抛出异常。

这就是Hibernate乐观锁的原理机制。

我们已经知道了Hibernate乐观锁是根据version的值来判断数据是否过时，也就是说，在向数据库update某数据时，必须保证该entity里的version字段被正确地设置为update之前的值，否则hibernate乐观锁机制将无法根据version作出正确的判断。
在我们的WEB应用中，尤其应该注意这个问题。

相关阅读:
Zuul路由转发规则
logstash数据处理示例
Spring Cloud问题分析
Linux定时器工具
线上系统问题定位
spring-data-redis读写分离
日志及参数的乱码问题
Maven中使用本地jar包
给数据库用户付权
jira 跟工时有关的配置文件

原文地址：https://www.cnblogs.com/erma0-007/p/8641915.html