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

你的名字 2023-06-29 02:56 27阅读 0赞

转载自：[https://blog.csdn.net/moshowgame/article/details/103086074][https_blog.csdn.net_moshowgame_article_details_103086074]

## 叙述 ##

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

### 悲观锁与并发 ###

**悲观锁（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);

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

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

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

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

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

[https_blog.csdn.net_moshowgame_article_details_103086074]: https://blog.csdn.net/moshowgame/article/details/103086074
[20200110135223830.png]: https://img-blog.csdnimg.cn/20200110135223830.png