Java 中的悲觀鎖和樂觀鎖的實現

1、定義sql

1.悲觀鎖:即很悲觀,每次拿數據的時候都以爲數據會被人更改,因此拿數據的時候就把這條記錄鎖掉,這樣別人就無法改這條數據了,一直到你的鎖釋放。數據庫

2.樂觀鎖:即很樂觀,查詢數據的時候總以爲不會有人更改數據,等到更新的時候再判斷這個數據有沒有被人更改,有人更改了則本次更新失敗。併發

 

 

2、實現過程性能

 

2.悲觀鎖:悲觀鎖的實現採用的數據庫內部的鎖機制,一個典型的倚賴數據庫的悲觀鎖調用:線程

select * from account where name=」張三」 for update
  這條sql 語句鎖定了account 表中全部符合檢索條件(name=」Erica」)的記錄。本次事務提交以前(事務提交時會釋放事務過程當中的鎖),外界沒法修改這些記錄。也就是咱們能夠在查詢數據的時候先用for update把這條數據鎖住,而後更改完這條數據再提交。這樣別的線程無法更新這條數據,也就保證了不會丟失更新。事務

2.1.悲觀鎖帶來的性能問題。咱們試想一個場景:如一個金融系統,當某個操做員讀取用戶的數據,並在讀出的用戶數據的基礎上進行修改時(如更改用戶賬戶餘額),若是採用悲觀鎖機制,也就意味着整個操做過程當中(從操做員讀出數據、開始修改直至提交修改結果的全過程),數據庫記錄始終處於加鎖狀態,能夠想見,若是面對幾百上千個併發,這樣的狀況將致使怎樣的後果?因此咱們這個時候可使用樂觀鎖。基礎

 

 

1.樂觀鎖:樂觀鎖的實現能夠經過在表裏面加一個版本號的形式,下面是一個實例。date

講解:也就是每一個人更新的時候都會判斷當前的版本號是否跟我查詢出來獲得的版本號是否一致,不一致就更新失敗,一致就更新這條記錄並更改版本號。select

 

2、使用場景im

像樂觀鎖適用於寫比較少的狀況下,即衝突真的不多發生的時候,這樣能夠省去了鎖的開銷,加大了系統的整個吞吐量。但若是常常產生衝突,

上層應用會不斷的進行retry,這樣反卻是下降了性能,因此這種狀況下用悲觀鎖就比較合適

相關文章
相關標籤/搜索