专栏首页攻城狮的那点事Spring Boot2+JPA之悲观锁和乐观锁实战

Spring Boot2+JPA之悲观锁和乐观锁实战

在我们开发的项目中,大量的请求,或者同时的操作,很容易导致系统在业务上发生并发的问题。通常讲到并发,解决方案无非就是前端限制重复提交,后台进行悲观锁或者乐观锁限制。

悲观锁与并发

悲观锁(Pessimistic Lock),顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到解锁,可以理解为独占锁。在java中synchronized和ReentrantLock重入锁等锁就是悲观锁,数据库中表锁、行锁、读写锁等也是悲观锁。

利用SQL的for update解决并发问题

行锁就是操作数据的时候把这一行数据锁住,其他线程想要读写必须等待,但同一个表的其他数据还是能被其他线程操作的。只要在需要查询的sql后面加上for update,就能锁住查询的行,特别要注意查询条件必须要是索引列,如果不是索引就会变成表锁,把整个表都锁住。

public interface ArticleRepository extends JpaRepository<Article, Long> {
    @Query(value = "select * from article a where a.id = :id for update", nativeQuery = true)
    Optional<Article> findArticleForUpdate(Long id);
}

利用JPA的@Lock行锁注解解决并发问题

如果说for update的做法太原始,那么JPA有提供一个更加优雅的方法,就是@Lock注解 。

为Repository添加JPA的锁方法,其中LockModeType.PESSIMISTIC_WRITE参数就是行锁。

关于LockModeType这个类型,可以在这找到文档 https://docs.oracle.com/javaee/7/api/javax/persistence/LockModeType.html

  • NONE: No lock.
  • OPTIMISTIC: Optimistic lock.
  • OPTIMISTIC_FORCE_INCREMENT: Optimistic lock, with version update.
  • PESSIMISTIC_FORCE_INCREMENT: Pessimistic write lock, with version update.
  • PESSIMISTIC_READ: Pessimistic read lock.
  • PESSIMISTIC_WRITE: Pessimistic write lock.
  • READ: Synonymous with OPTIMISTIC.
  • WRITE: Synonymous with OPTIMISTIC_FORCE_INCREMENT.
public interface ArticleRepository extends JpaRepository<Article, Long> {

    @Lock(value = LockModeType.PESSIMISTIC_WRITE)
    @Query("select a from Article a where a.id = :id")
    Optional<Article> findArticleWithPessimisticLock(Long id);
}

如果是@NameQuery,则可以

@NamedQuery(name="lockArticle",query="select a from Article a where a.id = :id",lockMode = PESSIMISTIC_READ)
public class Article

如果用entityManager的方式,则可以设置LocakMode:

Query query = entityManager.createQuery("from Article where articleId = :id");
  query.setParameter("id", id);
  query.setLockMode(LockModeType.PESSIMISTIC_WRITE);
  query.getResultList();

乐观锁与并发

乐观锁(Optimistic Lock),顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在提交更新的时候会判断一下在此期间别人有没有去修改。所以悲观锁是限制其他线程,而乐观锁是限制自己,虽然他的名字有锁,但是实际上不算上锁,通常为version版本号机制,还有CAS算法。

利用version字段解决并发问题

版本号机制就是在数据库中加一个字段version当作版本号。那么获取Article的时候就会带一个版本号,比如version=1,然后你对这个Article一波操作,操作完之后要插入到数据库了。校验一下version版本号,发现在数据库里对应Article记录的version=2,这和我手里的版本不一样啊,说明提交的Article不是最新的,那么就不能update到数据库了,进行报错把,这样就避免了并发时数据冲突的问题。

public interface ArticleRepository extends JpaRepository<Article, Long> {
    @Modifying
    @Query(value = "update article set content= :content, version = version + 1 where id = :id and version = :version", nativeQuery = true)
    int updateArticleWithVersion(Long id, String content, Long version);
}
public void postComment(Long articleId, String content) {
  //get article
    Optional<Article> articleOptional = articleRepository.findById(articleId);
    //update with Optimistic Lock
    int count = articleRepository.updateArticleWithVersion(article.getId(), content, article.getVersion());
   
    if (count == 0) {
        throw new RuntimeException("更新数据失败,请刷新重试");
    }else{
      articleRepository.save(article);
    }
}

