Spring Boot+SQL/JPA實戰悲觀鎖和樂觀鎖

摘要： 最近在公司的業務上遇到了併發的問題，並且還是很常見的併發問題，算是低階的失誤了。由於公司業務相對比較複雜且不適合公開，在此用一個很常見的業務來還原一下場景，同時介紹悲觀鎖和樂觀鎖是如何解決這類併發問題的。 公司業務就是最常見的“訂單+賬戶”問題，在解決完公司問題後，轉頭一想，我的部落格專...

最近在公司的業務上遇到了併發的問題，並且還是很常見的併發問題，算是低階的失誤了。由於公司業務相對比較複雜且不適合公開，在此用一個很常見的業務來還原一下場景，同時介紹悲觀鎖和樂觀鎖是如何解決這類併發問題的。

公司業務就是最常見的“訂單+賬戶”問題，在解決完公司問題後，轉頭一想，我的部落格專案 ofollow,noindex">Fame 中也有同樣的問題(雖然訪問量根本完全不需要考慮併發問題...)，那我就拿這個來舉例好了。

業務還原

首先環境是：Spring Boot 2.1.0 + data-jpa + mysql + lombok

資料庫設計

對於一個有評論功能的部落格系統來說，通常會有兩個表：1.文章表 2.評論表。其中文章表除了儲存一些文章資訊等，還有個欄位儲存評論數量。我們設計一個最精簡的表結構來還原該業務場景。

article 文章表

欄位	型別	備註
id	INT	自增主鍵id
title	VARCHAR	文章標題
comment_count	INT	文章的評論數量

comment 評論表

欄位	型別	備註
id	INT	自增主鍵id
article_id	INT	評論的文章id
content	VARCHAR	評論內容

當一個使用者評論的時候，1. 根據文章id獲取到文章 2. 插入一條評論記錄 3. 該文章的評論數增加並儲存

程式碼實現

首先在maven中引入對應的依賴

<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.1.0.RELEASE</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>

<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</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>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
複製程式碼

然後編寫對應資料庫的實體類

@Data
@Entity
public class Article {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

private String title;

private Long commentCount;
}
複製程式碼

@Data
@Entity
public class Comment {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

private Long articleId;

private String content;
}
複製程式碼

接著建立這兩個實體類對應的Repository，由於spring-jpa-data的 CrudRepository 已經幫我們實現了最常見的CRUD操作，所以我們的Repository只需要繼承 CrudRepository 介面其他啥都不用做。

public interface ArticleRepository extends CrudRepository<Article, Long> {
}
複製程式碼

public interface CommentRepository extends CrudRepository<Comment, Long> {
}
複製程式碼

接著我們就簡單的實現一下Controller介面和Service實現類。

@Slf4j
@RestController
public class CommentController {

@Autowired
private CommentService commentService;

@PostMapping("comment")
public String comment(Long articleId, String content) {
try {
commentService.postComment(articleId, content);
} catch (Exception e) {
log.error("{}", e);
return "error: " + e.getMessage();
}
return "success";
}
}
複製程式碼

@Slf4j
@Service
public class CommentService {
@Autowired
private ArticleRepository articleRepository;

@Autowired
private CommentRepository commentRepository;

public void postComment(Long articleId, String content) {
Optional<Article> articleOptional = articleRepository.findById(articleId);
if (!articleOptional.isPresent()) {
throw new RuntimeException("沒有對應的文章");
}
Article article = articleOptional.get();

Comment comment = new Comment();
comment.setArticleId(articleId);
comment.setContent(content);
commentRepository.save(comment);

article.setCommentCount(article.getCommentCount() + 1);
articleRepository.save(article);
}
}
複製程式碼

併發問題分析

從剛才的程式碼實現裡可以看出這個簡單的評論功能的流程，當用戶發起評論的請求時，從資料庫找出對應的文章的實體類 Article ，然後根據文章資訊生成對應的評論實體類 Comment ，並且插入到資料庫中，接著增加該文章的評論數量，再把修改後的文章更新到資料庫中，整個流程如下流程圖。

在這個流程中有個問題，當有多個使用者同時併發評論時，他們同時進入步驟1中拿到Article，然後插入對應的Comment，最後在步驟3中更新評論數量儲存到資料庫。只是由於他們是同時在步驟1拿到的Article，所以他們的Article.commentCount的值相同，那麼在步驟3中儲存的Article.commentCount+1也相同，那麼原來應該+3的評論數量，只加了1。

我們用測試用例程式碼試一下

