Java中数据库常用的两把锁之乐观锁和悲观锁

  在写入数据库的时候需要有锁,比如同时写入数据库的时候会出现丢数据,那么就需要锁机制。

  数据锁分为乐观锁和悲观锁,那么它们使用的场景如下:

  1. 乐观锁适用于写少读多的情景,因为这种乐观锁相当于JAVA的CAS,所以多条数据同时过来的时候,不用等待,可以立即进行返回。

  2. 悲观锁适用于写多读少的情景,这种情况也相当于JAVA的synchronized,reentrantLock等,大量数据过来的时候,只有一条数据可以被写入,其他的数据需要等待。执行完成后下一条数据可以继续。

  他们实现的方式上有所不同,乐观锁采用版本号的方式,即当前版本号如果对应上了就可以写入数据,如果判断当前版本号不一致,那么就不会更新成功,比如 update table set column = value where version=${version} and otherKey = ${otherKey}。悲观锁实现的机制一般是在执行更新语句的时候采用for update方式,比如 update table set column='value' for update。这种情况where条件呢一定要涉及到数据库对应的索引字段,这样才会是行级锁,否则会是表锁,这样执行速度会变慢。

  下面我就弄一个spring boot(springboot 2.1.1 + mysql + lombok + aop + jpa)工程,然后逐渐的实现乐观锁和悲观锁。假设有一个场景,有一个catalog商品目录表,然后还有一个browse浏览表,假如一个商品被浏览了,那么就需要记录下浏览的user是谁,并且记录访问的总数。

  表的结构非常简单:  

create table catalog (
id int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
name varchar(50) NOT NULL DEFAULT '' COMMENT '商品名称',
browse_count int(11) NOT NULL DEFAULT 0 COMMENT '浏览数',
version int(11) NOT NULL DEFAULT 0 COMMENT '乐观锁,版本号',
PRIMARY KEY(id)
) ENGINE=INNODB DEFAULT CHARSET=utf8;

CREATE table browse (
id int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
cata_id int(11) NOT NULL COMMENT '商品ID',
user varchar(50) NOT NULL DEFAULT '' COMMENT '',
create_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '创建时间',
PRIMARY KEY(id)
) ENGINE=INNODB DEFAULT CHARSET=utf8;

   POM.XML的依赖如下:  

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <parent>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-parent</artifactId>
 <version>2.1.1.RELEASE</version>
 <relativePath/> <!-- lookup parent from repository -->
 </parent>
 <groupId>com.hqs</groupId>
 <artifactId>dblock</artifactId>
 <version>1.0-SNAPSHOT</version>
 <name>dblock</name>
 <description>Demo project for Spring Boot</description>

 <properties>
 <java.version>1.8</java.version>
 </properties>

 <dependencies>
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-web</artifactId>
 </dependency>

 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-devtools</artifactId>
 <scope>runtime</scope>
 </dependency>
 <dependency>
 <groupId>mysql</groupId>
 <artifactId>mysql-connector-java</artifactId>
 <scope>runtime</scope>
 </dependency>
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-test</artifactId>
 <scope>test</scope>
 </dependency>
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-data-jpa</artifactId>
 </dependency>
 <dependency>
 <groupId>mysql</groupId>
 <artifactId>mysql-connector-java</artifactId>
 </dependency>
 <dependency>
 <groupId>org.projectlombok</groupId>
 <artifactId>lombok</artifactId>
 <optional>true</optional>
 </dependency>

 <!-- aop -->
 <dependency>
 <groupId>org.aspectj</groupId>
 <artifactId>aspectjweaver</artifactId>
 <version>1.8.4</version>
 </dependency>

 </dependencies>

 <build>
 <plugins>
 <plugin>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-maven-plugin</artifactId>
 </plugin>
 </plugins>
 </build>

</project>

     项目的结构如下:

  介绍一下项目的结构的内容:

  entity包: 实体类包。

  repository包:数据库repository

  service包: 提供服务的service

  controller包: 控制器写入用于编写requestMapping。相关请求的入口类

  annotation包: 自定义注解,用于重试。

  aspect包: 用于对自定义注解进行切面。

  DblockApplication: springboot的启动类。

  DblockApplicationTests: 测试类。

  咱们看一下核心代码的实现,参考如下,使用dataJpa非常方便,集成了CrudRepository就可以实现简单的CRUD,非常方便,有兴趣的同学可以自行研究。

  实现乐观锁的方式有两种:

  1. 更新的时候将version字段传过来,然后更新的时候就可以进行version判断,如果version可以匹配上,那么就可以更新(方法:updateCatalogWithVersion)。

  2. 在实体类上的version字段上加入version,可以不用自己写SQL语句就可以它就可以自行的按照version匹配和更新,是不是很简单。 

public interface CatalogRepository extends CrudRepository<Catalog, Long> {

 @Query(value = "select * from Catalog a where a.id = :id for update", nativeQuery = true)
 Optional<Catalog> findCatalogsForUpdate(@Param("id") Long id);