利用JPA的@Version版本机制解决并发问题

有没有更优雅的方式?当然,必须有,那就是JPA自带的@Version方式实现乐观锁。

  • each entity class must have only one version attribute。每个实体类只能有一个@Version字段,不能多
  • it must be placed in the primary table for an entity mapped to several tables。对于映射到多个表的实体,必须将其放置在主表中
  • type of a version attribute must be one of the following: int, Integer, long, Long, short, Short, java.sql.Timestamp

@Version支持的类型必须是以下类型:

  • int
  • Integer
  • long
  • Long
  • short
  • Short
  • java.sql.Timestamp

首先在Article实体类的version字段上加上@Version注解

@Data
@Entity
public class Article{
    @Id
    private Long id;
   //......
    @Version
    private Integer version;
}
Article article = entityManager.find(Article.class, id);
entityManager.lock(article , LockModeType.OPTIMISTIC);
entityManager.refresh(article , LockModeType.READ);

什么时候用悲观锁或者乐观锁

悲观锁适合写多读少的场景。因为在使用的时候该线程会独占这个资源,就适合用悲观锁,否则用户只是浏览文章的话,用悲观锁就会经常加锁,增加了加锁解锁的资源消耗。

乐观锁适合写少读多的场景。由于乐观锁在发生冲突的时候会回滚或者重试,如果写的请求量很大的话,就经常发生冲突,结合事务会有经常的回滚和重试,这样对系统资源消耗也是非常大。

所以悲观锁和乐观锁没有绝对的好坏,必须结合具体的业务情况来决定使用哪一种方式。另外在阿里巴巴开发手册里也有提到:

如果每次访问冲突概率小于 20%,推荐使用乐观锁,否则使用悲观锁。乐观锁的重试次数不得小于3次。

阿里巴巴建议以冲突概率20%这个数值作为分界线来决定使用乐观锁和悲观锁,虽然说这个数值不是绝对的,但是作为阿里巴巴各个大佬总结出来的也是一个很好的参考。

文章来源:https://blog.csdn.net/moshowgame/article/details/103086074

本文分享自微信公众号 - 攻城狮的那点事(gh_e40249fc5212)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-01-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Java基础面试题整理

    JRE是java运行环境包含了jvm虚拟机等等,简单的说如果要运行java程序只需要JRE即可。

    攻城狮的那点事
  • Java8中遍历Map的常用四种方式

    如果你现在正在使用Java8,那一定要看看在Java8中,对map操作遍历可以采用第4种方式哦。

    攻城狮的那点事
  • JVM基本结构及内存模型及优化

    JVM是Java Virtual Machine(Java虚拟机)的缩写,JVM是一种用于计算设备的规范,它是一个虚构出来的计算机,是通过在实际的计算机上仿真模...

    攻城狮的那点事
  • SQL Server通过整理索引碎片和重建索引提高速度

    本文章转载:http://database.51cto.com/art/201108/282408.htm

    跟着阿笨一起玩NET
  • 面向对象设计的 10 条戒律

    这也不是Jon Skeet / Martin Fowler / Jeff Atwood / Joel Spolsky(可以用你最喜欢的技术专家的替换这些名字)说...

    哲洛不闹
  • 腾讯云安全白皮书:2015年上半年安全威胁大起底

    日前,腾讯云首次发布《腾讯云安全白皮书》(以下简称“白皮书”),其中披露了《腾讯云安全运营数据报告(2015年上半年)》。 数据报告显示,2015年1月至7月 ...

    腾讯数据中心
  • C语言(局部标签)

    gcc允许我们在任何内嵌的代码块中声明局部标签,所谓的局部标签就跟常规标签差不多,但你只能在其声明的代码块内引用它。

    用户2617681
  • 分类算法实例二:用Softmax算法预测葡萄酒质量

    魏晓蕾
  • 《简明 Python 教程》学习笔记-函数

    回来后,重心一直放在地方站那边了,这边只是偶尔回来看看同时回复一下大家的留言,这两天可以放松一下心神,让自己静静,考虑码码字的问题,python在假期过后就没看...

    汐楓
  • springboot(15)Spring Security

    IT故事会

扫码关注云+社区

领取腾讯云代金券

玩转腾讯云 有奖征文活动