悲觀鎖的特點是先獲取鎖，再進行業務操作，即「悲觀」的認為獲取鎖是非常有可能失敗的，因此要先確保獲取鎖成功再進行業務操作；通常所說的「一鎖二查三更新」即指的是使用悲觀鎖。
樂觀鎖的特點先進行業務操作，不到萬不得已不去拿鎖；即「樂觀」的認為拿鎖多半是會成功的，因此在進行完業務操作需要實際更新資料的最後一步再去拿一下鎖就好；樂觀鎖在資料庫上的實現完全是邏輯的，不需要資料庫提供特殊的支援。一般的做法是在需要鎖的資料上增加乙個版本號，或者時間戳，然後按照如下方式實現：
select data as old_data, version as old_version from …;2. 根據獲取的資料進行業務操作，得到new_data和new_version
3. update set data = new_data, version = new_version where version = old_version
if (updated row > 0) else
樂觀鎖是否在事務中其實都是無所謂的
其底層機制是這樣：在資料庫內部update同一行的時候是不允許併發的，即資料庫每次執行一條update語句時會獲取被update行的寫鎖，直到這一行被成功更新後才釋放，因此在業務操作進行前獲取需要鎖的資料的當前版本號，然後實際更新資料時再次對比版本號確認與之前獲取的相同，並更新版本號，即可確認這之間沒有發生併發的修改；如果更新失敗即可認為老版本的資料已經被併發修改掉而不存在了，此時認為獲取鎖失敗，需要回滾整個業務操作並可根據需要重試整個過程。
資料庫的樂觀鎖和悲觀鎖
悲觀鎖 假定會發生併發衝突，遮蔽一切可能違反資料完整性的操作，假設資料肯定會衝突，所以在資料開始讀取的時候就把資料鎖定住。資料鎖定 資料將暫時不會得到修改 樂觀鎖 假設不會發生併發衝突，只在提交操作時檢查是否違反資料完整性。資料進行提交更新的時候，才會正式對資料的衝突與否進行檢測，如果發現衝突了，則...
樂觀鎖和悲觀鎖
1 悲觀鎖，正如其名，它指的是對資料被外界 包括本系統當前的其他事務，以及來自外部系統的事務處理 修改持保守態度，因此，在整個資料處理過程中，將資料處於鎖定狀態。悲觀鎖的實現，往往依靠資料庫提供的鎖機制 也只有資料庫層提供的鎖機制才能真正保證資料訪問的排他性，否則，即使在本系統中實現了加鎖機制，也無...
樂觀鎖和悲觀鎖
併發衝突 在多使用者的環境下，如果使用者同時修改同乙個文件，就會造成衝突。典型的衝突有兩種 1 丟失更新 乙個使用者的更新記錄覆蓋了另乙個人的更新。如 使用者一 讀 寫 使用者二 讀 寫 那麼使用者一就把使用者二的更新覆蓋了。2 髒讀 乙個使用者更新資料未完成時，另乙個使用者就讀取資訊。使用者一 讀...