前提：

由于業(yè)務需要在entity Product已經實現(xiàn)了@version的樂觀鎖的基礎上再加上了悲觀鎖的控制

@Lock(value = LockModeType.PESSIMISTIC_WRITE)

Product findByType(String type);

詳情描述：

但是當進行多請求的并發(fā)測試的時候發(fā)現(xiàn)程序第一個搶占findByType的請求能正常上鎖，其它并發(fā)請求也正常進入等待，可是當?shù)谝粋€請求修改product并且提交事務釋放鎖的時候，其它等待請求準備上鎖的時候卻拋出了樂觀鎖的錯誤，為什么會出現(xiàn)這種錯誤呢？

解答：

JPA 提供的@Lock 不是直接對findByType生成的對應查詢語句后面加for update上鎖，而是按照下面的順序來上鎖的：

執(zhí)行查詢語句： select * from product where type = ?

查詢結果(id, type, version): [1001, 'NEW', 1]

通過查詢出來的id, version在執(zhí)行以下查詢

select * from product where product id = 1001 and version = 1

如果步驟2查詢有數(shù)據(jù)返回的話就生成下面的for update的查詢SQL上鎖， 如果沒有就拋出樂觀鎖異常。

select * from product where product id = 1001 and version = 1 for update

根據(jù)@Lock的上述執(zhí)行原理，當觸發(fā)多請求并發(fā)的時候，所有請求都同步執(zhí)行了上述1的查詢操作，當執(zhí)行步驟2，3的時候先上鎖的請求修改了數(shù)據(jù)和版本后，后續(xù)請求在舊的version就查詢不出來數(shù)據(jù)就拋出了樂觀鎖異常了。

建議：

一般情況下盡量避免使用悲觀鎖，對系統(tǒng)開銷很大，如果不得已需要用到的話還是直接寫for update的SQL直接上鎖。

總結

以上是生活随笔為你收集整理的jpa mysql乐观锁_JPA @Lock(value = LockModeType.PESSIMISTIC_WRITE) 悲观锁防坑的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。