悲觀鎖（pessimistic lock）：
每次獲取資料的時候，都會擔心資料被修改，所以每次獲取資料的時候都會進行加鎖，確保在自己使用的過程中資料不會被別人修改，使用完成後進行資料解鎖。由於資料進行加鎖，期間對該資料進行讀寫的其他執行緒都會進行等待。
樂觀鎖（optimistic lock）：
每次獲取資料的時候，都不會擔心資料被修改，所以每次獲取資料的時候都不會進行加鎖，但是在更新資料的時候需要判斷該資料是否被別人修改過。如果資料被其他執行緒修改，則不進行資料更新，如果資料沒有被其他執行緒修改，則進行資料更新。由於資料沒有進行加鎖，期間該資料可以被其他執行緒進行讀寫操作。
悲觀鎖：比較適合寫入操作比較頻繁的場景，如果出現大量的讀取操作，每次讀取的時候都會進行加鎖，這樣會增加大量的鎖的開銷，降低了系統的吞吐量。
樂觀鎖：比較適合讀取操作比較頻繁的場景，如果出現大量的寫入操作，資料發生衝突的可能性就會增大，為了保證資料的一致性，應用層需要不斷的重新獲取資料，這樣會增加大量的查詢操作，降低了系統的吞吐量。
總結：兩種所各有優缺點，讀取頻繁使用樂觀鎖，寫入頻繁使用悲觀鎖。
像樂觀鎖適用於寫比較少的情況下，即衝突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果經常產生衝突，上層應用會不斷的進行retry，這樣反倒是降低了效能，所以這種情況下用悲觀鎖就比較合適,之所以用悲觀鎖就是因為兩個使用者更新同一條資料的概率高，也就是衝突比較嚴重的情況下，所以才用悲觀鎖.
悲觀鎖比較適合強一致性的場景，但效率比較低，特別是讀的併發低。樂觀鎖則適用於讀多寫少，併發衝突少的場景。
悲觀鎖（pessimistic lock）：
每次獲取資料的時候，都會擔心資料被修改，所以每次獲取資料的時候都會進行加鎖，確保在自己使用的過程中資料不會被別人修改，使用完成後進行資料解鎖。由於資料進行加鎖，期間對該資料進行讀寫的其他執行緒都會進行等待。
樂觀鎖（optimistic lock）：
每次獲取資料的時候，都不會擔心資料被修改，所以每次獲取資料的時候都不會進行加鎖，但是在更新資料的時候需要判斷該資料是否被別人修改過。如果資料被其他執行緒修改，則不進行資料更新，如果資料沒有被其他執行緒修改，則進行資料更新。由於資料沒有進行加鎖，期間該資料可以被其他執行緒進行讀寫操作。
悲觀鎖：比較適合寫入操作比較頻繁的場景，如果出現大量的讀取操作，每次讀取的時候都會進行加鎖，這樣會增加大量的鎖的開銷，降低了系統的吞吐量。
樂觀鎖：比較適合讀取操作比較頻繁的場景，如果出現大量的寫入操作，資料發生衝突的可能性就會增大，為了保證資料的一致性，應用層需要不斷的重新獲取資料，這樣會增加大量的查詢操作，降低了系統的吞吐量。
總結：兩種所各有優缺點，讀取頻繁使用樂觀鎖，寫入頻繁使用悲觀鎖。
像樂觀鎖適用於寫比較少的情況下，即衝突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果經常產生衝突，上層應用會不斷的進行retry，這樣反倒是降低了效能，所以這種情況下用悲觀鎖就比較合適,之所以用悲觀鎖就是因為兩個使用者更新同一條資料的概率高，也就是衝突比較嚴重的情況下，所以才用悲觀鎖.
悲觀鎖比較適合強一致性的場景，但效率比較低，特別是讀的併發低。樂觀鎖則適用於讀多寫少，併發衝突少的場景。
悲觀鎖和樂觀鎖使用場景
樂觀鎖是在應用層加鎖，而悲觀鎖是在資料庫層加鎖 for update 樂觀鎖顧名思義就是在操作時很樂觀，這資料只有我在用，我先儘管用，最後發現不行時就回滾。悲觀鎖在操作時很悲觀，生怕資料被其他人更新掉，我就先將其先鎖住，讓別人用不了，我操作完成後再釋放掉。悲觀鎖需要資料庫級別上的的實現，程式中是做不...
Java悲觀鎖與樂觀鎖的區別及使用場景
適用場景 總結每次獲取資料的時候，都會擔心資料被修改，所以每次獲取資料的時候都會進行加 鎖，確保在自己使用的過程中資料不會被別人修改，使用完成後進行資料解鎖。由於資料進行加鎖，期間對該資料進行讀寫的其他執行緒都會進行等待。每次獲取資料的時候，都不會擔心資料被修改，所以每次獲取資料的時候都不會進行加鎖...
Java程式設計 悲觀鎖 樂觀鎖的區別及使用場景
定義 悲觀鎖 pessimistic lock 每次獲取資料的時候，都會擔心資料被修改，所以每次獲取資料的時候都會進行加鎖，確保在自己使用的過程中資料不會被別人修改，使用完成後進行資料解鎖。由於資料進行加鎖，期間對該資料進行讀寫的其他執行緒都會進行等待。樂觀鎖 optimistic lock 每次獲...