 @Lock(value = LockModeType.PESSIMISTIC_WRITE) //代表行级锁
 @Query("select a from Catalog a where a.id = :id")
 Optional<Catalog> findCatalogWithPessimisticLock(@Param("id") Long id);

 @Modifying(clearAutomatically = true) //修改时需要带上
 @Query(value = "update Catalog set browse_count = :browseCount, version = version + 1 where id = :id " +
 "and version = :version", nativeQuery = true)
 int updateCatalogWithVersion(@Param("id") Long id, @Param("browseCount") Long browseCount, @Param("version") Long version);

}

  实现悲观锁的时候也有两种方式:

  1. 自行写原生SQL,然后写上for update语句。(方法:findCatalogsForUpdate)

  2. 使用@Lock注解,并且设置值为LockModeType.PESSIMISTIC_WRITE即可代表行级锁。

  还有我写的测试类,方便大家进行测试:  

package com.hqs.dblock;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.web.client.TestRestTemplate;
import org.springframework.test.context.junit4.SpringRunner;
import org.springframework.util.LinkedMultiValueMap;
import org.springframework.util.MultiValueMap;

@RunWith(SpringRunner.class)
@SpringBootTest(classes = DblockApplication.class, webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class DblockApplicationTests {

 @Autowired
 private TestRestTemplate testRestTemplate;

 @Test
 public void browseCatalogTest() {
 String url = "http://localhost:8888/catalog";
 for(int i = 0; i < 100; i++) {
 final int num = i;
 new Thread(() -> {
 MultiValueMap<String, String> params = new LinkedMultiValueMap<>();
 params.add("catalogId", "1");
 params.add("user", "user" + num);
 String result = testRestTemplate.postForObject(url, params, String.class);
 System.out.println("-------------" + result);
 }
 ).start();
 }
 }

 @Test
 public void browseCatalogTestRetry() {
 String url = "http://localhost:8888/catalogRetry";
 for(int i = 0; i < 100; i++) {
 final int num = i;
 new Thread(() -> {
 MultiValueMap<String, String> params = new LinkedMultiValueMap<>();
 params.add("catalogId", "1");
 params.add("user", "user" + num);
 String result = testRestTemplate.postForObject(url, params, String.class);
 System.out.println("-------------" + result);
 }
 ).start();
 }
 }
}

  调用100次,即一个商品可以浏览一百次,采用悲观锁,catalog表的数据都是100,并且browse表也是100条记录。采用乐观锁的时候,因为版本号的匹配关系,那么会有一些记录丢失,但是这两个表的数据是可以对应上的。

  乐观锁失败后会抛出ObjectOptimisticLockingFailureException,那么我们就针对这块考虑一下重试,下面我就自定义了一个注解,用于做切面。

package com.hqs.dblock.annotation;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface RetryOnFailure {
}

  针对注解进行切面,见如下代码。我设置了最大重试次数5,然后超过5次后就不再重试。  

package com.hqs.dblock.aspect;

import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
import org.hibernate.StaleObjectStateException;
import org.springframework.orm.ObjectOptimisticLockingFailureException;
import org.springframework.stereotype.Component;

@Slf4j
@Aspect
@Component
public class RetryAspect {
 public static final int MAX_RETRY_TIMES = 5;//max retry times

 @Pointcut("@annotation(com.hqs.dblock.annotation.RetryOnFailure)") //self-defined pointcount for RetryOnFailure
 public void retryOnFailure(){}

 @Around("retryOnFailure()") //around can be execute before and after the point
 public Object doConcurrentOperation(ProceedingJoinPoint pjp) throws Throwable {
 int attempts = 0;

 do {
 attempts++;
 try {
 pjp.proceed();
 } catch (Exception e) {
 if(e instanceof ObjectOptimisticLockingFailureException ||
  e instanceof StaleObjectStateException) {
  log.info("retrying....times:{}", attempts);
  if(attempts > MAX_RETRY_TIMES) {
  log.info("retry excceed the max times..");
  throw e;
  }
 }

 }
 } while (attempts < MAX_RETRY_TIMES);
 return null;
 }
}

  大致思路是这样了,欢迎拍砖。

  GIT代码:https://github.com/stonehqs/dblock

  到此这篇关于数据库常用的两把锁之乐观锁和悲观锁的文章就介绍到这了,更多相关数据库锁 乐观锁 悲观锁内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • SpringBoot整合MyBatis实现乐观锁和悲观锁的示例

    本文以转账操作为例,实现并测试乐观锁和悲观锁. 全部代码:https://github.com/imcloudfloating/Lock_Demo GitHub Page:https://cloudli.top 死锁问题 当 A, B 两个账户同时向对方转账时,会出现如下情况: 时刻 事务 1 (A 向 B 转账) 事务 2 (B 向 A 转账) T1 Lock A Lock B T2 Lock B (由于事务 2 已经 Lock A,等待) Lock A (由于事务 1 已经 Lock B,等

  • 实例讲解MySQL中乐观锁和悲观锁

    数据库管理系统中并发控制的任务是确保在多个事务同时存取数据库中同一数据不破坏事务的隔离性和统一性以及数据库的统一性 乐观锁和悲观锁式并发控制主要采用的技术手段 悲观锁 在关系数据库管理系统中,悲观并发控制(悲观锁,PCC)是一种并发控制的方法.它可以阻止一个事务以影响其他用户的方式来修改数据.如果一个事务执行的操作的每行数据应用了锁,那只有当这个事务锁释放,其他事务才能够执行与该锁冲突的操作 悲观并发控制主要应用于数据争用激烈的环境,以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本环境

  • Mysql悲观锁和乐观锁的使用示例

    悲观锁 悲观锁,认为数据是悲观的.当我们查询数据的时候加上锁.防止其他线程篡改,直到对方拿到锁,才能修改. 比如,有如下的表.status=1表示可以下单,status=2表示不可以下订单.假如在并发的过程中有两个用户同时查到status=1,那么从逻辑上来说都可以去新增订单,但是会造成商品超卖. 如下例子 CREATE TABLE `goods` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL,

  • Hibernate悲观锁和乐观锁实例详解

    本文研究的主要是Hibernate悲观锁和乐观锁的全部内容,具体介绍如下. 悲观锁 悲观锁通常是由数据库机制实现的,在整个过程中把数据锁住(查询时),只要事物不释放(提交/回滚),那么任何用户都不能查看或修改. 下面我们通过一个案例来说明. 案例:假设货物库存为1000,当核算员1取出了数据准备修改,但临时有事,就走了.期间核算员2取出了数据把数量减去200,然后核算员1回来了把刚才取出的数量减去200,这就出现了一个问题,核算员1并没有在800的基础上做修改.这就是所谓的更新丢失,采用悲观锁可

  • mysql 悲观锁与乐观锁的理解及应用分析

    本文实例讲述了mysql 悲观锁与乐观锁.分享给大家供大家参考,具体如下: 悲观锁与乐观锁是人们定义出来的概念,你可以理解为一种思想,是处理并发资源的常用手段. 不要把他们与mysql中提供的锁机制(表锁,行锁,排他锁,共享锁)混为一谈. 一.悲观锁 顾名思义,就是对于数据的处理持悲观态度,总认为会发生并发冲突,获取和修改数据时,别人会修改数据.所以在整个数据处理过程中,需要将数据锁定. 悲观锁的实现,通常依靠数据库提供的锁机制实现,比如mysql的排他锁,select .... for upd

  • Hibernate实现悲观锁和乐观锁代码介绍

    四种隔离机制不要忘记:(1,2,4,8) 1.read-uncommitted:能够去读那些没有提交的数据(允许脏读的存在) 2.read-committed:不会出现脏读,因为只有另一个事务提交才会读取来结果,但仍然会出现不可重复读和幻读现象. 4.repeatable read: MySQL 默认.可重复读,读数据读出来之后给它加把锁,其他人先别更新,等我用完了你再更新.你的事务没完,其他事务就不可能改这条记录. 8.serializable:序列化,最高级别.一个一个来,不去并发.效率最低

  • 浅析Sql server锁,独占锁,共享锁,更新锁,乐观锁,悲观锁

    锁有两种分类方法.(1) 从数据库系统的角度来看锁分为以下三种类型: •独占锁(Exclusive Lock)独占锁锁定的资源只允许进行锁定操作的程序使用,其它任何对它的操作均不会被接受.执行数据更新命令,即INSERT. UPDATE 或DELETE 命令时,SQL Server 会自动使用独占锁.但当对象上有其它锁存在时,无法对其加独占锁.独占锁一直到事务结束才能被释放. •共享锁(Shared Lock)共享锁锁定的资源可以被其它用户读取,但其它用户不能修改它.在SELECT 命令执行时,

  • Java并发问题之乐观锁与悲观锁

    首先介绍一些乐观锁与悲观锁: 悲观锁:总是假设最坏的情况,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会阻塞直到它拿到锁.传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁.再比如Java里面的同步原语synchronized关键字的实现也是悲观锁. 乐观锁:顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版

  • 基于Django的乐观锁与悲观锁解决订单并发问题详解

    前言 订单并发这个问题我想大家都是有一定认识的,这里我说一下我的一些浅见,我会尽可能的让大家了解如何解决这类问题. 在解释如何解决订单并发问题之前,需要先了解一下什么是数据库的事务.(我用的是mysql数据库,这里以mysql为例) 1)     事务概念 一组mysql语句,要么执行,要么全不不执行.  2)  mysql事务隔离级别 Read Committed(读取提交内容) 如果是Django2.0以下的版本,需要去修改到这个隔离级别,不然乐观锁操作时无法读取已经被修改的数据 Repea

  • thinkPHP框架乐观锁和悲观锁实例分析

    本文实例讲述了thinkPHP框架乐观锁和悲观锁.分享给大家供大家参考,具体如下: 乐观锁: 例子对于一个正在出售的火爆商品,同一个时间,同时有10个人同时发起了10个线程来购买,10个线程读取到数据库的库存有20件和version为9. 那么乐观锁读取num数量和version版本两个字段,在更新的结果时候,我们就要更新条件where version=9这条语句,具体UPDATE goods SET num=num-1,version=version+1 WHERE version=9 and

随机推荐