1. 程式人生 > >秒懂樂觀鎖與悲觀鎖

秒懂樂觀鎖與悲觀鎖

在資料庫的改查操作當中,多使用者的併發操作極有可能產生衝突。產生衝突的結果大概有兩種:更新覆蓋[0]和髒讀[1]。

應對方法便是對併發操作的控制

最常用的策略是加鎖,鎖有兩種,一種叫悲觀鎖,另一種叫樂觀鎖

悲觀鎖:

  • 顧名思義,就是從悲觀的角度去看待解決問題,假設會發生衝突,所以你要獨佔(鎖住)整個資源,寧可阻塞後來的操作,也要保證資料完整性。悲觀鎖雖然悲觀的處理問題,但是其策略強有力的保證了資料的完整性。悲觀鎖的粒度最小達到了行級(只鎖定該行),有效的減小了衝突,提高系統的吞吐量。

樂觀鎖:

  • 顧名思義,就是從樂觀的角度去看待解決問題,假設不會發生衝突,大家都可以來查,只是在改動的時候需要檢查是否是最新的資料,倘若資料不是最新的,則駁回改動。也就是說,倘若執行樂觀鎖策略,需要多增加一個欄位(一般是Version)用來判斷資料是否是最新的。然後更新後Version++。那麼對查詢沒有限制,所以發生衝突時的影響一般是造成髒讀。

應用:

悲觀鎖與樂觀鎖沒有好壞優劣之分,它們擅長應對不同的情況。

  • 悲觀鎖適合多改動的場景,最好是併發/資料量小或者不允許髒讀的場景。(例如balance)
  • 樂觀鎖適合多查詢的場景,並且對髒讀要求不高的場景。(只查不改的,例如log,report。)

實現:

樂觀鎖在不同資料庫有不同的實現方式,一般需要自己動手實現寫SQL語句,在流行的框架比如Hibernate中,已經封裝好了實現,在使用樂觀鎖策略的欄位前加@Version, Hibernate在更新記錄時會自動校驗該欄位。

腳註:
[0]更新覆蓋: 一個事務的更新操作結果併發的被其它事務的更新操作結果覆蓋。
[1]髒讀:當一個事務讀取的資料由於其它併發事務的操作造成的資料不真實時,就發生了髒讀。

相關推薦

樂觀悲觀

在資料庫的改查操作當中,多使用者的併發操作極有可能產生衝突。產生衝突的結果大概有兩種:更新覆蓋[0]和髒讀[1]。 應對方法便是對併發操作的控制。 最常用的策略是加鎖,鎖有兩種,一種叫悲觀鎖,另一種叫樂觀鎖。 悲觀鎖: 顧名思義,就是從悲觀的角度去

樂觀悲觀

到你 目前 from 提高 選中 base 排它鎖 之前 準備 在多用戶環境中,在同一時間可能會有多個用戶更新相同的記錄,這會產生沖突。這就是著名的並發性問題。 典型的沖突有: l 丟失更新:一個事務的更新覆蓋了其它事務的更新結果,就是所謂的更新丟失。例如:用戶A把值從6改

樂觀悲觀的簡單區分

個數 行數 但是 分布式系 修改 讀寫 使用場景 狀態 控制 1、鎖的出現,是因為並發讀寫同一個數據的時候,需要進行數據完備性的保護,避免臟讀、臟寫等。 2、樂觀鎖,需要在事務中加鎖,在讀取數據的時候,不必在意數據是否已經被修改了(即允許臟讀);但是在寫入數據的時候,要檢查

[數據庫事務]詳解七: 深入理解樂觀悲觀

ood insert 影響 hiberna memcach begin 策略 goods 其它 註明: 本文轉載自http://www.hollischuang.com/archives/934在數據庫的鎖機制中介紹過,數據庫管理系統(DBMS)中的並發控制的任務是確保在

Java並發問題--樂觀悲觀以及樂觀的一種實現方式-CAS

RF -- 指針 locking water 更多 錯誤 創建 判斷 首先介紹一些樂觀鎖與悲觀鎖: 悲觀鎖:總是假設最壞的情況,每次去拿數據的時候都認為別人會修改,所以每次在拿數據的時候都會上鎖,這樣別人想拿這個數據就會阻塞直到它拿到鎖。傳統的關系型數據庫裏邊就用到了很多這

mysql的樂觀悲觀

想要 附加 情況 屬性 ... str 但是 share 版本 樂觀鎖 總是認為不會產生並發問題,每次去取數據的時候總認為不會有其他線程對數據進行修改,因此不會上鎖,但是在更新時會判斷其他線程在這之前有沒有對數據進行修改,一般會使用版本號機制或CAS操作實現。 例如: 有這

深入理解樂觀悲觀

遇到 實現 個數 默認 ODB date 開始 安全 行數 前言在數據庫的鎖機制中介紹過,數據庫管理系統(DBMS)中的並發控制的任務是確保在多個事務同時存取數據庫中同一數據時不破壞事務的隔離性和統一性以及數據庫的統一性。 樂觀並發控制(樂觀鎖)和悲觀並發控制(悲觀鎖)是並

Java多線程系列---“基礎篇”13之 樂觀悲觀

