数据库中应用级别并发解决之道一:锁

lero

前言：为什么需要锁？

开发系统中，我们需要考虑各种各样的潜在问题。其中一个就有著名的并发性问题。

比如开发了一个XXX管理系统，在多用户环境中，在同一时刻可能会有多个用户更新相同的记录，这会产生冲突，尤其是在很重要的数据面前：比如银行数据，财务数据等。

典型的冲突有：

1）丢失更新：一个事务的更新覆盖了其它事务的更新结果，就是所谓的更新丢失。例如：在用户余额表里，由于某种原因，同一时刻管理员张三把某条记录的余额值值从100改为50,管理员李四把同一条记录的余额值从50改为100，则管理员张三丢失了他的更新，但是他不知道。

2） 脏读：当一个事务读取其它完成一半事务的记录时，就会发生脏读取。例如：在用户的余额表里，同一时刻管理员张三和李四同时看到了某条记录的余额值都是80，然后管理员李四把该记录的余额值改为20，然后管理员张三读到的余额值仍为原来的80。

为了解决这些并发带来的问题。 我们需要引入并发控制机制。

正文：常用的两种锁详解

悲观锁：对数据库而言，它感觉每一个对他操作的程序都有可能产生并发，那么每次操作它，都出于锁定状态，一次只接受一个操作，其它任何用户都不能读取或修改。

优点是：

悲观并发控制实际上是“先取锁再访问”的保守策略，为数据处理的安全提供了保证。

缺点是：

1）在效率方面，处理加锁的机制会让数据库产生额外的开销，还有增加产生死锁的机会。

2）在只读型事务处理中由于不会产生冲突，必要使用锁，这样做只能增加系统负载；还有会降低了并行性，一个事务如果锁定了某行数据，其他事务就必须等待该事务处理完才可以处理那行数。

数据库中悲观锁调用：

eg: select * from t_user where name=”lero” forupdate

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

Hiberante中悲观锁实现方式：

String hqlStr ="from UserEntity as user where user.name=‘lero‘";

Query query = session.createQuery(hqlStr);

query.setLockMode("user",LockMode.UPGRADE); // 加锁

List userList = query.list();// 执行查询，获取数据

其中：query.setLockMode对查询语句中，特定别名所对应的记录进行加锁（我们为UserEntity类指定了一个别名“user”），这里也就是对返回的所有 user 记录进行加锁。

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的 for update nowait子句实现加锁。

上面这两种锁机制是我们在应用层较为常用的，加锁一般通过以下方法实现：

Criteria.setLockMode

Query.setLockMode

Session.lock

注意，只有在查询开始之前（也就是 Hiberate生成 SQL之前）设定加锁，才会真正通过数据库的锁机制进行加锁处理

乐观锁：对数据库而言，它认为数据一般情况下不会造成冲突，只在提交更新操作时检查是否违反数据完整性。若真的发生了冲突，再把错误信息返回。常采用给数据库表加上一字段比如版本号，时间戳,来校验是否并发。

优点是：

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

缺点是：需要加一些额外的字段去处理可能出现的冲突。

Hiberante中乐观锁实现方式：

下面以版本号字段控来制锁定，在实体里增加一个version成员变量。

@Entity

@Table(name = "o_user")

public class UserEntity {

@Version

private int version;

private String name;l

}

版本号的作用只是将最初获取的版本号与最后完成事务前获取的版本号进行比较,作为是否提交操作成功的依据。

下面模拟多个Sesssion来测试：

/*

* 模拟多个session操作t_user数据表

*/

Sessionsession1=sessionFactory.openSession();

Session session2=sessionFactory.openSession();

UserEntity u1=( UserEntity)session1.createQuery("from UserEntity as user where user.name=”lero").uniqueResult();

UserEntity u2=( UserEntity)session2.createQuery("from UserEntity as user where user.name='lero'").uniqueResult();

//这时候，两个版本号是相同的

System.out.println("v1="+u1.getVersion()+"--v2="+u2.getVersion());

Transaction tx1=session1.beginTransaction();

u1.setName("he");

tx1.commit();

//这时候，两个版本号是不同的，其中一个的版本号递增了

System.out.println("v1="+u1.getVersion()+"--v2="+u2.getVersion());

Transaction tx2=session2.beginTransaction();

stu2.setName("she");

tx2.commit();

运行结果：报错如下

Exception in thread "main" org.hibernate.StaleObjectStateException:Row was updated or deleted by another transaction (or unsaved-value mapping wasincorrect)就说明了乐观锁生效了。

总结 乐观锁和悲观锁适用场景：

在实际生产环境里边,如果并发量不大且不允许脏读，可以使用悲观锁解决并发问题；但如果系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法.喜欢我们的小伙伴可以点个关注，如果有疑问欢迎大家评论区留言，我们会第一时间给大家解答。