悲觀鎖和樂觀鎖的一點學習
鎖（ locking ）
業務邏輯的實現過程中，往往需要保證資料訪問的排他性。
鎖機制是在處理併發的時候所必須的乙個東西，當不存在併發的時候根本就不用考慮鎖機制
悲觀鎖【pessimistic locking】
顧名思義就是採用一種悲觀的態度來對待事務併發問題，我們認為系統中的併發更新會非常頻繁，並且事務失敗了以後重來的開銷很大，這樣以來，我們就需要採用真正意義上的鎖來進行實現。悲觀鎖的基本思想就是每次乙個事務讀取某一條記錄後，就會把這條記錄鎖住，這樣
其它的事務要想更新，必須等以前的事務提交或者回滾解除鎖。
在應用程式中顯式為資料資源加鎖。悲觀鎖假定當前事務操縱資料資源時，肯定還會有其他事務訪問該資源，為了避免當前事務的操作受干擾，先鎖定資源，它能防止丟失更新和不可重複讀等併發問題，但會影響併發效能。
悲觀鎖的實現，往往依靠資料庫提供的鎖機制（也只有資料庫層提供的鎖機制才能 真正保證資料訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無法保證外部系統不會修改資料）。
實現方式：
jdbc方式：在jdbc中使用悲觀鎖，需要使用select for update語句，假如我們系統中有乙個account的類，我們可以採用如下的方式來進行：
select * from account where ...(where condition).. for update.
當使用了for update語句後，每次在讀取或者載入一條記錄的時候，都會鎖住被載入的記錄，那麼當其他事務如果要更新或者是載入此條記錄就會因為不能獲得鎖而阻塞，這樣就避免了不可重複讀以及髒讀的問題，但是其他事務還是可以插入和刪除記錄，這樣也許同乙個事務中的兩次讀取會得到不同的結果集，但是這不是悲觀鎖鎖造成的問題，這是我們資料庫隔離級別所造成的問題。
樂觀鎖【optimistic locking】
樂觀鎖是在同乙個資料庫事務中我們常採取的策略，因為它能使得我們的系統保持高的效能的情況下，提高很好的併發訪問控制。樂觀鎖，顧名思義就是保持一種樂觀的態度，我們認為系統中的事務併發更新不會很頻繁，即使衝突了也沒事，大不了重新再來一次。它的基本思想就是每次提交乙個事務更新時，我們想看看要修改的東西從上次讀取以後有沒有被其它事務修改過，如果修改過，那麼更新就會失敗。（因此能夠解決第二類丟失修改問題）
假定當前事務操縱資料資源時，不會有其他事務同時訪問該資料資源，因此完全依靠資料庫的隔離級別來自動管理鎖的工作。
實現方式：
大多是基於資料版本 （ version ）記錄機制實現。何謂資料版本？即為資料增加乙個版本標識，在基於資料庫表的版本解決方案中，一般是通過為資料庫表增加乙個 「version」 欄位來實現。
讀取出資料時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提 交資料的版本資料與資料庫表對應記錄的當前版本資訊進行比對，如果提交的資料 版本號大於資料庫表當前版本號，則予以更新，否則認為是過期資料。
假如系統中有乙個account的實體類，我們在account中多加乙個version欄位，那麼我們jdbc sql語句將如下寫：
select a.version....from account as a where (where condition..)
update account set version = version+1.....(another field) where version =?...(another contidition)
這樣就可以通過更新結果的行數來進行判斷，如果更新結果的行數為0，那麼說明實體從載入以來已經被其它事務更改了，所以就拋出自定義的樂觀鎖定異常
悲觀鎖和樂觀鎖
1.悲觀鎖，正如其名，它指的是對資料被外界 包括本系統當前的其他事務，以及來自外部系統的事務處理 修改持保守態度，因此，在整個資料處理過程中，將資料處於鎖定狀態。悲觀鎖的實現，往往依靠資料庫提供的鎖機制 也只有資料庫層提供的鎖機制才能真正保證資料訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無...
悲觀鎖和樂觀鎖
前幾天有人問了我乙個問題，說如果資料庫某些操作不用事務，那麼又需要保持資料的一致性，那麼該用什麼方法替代事務。我就想到了悲觀鎖和樂觀鎖的思想，下面我解釋一下在資料庫中的悲觀鎖和樂觀鎖 1.悲觀鎖就是把資料庫的一些操作，放在事務當中，依賴資料庫的隔離級別，實現對資料修改的封鎖，這樣做資料一致性可以保持...
悲觀鎖和樂觀鎖
悲觀鎖 pessimistic lock 顧名思義，就是很悲觀，每次去拿資料的時候都認為別人會修改，所以每次在拿資料的時候都會上鎖，這樣別人想拿這個資料就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。樂觀鎖 optim...