而是 關系型 lock color 情況 發現 mis 再次 中一 轉自:http://www.cnblogs.com/zhengbin/p/5657435.html 樂觀鎖   樂觀鎖(Optimistic Lock), 顧名思義,就是很樂觀,每次去拿數據的時候都認

資料庫中的樂觀悲觀

樂觀鎖: 在關係資料庫管理系統裡,樂觀併發控制(又名“樂觀鎖”,Optimistic Concurrency Control,縮寫“OCC”)是一種併發控制的方法。它假設多使用者併發的事務在處理時不會彼此互相影響,各事務能夠在不產生鎖的情況下處理各自影響的那部分資料。在提交資料更新之前,

資料庫 樂觀悲觀

樂觀鎖 總是認為不會產生併發問題,每次去取資料的時候總認為不會有其他執行緒對資料進行修改,因此不會上鎖,但是在更新時會判斷其他執行緒在這之前有沒有對資料進行修改,一般會使用版本號機制或CAS操作實現。 version方式:一般是在資料表中加上一個資料版本號version欄位,表示資料被修改的次數,當

最通俗易懂的樂觀悲觀原理及實現

一、樂觀鎖   總是認為不會產生併發問題,每次去取資料的時候總認為不會有其他執行緒對資料進行修改,因此不會上鎖,但是在更新時會判斷其他執行緒在這之前有沒有對資料進行修改,一般會使用版本號機制或CAS操作實現。  version方式:一般是在資料表中加上一個資料版本號ver

什麼是樂觀悲觀

樂觀鎖: 簡單的來說:就是認為別人不會過來修改它的資料,常見的樂觀鎖通常會帶一個version(版本),等到提交的時候,會去檢查一下版本,如果版本修改了,就會丟擲異常,並且回滾資料; 樂觀鎖通常需要在表中額外設計一個version的冗餘欄位 並且在插入資料的時候,將version初始

關於樂觀悲觀的實際應用

開門見山,先聊一聊我實際遇到的業務問題: 在專案中有一個競猜下注的功能,它的賠率是根據A隊和B隊兩邊的下注總金額來計算的。於是當有使用者下注某一邊時,兩邊的賠率都會進行相應的變化。 反應到資料庫裡就是(簡化版本),一個人下注,會更改資料庫盤口表的幾個欄位:A隊賠率,A隊下注金額、B隊賠率,B隊下注金額

深入Mysql機制(四)樂觀悲觀

深入Mysql鎖機制(四)樂觀鎖與悲觀鎖 在資料庫鎖機制中介紹過,資料庫管理系統(DBMS)中的併發控制的任務是確保在多個事務同時存取資料庫中同一資料時不破壞事務的隔離性和統一性以及資料庫的統一性。 樂觀併發控制(樂觀鎖)和悲觀併發控制(悲觀鎖)是併發控制主要採用的技術手段。

Java併發問題--樂觀悲觀

首先為什麼需要鎖(併發控制)? 在多使用者環境中,在同一時間可能會有多個使用者更新相同的記錄,這會產生衝突。這就是著名的併發性問題。 典型的衝突有: 丟失更新:一個事務的更新覆蓋了其它事務的更新結果,就是所謂的更新丟失。例如:使用者A把值從6改為2,使用者B把值從2改為

關於樂觀悲觀的應用解決方案

原文連結 https://juejin.im/post/5c0009adf265da614a3a3741 在專案中有一個競猜下注的功能,它的賠率是根據A隊和B隊兩邊的下注總金額來計算的。於是當有使用者下注某一邊時,兩邊的賠率都會進行相應的變化。 反應到資料庫裡就是(簡化版本),一個

樂觀悲觀及應用舉例

最近因為在工作中需要,學習了樂觀鎖與悲觀鎖的相關知識,這裡我通過這篇文章,把我自己對這兩個“鎖家”兄弟理解記錄下來;        - 悲觀鎖:正如其名,它指的是對資料被外界(包括本系統當前的其他事務,以及來自外部系統的事務處理)的修改持保守態度,因此,在整個資料處理過程

【轉】Java併發問題--樂觀悲觀以及樂觀的一種實現方式-CAS

首先介紹一些樂觀鎖與悲觀鎖: 悲觀鎖:總是假設最壞的情況,每次去拿資料的時候都認為別人會修改,所以每次在拿資料的時候都會上鎖,這樣別人想拿這個資料就會阻塞直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制,比如行鎖,表鎖等,讀鎖,寫鎖等,都是在做操作之前先上

技術分享:關於樂觀悲觀的實際應用

    開門見山,先聊一聊我實際遇到的業務問題: 在專案中有一個競猜下注的功能,它的賠率是根據A隊和B隊兩邊的下注總金額來計算的。於是當有使用者下注某一邊時,兩邊的賠率都會進行相應的變化。 反應到資料庫裡就是(簡化版本),一個人下注,會更改資料庫盤口表的幾個

樂觀悲觀的應用場景

鎖( locking )         業務邏輯的實現過程中,往往需要保證資料訪問的排他性。如在金融系統的日終結算 處理中,我們希望針對某個 cut-off 時間點的資料進行處理,而不希望在結算進行過程中 (可能是幾秒種,也可能是幾個小時),資料再發生變化。此時,我