@RunWith(SpringRunner.class)
@SpringBootTest(classes = LockAndTransactionApplication.class, webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class CommentControllerTests {
@Autowired
private TestRestTemplate testRestTemplate;

@Test
public void concurrentComment() {
String url = "http://localhost:9090/comment";
for (int i = 0; i < 100; i++) {
int finalI = i;
new Thread(() -> {
MultiValueMap<String, String> params = new LinkedMultiValueMap<>();
params.add("articleId", "1");
params.add("content", "測試內容" + finalI);
String result = testRestTemplate.postForObject(url, params, String.class);
}).start();
}

}
}
複製程式碼

這裡我們開了100個執行緒，同時傳送評論請求，對應的文章id為1。

在傳送請求前，資料庫資料為

select * from article
複製程式碼

select count(*) comment_count from comment
複製程式碼

傳送請求後，資料庫資料為

select * from article
複製程式碼

select count(*) comment_count from comment
複製程式碼

明顯的看到在article表裡的comment_count的值不是100，這個值不一定是我圖裡的14，但是必然是不大於100的，而comment表的數量肯定等於100。

這就展示了在文章開頭裡提到的併發問題，這種問題其實十分的常見，只要有類似上面這樣評論功能的流程的系統，都要小心避免出現這種問題。

下面就用例項展示展示如何通過悲觀鎖和樂觀鎖防止出現併發資料問題，同時給出SQL方案和JPA自帶方案，SQL方案可以通用“任何系統”，甚至不限語言，而JPA方案十分快捷，如果你恰好用的也是JPA，那就可以簡單的使用上樂觀鎖或悲觀鎖。最後也會根據業務比較一下樂觀鎖和悲觀鎖的一些區別

悲觀鎖解決併發問題

悲觀鎖顧名思義就是悲觀的認為自己操作的資料都會被其他執行緒操作，所以就必須自己獨佔這個資料，可以理解為”獨佔鎖“。在java中 synchronized 和 ReentrantLock 等鎖就是悲觀鎖，資料庫中表鎖、行鎖、讀寫鎖等也是悲觀鎖。

利用SQL解決併發問題

行鎖就是操作資料的時候把這一行資料鎖住，其他執行緒想要讀寫必須等待，但同一個表的其他資料還是能被其他執行緒操作的。只要在需要查詢的sql後面加上 for update ，就能鎖住查詢的行， 特別要注意查詢條件必須要是索引列，如果不是索引就會變成表鎖，把整個表都鎖住。

現在在原有的程式碼的基礎上修改一下，先在 ArticleRepository 增加一個手動寫sql查詢方法。

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

然後把 CommentService 中使用的查詢方法由原來的 findById 改為我們自定義的方法

public class CommentService {
...

public void postComment(Long articleId, String content) {
// Optional<Article> articleOptional = articleRepository.findById(articleId);
Optional<Article> articleOptional = articleRepository.findArticleForUpdate(articleId);

...
}
}
複製程式碼

這樣我們查出來的 Article ， 在我們沒有將其提交事務之前，其他執行緒是不能獲取修改的 ，保證了同時只有一個執行緒能操作對應資料。

現在再用測試用例測一下， article.comment_count 的值必定是100。

利用JPA自帶行鎖解決併發問題

對於剛才提到的在sql後面增加 for update ，JPA有提供一個更優雅的方式，就是 @Lock 註解，這個註解的引數可以傳入想要的鎖級別。

現在在 ArticleRepository 中增加JPA的鎖方法，其中 LockModeType.PESSIMISTIC_WRITE 引數就是行鎖。

public interface ArticleRepository extends CrudRepository<Article, Long> {
...

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

同樣的只要在 CommentService 裡把查詢方法改為 findArticleWithPessimisticLock() ，再測試用例測一下，肯定不會有併發問題。而且這時看一下控制檯列印資訊，發現實際上查詢的sql還是加了 for update ，只不過是JPA幫我們加了而已。

樂觀鎖解決併發問題

樂觀鎖顧名思義就是特別樂觀，認為自己拿到的資源不會被其他執行緒操作所以不上鎖，只是在插入資料庫的時候再判斷一下資料有沒有被修改。所以悲觀鎖是限制其他執行緒，而樂觀鎖是限制自己，雖然他的名字有鎖，但是實際上不算上鎖，只是在最後操作的時候再判斷具體怎麼操作。

樂觀鎖通常為版本號機制或者CAS演算法

利用SQL實現版本號解決併發問題

版本號機制就是在資料庫中加一個欄位當作版本號，比如我們加個欄位version。那麼這時候拿到 Article 的時候就會帶一個版本號，比如拿到的版本是1，然後你對這個 Article 一通操作，操作完之後要插入到資料庫了。發現哎呀，怎麼資料庫裡的 Article 版本是2，和我手裡的版本不一樣啊，說明我手裡的 Article 不是最新的了，那麼就不能放到資料庫了。這樣就避免了併發時資料衝突的問題。

所以我們現在給article表加一個欄位version

article 文章表

欄位	型別	備註
version	INT DEFAULT 0	版本號

然後對應的實體類也增加version欄位

@Data
@Entity
public class Article {
...

private Long version;
}
複製程式碼

接著在 ArticleRepository 增加更新的方法，注意這裡是更新方法，和悲觀鎖時增加查詢方法不同。

public interface ArticleRepository extends CrudRepository<Article, Long> {
@Modifying
@Query(value = "update article set comment_count = :commentCount, version = version + 1 where id = :id and version = :version", nativeQuery = true)
int updateArticleWithVersion(Long id, Long commentCount, Long version);
}
複製程式碼

可以看到update的where有一個判斷version的條件，並且會set version = version + 1。這就保證了只有當資料庫裡的版本號和要更新的實體類的版本號相同的時候才會更新資料。

接著在 CommentService 裡稍微修改一下程式碼。

// CommentService
public void postComment(Long articleId, String content) {
Optional<Article> articleOptional = articleRepository.findById(articleId);

...

int count = articleRepository.updateArticleWithVersion(article.getId(), article.getCommentCount() + 1, article.getVersion());
if (count == 0) {
throw new RuntimeException("伺服器繁忙,更新資料失敗");
}
// articleRepository.save(article);
}
複製程式碼

首先對於 Article 的查詢方法只需要普通的 findById() 方法就行不用上任何鎖。

然後更新 Article 的時候改用新加的 updateArticleWithVersion() 方法。可以看到這個方法有個返回值，這個返回值代表更新了的資料庫行數，如果值為0的時候表示沒有符合條件可以更新的行。

這之後就可以由我們自己決定怎麼處理了， 這裡是直接回滾，spring就會幫我們回滾之前的資料操作，把這次的所有操作都取消以保證資料的一致性 。

現在再用測試用例測一下

select * from article
複製程式碼

select count(*) comment_count from comment
複製程式碼

現在看到 Article 裡的comment_count和 Comment 的數量都不是100了， 但是這兩個的值必定是一樣的了 。因為剛才我們處理的時候假如 Article 表的資料發生了衝突，那麼就不會更新到資料庫裡，這時丟擲異常使其事務回滾，這樣就能保證沒有更新 Article 的時候 Comment 也不會插入，就解決了資料不統一的問題。

這種直接回滾的處理方式使用者體驗比較差，通常來說如果判斷 Article 更新條數為0時，會嘗試重新從資料庫裡查詢資訊並重新修改，再次嘗試更新資料，如果不行就再查詢，直到能夠更新為止。當然也不會是無線的迴圈這樣的操作，會設定一個上線，比如迴圈3次查詢修改更新都不行，這時候才會丟擲異常。

利用JPA實現版本現解決併發問題

JPA對悲觀鎖有實現方式，樂觀鎖自然也是有的，現在就用JPA自帶的方法實現樂觀鎖。

首先在 Article 實體類的version欄位上加上 @Version 註解，我們進註解看一下原始碼的註釋，可以看到有部分寫到:

The following types are supported for version properties: int, Integer, short, Short, long, Long, java.sql.Timestamp.

註釋裡面說版本號的型別支援int, short, long三種基本資料型別和他們的包裝類以及Timestamp，我們現在用的是Long型別。

@Data
@Entity
public class Article {
...

@Version
private Long version;
}
複製程式碼

接著只需要在 CommentService 裡的評論流程修改回我們最開頭的“會觸發併發問題”的業務程式碼就行了。說明JPA的這種樂觀鎖實現方式是非侵入式的。

// CommentService
public void postComment(Long articleId, String content) {
Optional<Article> articleOptional = articleRepository.findById(articleId);
...

article.setCommentCount(article.getCommentCount() + 1);
articleRepository.save(article);
}
複製程式碼

和前面同樣的，用測試用例測試一下能否防止併發問題的出現。

select * from article
複製程式碼

select count(*) comment_count from comment
複製程式碼

同樣的 Article 裡的comment_count和 Comment 的數量也不是100，但是這兩個數值肯定是一樣的。看一下IDEA的控制檯會發現系統丟擲了 ObjectOptimisticLockingFailureException 的異常。

這和剛才我們自己實現樂觀鎖類似，如果沒有成功更新資料則丟擲異常回滾保證資料的一致性。如果想要實現重試流程可以捕獲 ObjectOptimisticLockingFailureException 這個異常，通常會利用AOP+自定義註解來實現一個全域性通用的重試機制，這裡就是要根據具體的業務情況來拓展了，想要了解的可以自行搜尋一下方案。

悲觀鎖和樂觀鎖比較

悲觀鎖適合寫多讀少的場景。因為在使用的時候該執行緒會獨佔這個資源，在本文的例子來說就是某個id的文章，如果有大量的評論操作的時候，就適合用悲觀鎖，否則使用者只是瀏覽文章而沒什麼評論的話，用悲觀鎖就會經常加鎖，增加了加鎖解鎖的資源消耗。

樂觀鎖適合寫少讀多的場景。由於樂觀鎖在發生衝突的時候會回滾或者重試，如果寫的請求量很大的話，就經常發生衝突，經常的回滾和重試，這樣對系統資源消耗也是非常大。

所以悲觀鎖和樂觀鎖沒有絕對的好壞，必須結合具體的業務情況來決定使用哪一種方式。另外在阿里巴巴開發手冊裡也有提到：

如果每次訪問衝突概率小於 20%，推薦使用樂觀鎖，否則使用悲觀鎖。樂觀鎖的重試次 數不得小於 3 次。

阿里巴巴建議以衝突概率20%這個數值作為分界線來決定使用樂觀鎖和悲觀鎖，雖然說這個數值不是絕對的，但是作為阿里巴巴各個大佬總結出來的也是一個很好的參考。

原文地址: Spring Boot+SQL/JPA實戰悲觀鎖和樂觀鎖