前言
大量的请求,或者同时的操作,容易导致系统在业务上发生并发的问题. 通常讲到并发,解决方案无非就是前端限制重复提交,后台进行悲观锁或者乐观锁限制.
悲观锁与并发
悲观锁(Pessimistic Lock),顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到解锁,可以理解为独占锁。在java中synchronized和ReentrantLock重入锁等锁就是悲观锁,数据库中表锁、行锁、读写锁等也是悲观锁。
利用SQL的for update解决并发问题
行锁就是操作数据的时候把这一行数据锁住,其他线程想要读写必须等待,但同一个表的其他数据还是能被其他线程操作的。只要在需要查询的sql后面加上for update,就能锁住查询的行,特别要注意查询条件必须要是索引列,如果不是索引就会变成表锁,把整个表都锁住。
1
2
3
4
|
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.
1
2
3
4
5
|
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,则可以
1
2
|
@NamedQuery (name= "lockArticle" ,query= "select a from Article a where a.id = :id" ,lockMode = PESSIMISTIC_READ) public class Article |
如果用entityManager的方式,则可以设置LocakMode:
1
2
3
4
|
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到数据库了,进行报错把,这样就避免了并发时数据冲突的问题。
1
2
3
4
5
|
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); } |
1
2
3
4
5
6
7
8
9
10
11
12
|
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注解
1
2
3
4
5
6
7
8
9
|
@Data @Entity public class Article{ @Id private Long id; //...... @Version private Integer version; } |
1
2
3
|
Article article = entityManager.find(Article. class , id); entityManager.lock(article , LockModeType.OPTIMISTIC); entityManager.refresh(article , LockModeType.READ); |
什么时候用悲观锁或者乐观锁
悲观锁适合写多读少的场景。因为在使用的时候该线程会独占这个资源,就适合用悲观锁,否则用户只是浏览文章的话,用悲观锁就会经常加锁,增加了加锁解锁的资源消耗。
乐观锁适合写少读多的场景。由于乐观锁在发生冲突的时候会回滚或者重试,如果写的请求量很大的话,就经常发生冲突,结合事务会有经常的回滚和重试,这样对系统资源消耗也是非常大。
所以悲观锁和乐观锁没有绝对的好坏,必须结合具体的业务情况来决定使用哪一种方式。另外在阿里巴巴开发手册里也有提到:
如果每次访问冲突概率小于 20%,推荐使用乐观锁,否则使用悲观锁。乐观锁的重试次数不得小于3次。
阿里巴巴建议以冲突概率20%这个数值作为分界线来决定使用乐观锁和悲观锁,虽然说这个数值不是绝对的,但是作为阿里巴巴各个大佬总结出来的也是一个很好的参考。
以上为个人经验,希望能给大家一个参考,也希望大家多多支持服务器之家。
原文链接:https://zhengkai.blog.csdn.net/article/details/103086074